vergesst C++ ...
-
Ich finde schon, dass C# 1.0 grobe Patzer hat, auch solche, die man nicht mehr korrigieren kann. Der größte Patzer war, dass sie die Generics noch nicht hatte und man daraufhin die Standardbibliothek an einigen Stellen schlecht designed hat. Das Problem ist, dass generische Typen nicht abwärtskompatibel sind. Jetzt gibt es in der Standardbibliothek nicht-generische Collections und generische. Das einfache VB wird aufgemotzt weil sonst die neuen Klassen nicht genutzt werden könnten und implizit scheinbar nicht Object als Typparemeter angenommen werden kann.
Oder nen XmlSerializer mit Konstruktor XmlSerializer(System.Type) und Serialize(Stream, Object) anstatt nen XmlSerializer<Type>. Im System.Drawing-Namespace gibt es ein Rectangle, Size, Point sowie ein RectangleF, SizeF, PointF.
Am schlimmsten IMHO das kovariante Array mit Performance-Strafe für Referenztypen. Wenn von Anfang an Generics drin gewesen wäre, hätte man vielleicht so etwas gemacht wie Array<T>, wobei T[] dann nur eine abkürzende Schreibweise ist. Und Kovarianz hätte man dann immer noch explizit haben können mit Array<T> where T: Foo. Ich brauche so selten ein kovariantes Array, dass es mir weh tut, dafür zahlen zu müssen.
-
kartoffelsack schrieb:
Natürlich kannst Du eine Objekt in ne simple Zeichenfolge zerdröseln, das über tcp verschicken und auf der anderen Seite wieder zusammenbasteln. Nur: Mit Reflexions würde das Serialisieren automatisch funzen. In J2EE muss ich mir keine Gedanken darüber machen, wie das Ding serialisiert wird. ...
Aha? Aber schon mal die Praxis durchgemacht? Wie haben hier einen J2EE 1.3 Server von IBM (WebSphere), natürlich sind die serialisierten Objekte die wir über RMI verschicken, mit einem J2SE 1.4 Client inkompatibel. Schöne tolle Welt, wo man sich keine Sorgen machen muß.
SUN hat das Problem erkannt, und seit Java 1.4 (oder 1.4.2?) werden alle Serialisierungen defaultmäßig per XML getätigt -> Text-Format!
Eben damit es keine Binary-Inkompatibilitäten mehr zwischen Java Versionen geben kann (da bringt mir auch eine VM nichts mehr).Ja ja, Theorie und Praxis!
Ich arbeite täglich 8 Std. mit Java, und glaubt mir: es hat schon seine Vorteile gegenüber C++. Aber es gibt Sachen, da frage ich mich "Was machen wir hier eigentlich mit dem Java-Kram?"
-
schrieb:Power Off schrieb:
Perl ist übrigens auch sehr mächtig [...]
yo, mächtig scheisse
Ich hab schon Compiler-Generatoren und Anwendungen mit grafischer Oberflaeche in Perl entwickelt.
Einziger Wermutstropfen ist, dass Perl so langsam ist. Z.B. OO-Programmierung in Perl ist sehr lahm.
Aber Perl ist halt sehr komfortabel.
Hatte mal ein Problem mit den Windows-Implementationen von Perl (z.B. ActiveState Perl), das lief irgendwie nicht zuverlaessig, da hab ich mit Perl unter Windows aufgehoert.
Aber unter Linux z.B. kann man's ja noch benutzen (oder unter Windows eine andere Perl-Distro nehmen).
Es gibt halt SWIW keine kostenlosen Perl Compiler, die die Programme schneller machen wuerden.
-
kartoffelsack schrieb:
Ein paar Nachteile hat der C++-Weg mit den Libs allerdings schon. Und weil o'rakl sie nicht nennt ...:
Der ganze Schmus (also z.B. std::vector) wird jedesmal neu übersetzt. Das kostet Compilezeit und die ist in C++ z.T. wirklich nicht mehr lustig. Hinzu kommt, dass es kein anständiges Modulkonzept gibt und jede übersetzungseinheit jedesmal xxx Zeilen Headercode neu mitübersetzt. Vorkompilierte Header etc. bringen zwar was, lösen aber das Problem nicht. Ein compiler, der wie in Java den Code während der eingabe übersetzt und eine IDE, die mir die Fehler dann - wie in ner Text-Verarbeitung - unterringelt, ist so nicht zu machen. In C++ freu ich mich wie ein kleines Kind, wenn die Codevervollständigung die richtigen hints gibt.
Übliche Tricks, abhängigkeiten zwischen Übersetzungseinheiten zu vermeiden (forward-Deklaration) funzen nicht mehr, wenn man mit smart_ptr arbeitet. Da muss nämlich die Definition des verpackten Typs bekannt sein, damit der Dtor aufgerufen werden kann. Gut, dann kann ich mit pimpl arbeiten, aber das verdoppelt die Tipparbeit für die Definition der Schnittstelle, eine Schnittstellenänderung wird gleich noch unangenehmer und unübersichtlicher etc.. Das alles heist, dass ich mich neben sauberer Modellierung in der Sprache auch noch einen Haufen sachen kümmern muss, damit mir nicht jeder Compilerlauf, während ich grad Unit-Tests mache und da und dort Fehler ausbessere ne viertelstunde kostet. Und auch 3 Minuten sind eigentlich viel zu viel.Ein weiterer Nachteil ist die Arbeit mit dem Debugger. Welcher Debugger kann mir einfach mal schnell den Inhalt eines list<int>-Objekts anzeigen? Ganz zu schweigen von map<string, shared_ptr<Foo> >. Das schaffen die Werkzeughersteller bisher nichtmal für die STL-Konstrukte.
mE kann man C++ z.T. schon vorwerfen, dass es nicht so produktiv ist, wie andere Sprachen. Das liegt aber nicht an den Eigenschaften der Sprache an sich (mögliche Konstrukte, Einschränkungen oder Freiheiten), sondern
an mangelnder Unterstützung durch Werkzeuge bzw. daran, dass es die Sprache offensichtlich schwer macht, gute Werkzeuge zu entwickeln.Das Argument, dass boost nicht zählt, weil es nicht zum Standard gehört, ist me übrigens nichtig. Boost lässt sich auf den verbreiteten Plattformen auf denen es einen vernünftigen standardkonformen Compiler gibt, übersetzen. Auf exotischen Plattformen zwar vielleicht nicht, aber da gibts dann auch keine python-Implementierung
Die ersten ernst zu nehmende Argumente gegen C++.
kartoffelsack schrieb:
Natürlich kannst Du eine Objekt in ne simple Zeichenfolge zerdröseln, das über tcp verschicken und auf der anderen Seite wieder zusammenbasteln. Nur: Mit Reflexions würde das Serialisieren automatisch funzen. In J2EE muss ich mir keine Gedanken darüber machen, wie das Ding serialisiert wird. (natürlich kann ich mir gedanken machen, und ich muss es auch, wenn ich etwas komplexere Objekte verschicken will. Aber das ist nicht der Standardfall und für den sollte eine Sprache was mitbringen. Genauso wie std::vector den Standardfall für Conatainer abdeckt). Automatische Serialisierung kann nicht von externen Bibs abgebildet werden, außer mann lässt nochmal spezielle Generatoren laufen (wie mans z.B. bei gSoap macht) -> für interprozesskommunikation wichtig.
boost::serialize bietet da eigentlich recht gute Möglichkeiten. Aber in einem Punkt hast du recht, es gibt keine default Serialisirungsmethode. Diese muß jedesmal auf neue geschrieben werden wobei die aber meist trivial ist.
-
kartoffelsack schrieb:
kartoffelsack schrieb:
Vorkompilierte Header etc. bringen zwar was, lösen aber das Problem nicht.
warum lösen die das problem nich? die header werden dann schliesslich nur einmal übersetztIst mir egal, wenn ein ein mittelgroßes Projekt dann trotzdem noch ein zwei drei oder 5 Minuten compiliert. Hab noch nie ein Java oder Delphi-Projekt gesehen, das auch nur ne Minute brauchen würde. Ja, ich weiß, C++-Code ist komplexer etc. aber es sind wirklich Größenordnungen. Und das, wenn ich alle vorkompilierten-Header- und Abhängigkeiten-vermeide-Tricks nutze. Wenn ich einfach versuche mein Problem mit Code zu lösen bin ich schnell bei compile-Zeiten von nem Viertelstündchen.
Außerdem muss ich für die vorkompilierten Header n Haufen herstellerspezifischer Regeln einhalten. Bei VC++ überall stdafx.h einbinde, da alle häufig genutzen wenig veränderten Header reintu (und damit in jedem Modul mehr abhängigkeiten schaffe, als ich eigentlich bruach. bei C++Builder dürfen die Header keinen Code (keine inline-Funktionen) beinhalten ...
Warum es nicht geht, jeden Header einzeln vorkompiliert vorzuhalten ...???
dann musst du halt deinen modularen aufbau überdenken
wenn du an der implementierung eines moduls was änderst ohne das interface zu ändern musst du ja nur das eine modul neu übersetzender name stdafx is austauschbar
außerdem musst du den vorkompilierten header nich überall einbinden, sondern nur in den sourcedateien die ihn auch brauchen
-
Ben04 schrieb:
boost::serialize bietet da eigentlich recht gute Möglichkeiten. Aber in einem Punkt hast du recht, es gibt keine default Serialisirungsmethode. Diese muß jedesmal auf neue geschrieben werden wobei die aber meist trivial ist.
Das könnte man auch automatisieren, in dem man ein kleines Tool baut, das einem den entsprechenden Code baut. Einfach angeben, welche Klassen mit boost::serialize implementiert werden sollen -> fertig.
Gut, so ein Tool gibt es leider (noch) nicht, wäre mal eine Idee sowas nebenbei zu proggen.
-
Power Off schrieb:
Aber Perl ist halt sehr komfortabel.
du kannst ind willst nicht ordentlich coden.
http://www.c-plusplus.net/forum/viewtopic-var-t-is-121401-and-postdays-is-0-and-postorder-is-asc-and-start-is-0.html
also sind deine einschätzungen hier irrelevant.
-
Zum Serialisieren gehört mehr, als eine default-Methode zu haben, die das macht. Wenn man einen Graphen serialisieren will, muss Zeigern auf andere Objekte gefolgt werden, die müssen mit serialisiert werden, usw. Wie stellt ihr euch eine serialisierte LinkedList sonst vor? Natürlich braucht man dazu noch die Möglichkeit, auch angeben zu können, wenn einem Zeiger nicht gefolgt werden darf.
Das zweite ist Versioning. Man braucht mit einer default-Serialisierung auch eine default-Möglichkeit, ältere Objekte korrekt wieder zusammenzubauen und sie am besten in was neueres zu konvertieren. Das geht beispielsweise mit dem XmlSerializer vom .Net Framework sehr fein. Ne Eigenschaft entfernen, wird halt nicht mit ausgepackt. Ne Eigenschaft hinzufügen, kommt halt default-Wert hin. Solche Sachen sind wichtig und ohne wenigstens compile-time Reflection nicht trivial zu implementieren. Noch vielseitiger wird es mit run-time Reflection, beim Serialisieren dann, dann kann man auch schön abgeleitete Klassen reinpacken, und evtl. als Basis auspacken, mit nem template<class T> Serializer aber IMHO nicht mehr zu machen, compile-time Reflection reicht da nicht.
-
volkard schrieb:
Power Off schrieb:
Aber Perl ist halt sehr komfortabel.
du kannst ind willst nicht ordentlich coden.
http://www.c-plusplus.net/forum/viewtopic-var-t-is-121401-and-postdays-is-0-and-postorder-is-asc-and-start-is-0.html
also sind deine einschätzungen hier irrelevant.Power Off == Doedel?
-
Optimizer schrieb:
Power Off == Doedel?
nein. Power Off hat wirklich das alles gemacht, von dem er erzählt. hoffentlich hat er das auch fachgerecht entsorgt. ok, ob der nen compiler nu wirklich geschrieben hat, oder damals das drachenbuch gelesen hat, kann man nicht entscheiden.
es ist schwer zu glauben, wie einer so unglaublich lang auf der stelle treten kann. aber das gibts. ich hab nen kollegen, der ebenso wie ich manchmal c++ lehrt, der kann auch nur c mit großen funktionen schreiben und von c++ kennt er die sprachmitten, weiß aber überhaupt nichts damit anzufangen. von oo hat er keine ahnung. templates reichen bis zu containerklassen (ohne policies). und er hat keine ahnung davon, wie sagenhaft wenig er von c++ weiß. er fühlt sich total groß und ist stolz, wie lange er schon "c++" macht.
-
O'Rakl schrieb:
Ganz einfach: Im letzteren Fall stürzt nur eine *virtuelle* Maschine ab.
Dabei entstehen weder Schäden am Speicher noch am Dateisystem.Aha, Fehlerhandling in Software ist für dich ok, in Hardware aber nicht? Interessant. Was glaubst du denn, was da passiert? Ich sag dir, was passiert. Abgefangen wird sowas auch, deshalb macht es praktisch keinen Unterschied. Nur mal als Beispiel: die CPU erhält einen ungültigen Befehl, weil jemand die Zugriffsbeschränkungen von Code Pages und den Code selbst verändert hat. Jetzt läuft niemand unkontrolliert Amok, sondern ein Hardware Interrupt springt an, der alles weitere regelt. Wobei ich mich auf x86 Systeme beziehe, auf anderen Systemen mag das anders aussehen.
Eine Diskussion darüber ist aber sowieso unsinnig, da C++ Exceptions hat. Basta.O'Rakl schrieb:
Die aber auch nicht, das muß der Neid Dir lassen
Versteh ich nicht. Wer sind denn die?
O'Rakl schrieb:
So ein Käse.
C++ ist ein um OOP-Elemente erweitertes C und C ist bekanntlich keine objektorientierte Sprache.Der einzige, der seit 30 Seiten
Käse erzählt, bist du. Du hast es vielleicht noch nicht mitbekommen 
, aber C++ ist *nicht* C. Das sind zwei unabhängige Sprachen. Und dass bei der Entwicklung von C++ C als Grundlage diente, und man einiges für Kompatibilität getan hat, ist irrelevant. Genauso gut hätte man jede andere Sprache nehmen können. Genau genommen, entstand C++ aus den Erfahrungen Stroustrup's mit Simula, was als erste OO Sprache überhaupt gilt. Seit dem ersten Release der C++ Spezifikationen enthält die Sprache jedenfalls ein OO Konzept, also überleg in Zukunft besser zweimal, als solchen Blödsinn zu erzählen.Sovok schrieb:
probier mal visual assist x... macht n deutlich besseren job als die standardvervollständigung
Visual Assist ist wirklich super, für die meisten leider keine Option, da es für dauerhafte Nutzung kostenpflichtig ist.
O'Rakl schrieb:
Eine "access violation"-Meldung weist auch auf eine versuchte Beschädigung (natürlich nicht im Hardware-Sinne, sondern im
Sinne der Speicher-Integrität) des Speichers hin.Und? Ist das nicht genau das, was wir wollen. und was bei deiner tollen VM auch passiert?
O'Rakl schrieb:
Ein Pointer, der durch Programmfehler auf falsche Adressen zeigt, und dabei einen Befehlsstring wie "del $" in "del *"
verändert, kann das Dateisystem ebenso beschädigenSowas bekommt man sicherlich auch in Python hin, vielleicht nicht durch Zeiger, aber unfähige Programmierer schaffen das. Du solltest das also wissen. Mir ist dabei aber immer noch unklar, was du mit "beschädigen" meinst.
Artchi schrieb:
Alte Geschichten, die seit MS VC++ 7.1 der Vergangenheit angehören! Der Compiler hat mittlerweile eine Array-Überlaufprüfung drin, die zur Laufzeit anspringt (gibts einen Compiler-Switch für).
Meinst du /GS? AFAIK ist das aber nur zur Überprüfung, ob die return Adresse überschrieben wurde. Ob generelle Array-Überlaufprüfung möglich ist, da bin ich mir gar nicht so sicher. Für C++ aber auch nicht so wichtig, wer keine Container wie std::vector oder boost::array nimmt, macht sich das Leben selbst unnötig schwer.
-
groovemaster schrieb:
Sovok schrieb:
probier mal visual assist x... macht n deutlich besseren job als die standardvervollständigung
Visual Assist ist wirklich super, für die meisten leider keine Option, da es für dauerhafte Nutzung kostenpflichtig ist.
ich gehör tatsächlich zu den leuten die für gute software auch bezahlen
-
Ich auch, da aber viele C++ nur als Hobby haben, werden die es sich zweimal überlegen, 130$ für ein IDE Addon auszugeben.
-
groovemaster schrieb:
aber C++ ist *nicht* C.
Hört, hört. -- ja, und ? was willst du uns damit sagen ?
Das sind zwei unabhängige Sprachen.
Nein. C++ und C sind nicht voneinander unabhängig, ebensowenig wie etwa Visual Basic und Tiny Basic voneinander unabhängig sind. C++ hieß ursprünglich "C with classes", das kann dir gefallen oder nicht, es ist nun mal so.
Übrigens: Verbalinjurien sind kein Ersatz für fehlende Argumente. Nur mal so
nebenbei
-
O'Rakl schrieb:
Hört, hört. -- ja, und ? was willst du uns damit sagen ?
Du trennst sie doch nicht sauber! Du meinst du redest von C++, aber in Wirklichkeit redest du von C!
O'Rakl schrieb:
C++ hieß ursprünglich "C with classes", das kann dir gefallen oder nicht, es ist nun mal so.
Das war doch nur der Arbeitstitel.
O'Rakl schrieb:
Übrigens: Verbalinjurien sind kein Ersatz für fehlende Argumente. Nur mal so nebenbei
Wer im Glashaus sitzt...
-
O'Rakl schrieb:
Das sind zwei unabhängige Sprachen.
Nein. C++ und C sind nicht voneinander unabhängig, ebensowenig wie etwa Visual Basic und Tiny Basic voneinander unabhängig sind. C++ hieß ursprünglich "C with classes", das kann dir gefallen oder nicht, es ist nun mal so.
sie sind verschiedene sprachen. außer natürlich du zählst die ähnlichkeiten in der syntax. dann muß man aber auch klarerweise sagen, daß java gleich c ist. willste das?
schau dir gute (also af keinen fall von Power Off) c++-programme und gute c-programme an und du wirst sehen, daß sie ganz unterschiedlich sind.
-
O'Rakl schrieb:
Nein. C++ und C sind nicht voneinander unabhängig, ebensowenig wie etwa Visual Basic und Tiny Basic voneinander unabhängig sind. C++ hieß ursprünglich "C with classes", das kann dir gefallen oder nicht, es ist nun mal so.
Man hat C mit Klassen in C++ umgenannt weil der Name der Sprache eben nicht mehr gerecht wurde, da C++ in der Zwischenzeit eben weit über ein C mit Klassen hinaus gewachsen war. Das kann dir gefallen oder nicht, es ist nun mal so.
-
Putzig: Da muß ich euch noch sagen, wie C++ hieß, bevor es "C++" hieß.
Einige wollen hier wohl leider nur streiten um des Streitens willen.
Egal.
-
O'Rakl schrieb:
Nein. C++ und C sind nicht voneinander unabhängig, ebensowenig wie etwa Visual Basic und Tiny Basic voneinander unabhängig sind. C++ hieß ursprünglich "C with classes", das kann dir gefallen oder nicht, es ist nun mal so.
Dann erklär uns doch bitte mal, warum ein C-Programm (ich meine eines, das den aktuellen C-Standard voll ausnutzt) sich auf einem reinen C++-Compiler (auch aktuell) nicht kompilieren lassen würde?
Wie kann da also C++ ein C sein, wenn es nicht alle Eigenschaften von C geerbt hat?
-
O'Rakl schrieb:
Putzig: Da muß ich euch noch sagen, wie C++ hieß, bevor es "C++" hieß.
Einige wollen hier wohl leider nur streiten um des Streitens willen.
Egal.Und du meinst, Recht zu haben, obwohl dir das ganze Forum über 30 Seiten etwas anderes sagt. Sehr putzig. Und jetzt geh spielen.