Ich lese grade weiter unten das ein frischer Absolvent, wegen C++ Probleme hat. Mich wundert das nicht, denn ich hatte auch welche damit, denn diese Terrorshow in Sachen C++ Werbung konnte ich nie nachvollziehen, wo es hieß Wiederverwendbarkeit usw. Als ob die Altprogrammierer alle blöd waren und ihre Programme und Bibliotheken weggeworfen haben ? Fakt ist, in vielen Compilern wurde bis tief in die 90er Jahre C++ direkt in Ansi-C umgewandelt also reine Textverarbeitung betrieben, bevor dann der normale C-compiler drüber ging. der haken dabei ist, das C++ doof ist, also nicht das an optimierunen bringen kann wie ein Mensch der in C handverlesen programmiert und somit einen Molloch an Code erzeugt. Man sieht das an der KDE unter Linux, wobei die Ladezeiten im Regelfall beim Erststart oft doppelt so hoch sind wie bei einem reinen C-Programm. Beispiele: (unter Linux) KPDF und zum Vergleich das schnelle XPDF, beides PDF-Reader, wobei KPDF auf dem SoureCode von XPDF basiert allerding nur den Oberflächen Molloch des KDE-Styles drüberzieht wären XPDF die GTk+ als Grafikoberfläche benutzt. Testet das mal auf nem älteren Rechner aus (PII - 400 MHz - 128 MB), da fällt das sehr dramatisch auf. Ausserdem sind C++ - Klassen nix anderes als Strukturen in C , nur die Reihenfolge in den Zugriffsrechten ist anders, Structs sind immer public beim Erstellen und müssen abgedichtet werden, während Klassen immer private sind und somit nach aussen gelockert werden müssen. Durch Friendfunktionen wird das Konzept der Verkappselung ausgehöhlt, was ein Wiederspruch der Objektorientierung in sich ist. Vererbung von Klassen ist nix anderes als Copy+Paste von Strukturen in C. Klassenfunktionen (Methoden) die ja eigendlich nur(!) in die Klasse gehören sollten, sind ebenfalls Betrug! Diese Dinger werden einfach in einem anderen (internen) Modul (im Compilerlauf) gespeichert und in diesem Modul als static deklariert, was verhindert das der Linker diese routinen den anderen Modulen bekannt macht und somit dieser private Charakter nur vorgetäuscht wird, denn variablen und funktionen die static deklariert werden gab es ja schon im guten alten C denn ansonsten würde die umwandlung von C++ nach C wie bei vielen Compilern die bis ende der 90er auf dem Marktwaren nicht funktionieren. Was glaubt ihr wohl warum diese C++ Fetischisten empfehlen für jede Klasse eine eigene Header-Datei anzulegen ? Eben, weil genau das oben beschriebene Konzeppt dahinter steckt und auf diese weise dem HyroglyphenCompiler (C++) die arbeit etwas leichter gemacht wird......des weitren möchte ich hier mal kurz zeigen, wie man Objektorientiert Klassen anlegt. dazu bedarf es kein C++ ! Objektorientierte Sichtweise kann man besonders schnell lernen, wenn man schon mal auf irgend einer Relationalen Datenbank mit SQL gearbeitet hat Jede Tabellendeklaration der Datenbank wäre in C++ ein Klasse. Tabellen werden verknüpft um Speicherplatz aufgrund Redundanzen zu sparen. Beispiel: Person( personalnr. , name, vorname , alter); Stadt( plz , name ); ...ist sinniger als jedes mal "Dortmund" in einer anderen Tabelle z.b. Adresse( plz , strasse ) ; ....statt plz schreiben zu müssen, denn es reicht die plz vollkommen aus. Verknüpft man nun Tabellen miteinander aus logischen gründen gibt es 2 Fälle: a) Anhand der plz kann man beide Tabellen verknüpfen wenn nix weiter benötigt wird. Personaltab( personalnr , plz ) um alle daten (indirekt) zu adressieren. b) Will man zur adresse eine Eigenschaft hinzubasteln z.B Tätigkeit( personalnr , "terrorist" ) würde man eine neue Tabelle Tätigkeit erstellen müssen, in C++ wäre das eine neue Klasse die von 2 anderen Klassen erbt und dann um die eigenschaft wie hier art der Tätigkeit -terrorist- erweitert wird. Das ist eigendlich alles. Diese OOP Geschichte ist das selbe in grün, nur es werden alte Eigenschaften unter komplizierten Namen verkauft um die potentiellen Anwender (Entwicker) mit einer angeblich neuen Technik zu narren, die im Kern der Sache alles andere als neu ist. Was meine meinung betrifft, es geht nix über reines C !!!!!! Ausnahme wäre vieleicht ADA, wegen der Strenge. Kleine Objectcodes, praktisch und sehr sehr schnell. Bis auf Windows kenne ich kein Betriebssysem was wesentlich in C++ gebaut ist ? Alles was nicht in C++ gebaut ist, ist wesentlich schneller kleiner und effektiver. Ach so ich vergaß - Operatoren-Überladung: Das ist ja an sich ne geile Sache, nur meine lieben Informatikerkollegen haben es übertrieben. Alles was nicht niet- und nagelfest war wurde addiert, subtrahiert, multibliziert und dividiert, z.B. Bäume, Listen, Stacks, Arrays usw. Ob die artverwandten Mathematiker solche Operationen überhaupt genehmigt haben, damit sie einen Sinn machen darauf wurde gepfiffen. Als Java raus kam hat SUN wohl bewusst auf diese Überladung verzichtet........ Soll heissen, wenn die Katze nicht im Hause ist, tanzen die Mäuse auf dem Tisch. Und so war es auch als dieser Hype in sachen C++ in den 90ern gemacht wurde. Was ich lustig finde ist, es gibt ja echte Experten in C++ so auch welche aus meinem Studium. Nur ich weis acht nicht worauf man da stolz sein kann ? Darauf das man echte Textverarbeitung kann ? Textverarbeitung die mittels PreProzesser-Programm Hyroglyphen in Ansi-C umwandelt das dann compiliert wird ? Ich sage nur, alles das kann man auch in C machen, nur wesendlich effektiver und vor allem viel schneller in sachen speed beim Programmlauf. Übrigens ich möchte um Gottes willen nicht das mir einer das hier alles glaubt. Wer zweifelt, solle mal im Buch: "Design and implementation of C++" nachsehen hier: http://www.research.att.com/~bs/homepage.html Theo
> Übrigens ich möchte um Gottes willen nicht das mir einer das hier > alles glaubt. Ich hatte anfangs noch gezweifelt, ob das jemand ernst meinen kann, aber zum Glück kommt ja unten die Auflösung. Ansonsten hast du es den C++-Programmierern aber gezeigt. Jetzt wissen die endlich auch, dass am Ende nur Maschinencode rauskommt den man auch mit C-Programmierung erreichen kann. Aber ich persönlich bin ja der Meinung, dass alles was über Assembler hinausgeht, nur für Warmduscher ist - schliesslich kann ich das Ganze auch in Assembler realisieren. ----, (QuadDash).
Wobei reines Assembler nicht wirklich viel bringt, wenn man ANwendungsprogramme erstellen möchte. Beispiel Texteditor: du wirst kaum ein Unterschied merken zwischen der C-Version und der reinen Assembler-Version.
> Vererbung von Klassen ist nix anderes als Copy+Paste von Strukturen > in C. Du hast ja in vielerlei Themen die Weisheit mit Löffeln gefressen, aber mit solchen bekloppten Statements zeigt sich wieder, was für ein Held du bist. An welcher Hochschule haben sie dich eigentlich bis zum Abschluss studieren lassen?
Wow. >Diese OOP Geschichte ist das selbe in grün, nur es werden alte >Eigenschaften unter komplizierten Namen verkauft um die potentiellen >Anwender (Entwicker) >mit einer angeblich neuen Technik zu narren, die im Kern der Sache >alles andere als neu ist. Da hast Du sicher Recht. Allerdings werden bei OOP wenigstens die Eigenschaften beim Namen genannt. Brechen kann ich die aber überall. Ob ich jetzt eine C-header Datei habe, die überall benutzt wird, oder eine Klasse mit Singleton-Pattern implementiere und dann immer wieder ranziehe. Eine Kapselung ist dann nicht mehr gegeben. >Das ist ja an sich ne geile Sache, nur meine lieben >Informatikerkollegen haben es übertrieben. Das haben sie manchmal. Besonders den Shift-operator zur Ausgabe zu misbrauchen STDOUT << "hallo" ist nicht nett. An anderen Stellen fehlt es aber manchmal schon. Desshalb würde ich 3D algorithmen doch lieber in C++ machen. >Objektorientierte Sichtweise kann man besonders schnell lernen, wenn >man schon mal auf irgend einer Relationalen Datenbank mit SQL >gearbeitet hat Hä? Was hat denn das damit zu tun? Also ich schreibe gerne sowohl C, wie auch C++. Auf den Anwendungsfall kommt es halt an. Wer Objekte in C nachbaut, der macht es sich schwer (GTK). Es geht aber. Wer das gleiche mit Tabellen probiert, der landet dann bei so etwas: call_object( Object obj, int function, long p1, long p2, long p3) Hab ich schon gesehen. Ist Super zum debuggen. Wer von C++ keine Ahnung hat, der verbricht so etwas wie z.B. Symbian, wo es so etwa zehn verschiedene String Objekte gibt. Verwirrung ist vorprogrammiert. Wer es aber richtig macht, der hat an C++ seine echte Freude. Kurz, prägnant und weniger Gefahren eine Memory Leak zu erzeugen. Warum? Wegen Destruktoren und der Möglichkeit komplexe Strukturen komplett über den Stack zu handlen. Und hier noch mein Vergleich: Qt und GTK Eines davon ist in C++. Keines ist viel schneller, kleiner oder besser.
>> Vererbung von Klassen ist nix anderes als Copy+Paste von Strukturen >> in C. >Du hast ja in vielerlei Themen die Weisheit mit Löffeln gefressen, aber >mit solchen bekloppten Statements zeigt sich wieder, was für ein Held du >bist. Bevor du in dieser Hinsicht die Klappe öffnest, solltest du lieber mal einen Blick hier rein werfen: "Design and Implementation of C++" http://www.research.att.com/~bs/homepage.html Falls dir das nicht gefällt, dann kannst du auchmal hier nachsehen: http://www.amazon.de/Objektorientiertes-Programmieren-C%2b%2b-Tutorial-Umsteiger/dp/3827317711/sr=1-1/qid=1157581741/ref=sr_1_1/028-9836768-5629312?ie=UTF8&s=books Trotz der Lobeshymnen die da ein Kritiker auf C++ hält, gabs von Josuttis um 3/1996 einen Artikel in der Zeitung -Objekt-Spektrum- der so hieß wie: "C ++ Die wahrheit über Vererbung" wo er nicht unbedingt ein all zu gutes Haar an der Sprache lies. Und was Vererbung betrifft, was ist daran falsch wenn ich sage ist nix andertes als copy + paste ? Das etwa ein Konstruktor da ist, der eigendlich nix anderes ist als eine Init-Routine die ggf. die Klasseninstanz füllt und die man letztlich auch ohne automatismus schreiben kann.......? An welcher Hochschule haben sie dich eigentlich bis zum Abschluss studieren lassen? Dortmund Interessant fand ich allerdings das es in Dortmund im Indupark (nähe Uni) eine schon seit vielen Jahren erfolgreiche Firma gibt, deren Chef mir mal sagte das es viele C++ Programierer gäbe, die kein C könnten un beim Umstieg sehr große Probleme hätten, wenn z.B. ein C-projekt betreut werden müsste. Na ja, iss ja auch was anderes wenn man von ner Pre-Prozessor-Textverarbeitung auf ne eigendliche Programmiersprache umsteigt.......:-) Aber über Dogmatiken kann man bekanntlich streiten........ Theo
>Da hast Du sicher Recht. Allerdings werden bei OOP wenigstens die >Eigenschaften beim Namen genannt. >Brechen kann ich die aber überall. Aber ganau das solle ja verhindert werden, zumindest wesentlich. Ich denke aber mal das eine Sprache wie C++ wohl keinen Apell an die vernunft eines programmieres setzen kann, was ja eigendlich beabsichtigt war. >Das ist ja an sich ne geile Sache, nur meine lieben >Informatikerkollegen haben es übertrieben. >Das haben sie manchmal. Besonders den Shift-operator zur Ausgabe zu >misbrauchen STDOUT << "hallo" ist nicht nett. Stimme ich dir zu. >An anderen Stellen fehlt es aber manchmal schon. Desshalb würde ich 3D >algorithmen doch lieber in C++ machen. Weis nicht, seit C99 ist Operatorenüberladung auch in C drin, ebenso dynamische Arrays. Davon ab, macht C++ bei einer Methode ja nix anderes als heimlich hinter Programmierers Rücken die Parameterliste der Methode zu öffnen und dann an erster oder letzter stelle, den Selfpointer mit dem Typ der Klasse einzufügen, wobei man im Programmcode natürlich nix davon sieht. >>Objektorientierte Sichtweise kann man besonders schnell lernen, wenn >>man schon mal auf irgend einer Relationalen Datenbank mit SQL >>gearbeitet hat >Hä? Was hat denn das damit zu tun? Es kommt auf die Sichtweise an. Klassen ann man auch als Entitäten sehen, so wie: class Person { Eigenschaften ..... Methoden(...) } Genau so entwirft man ein betriebliches Informationssystem, durch geeignet verknüpfung von Entitäten. Die Denke ist dabei die selbe, nur das man nicht Tabelle sagt, sondern Klasse, statt Verknüpfung nennt man das dann in C++ Vererbung. Natürlich ist die Denke nicht 100% kompatibel aber 80-90% sind dabei allemal drin. >Also ich schreibe gerne sowohl C, wie auch C++. Auf den Anwendungsfall >kommt es halt an. Wer Objekte in C nachbaut, der macht es sich schwer >(GTK). Es geht aber. Und der Betreffende weis was er tut !!! Wer das gleiche mit Tabellen probiert, der landet dann bei so etwas: call_object( Object obj, int function, long p1, long p2, long p3) Hab ich schon gesehen. Ist Super zum debuggen. Funktionen als Parameter zu übergeben kommt in C schon ewig vor. und der Parameter "Object obj" ist genau das was der c++ compiler hinter vorgehaltener Hand macht in dem er die parameterliste erst beim Compilerlauf erweitert. >Wer von C++ keine Ahnung hat, der verbricht so etwas wie z.B. Symbian, >wo es so etwa zehn verschiedene String Objekte gibt. Verwirrung ist >vorprogrammiert. >Wer es aber richtig macht, der hat an C++ seine echte Freude. Kurz, >prägnant und weniger Gefahren eine Memory Leak zu erzeugen. Ok, da gebe ich dir recht, aber da liegt aber auch der grund warum das ding so einen fetten Overhead erzeugt. >Warum? >Wegen Destruktoren und der Möglichkeit komplexe Strukturen >komplett über den Stack zu handlen. Ja ja, bis das Ding platzt....den stack sollte man eigendlich sparsam benutzen, aber vieleicht liegt das daran das ich noch aus der Gilde der Speichersparer komme. >Und hier noch mein Vergleich: Qt und GTK >Eines davon ist in C++. Keines ist viel schneller, kleiner oder besser. Von GTK hatte ich mir allerdings auch mehr Geschwindigkeit erhofft. auch was Platzbedarf ausmacht, ist es nicht besser. da tun sich KDE (Qt) und Gnome relativ wenig, da muss ich dir recht geben. Jedenfalls ist C++ nix für kleine Maschinen (Speicher). Wer allerdings mit RAM im Gigabytebereich rumwerfen kann, der wird wirklich seinen Spaß dran haben, dann ist das nämlich egal wie aufgeblasen so ein Programm ist. Theo
Naja, teilweise bin ich deiner Meinung. C++ ist halt etwas, was man auf C aufgesetzt hat und irgendwie nichts halbes und nichts ganzes ist. Trotzdem hat es auch gute Ansätze (STL Container, Templates z.B.). Und mir ist es egal ob der Compiler dann das ganze in C-Code umwandelt, das juckt mich absolut gar nicht. Kleine Sachen programmiere ich auch lieber in C, größere Dinge sollten schon C++ sein. Auf die Spitze hat es aber Microsoft mit C++ .NET getrieben, das ist absolutes Chaos... da gibts plötzlich ne neue String-Klasse (natürlich inkompatibel mit der alten) cout funktioniert nicht mehr (weil die neue Stringklasse damit nicht zusammenarbeitet) etc. Da benutze ich dann lieber C#, da weiß man wenigstens, dass es ne neue Programmiersprache ist. Oder ich nehm halt gleich Java...
Ah, also Anfangs hielt ich den Anfangspost einfach nur für Troll-Geschrei, der Autor scheint aber wirklich daran zu glauben, was er da schreibt und das finde ich einfach ... eigentlich gibt man dazu besser keinen Kommentar ab, aber beginnen wir doch mal mit ein paar allgemeineren Dingen: 1. Alles, aber auch wirklich alles, was auf irgendeinem (heuete grbäuchlichen) Rechner läuft ist mit einer Turing-Maschine implementierbar, also ist C++ natürlich auch in Maschinencode implementierbar, alles andere wäre ja echt fatal. Das entscheidende ist, welche Schnittstelle die C++ anbietet, und zu der gehören nunmal Klassen, public, private, ..., die brint mir aber auch echt nur auf der ebene des C++ Programms etwas, was darunter geschieht ist ein komplett andere Welt! 2. "A poor programmer can produce bad code in any language!" - Das gilt für C++, C, Java, Ada, Ada95 - eben einfach alle Programmiersprachen Nun ein paar speziellere Statements: 1. Die Übersetzung von C++ nach C als "Textverarbeitung" zu bezeichnen, zeugt einfach von Unkenntnis, es handelt sich hierbei keinesfalls um "Textverarbeitung". Vielmehr geht es darum ein Programm vom abstrakten C++-Prozessor auf den abstrakten C-Prozessor zu übersetzen (angenommen es gäbe Prozessoren, die C drekt ausführen könnten, wäre es dann in deinen Augen immernoch "Textverarbeitung"?). Hierbei müssen, wie bei der Übersezung zu Maschinencode, C++-Statements in C-Statements mit identischer Semantik übersetzt werden, und das ist bei den wenigen Abstraktionmechanismen, die C im vergleich zu C++ bietet alles andere als einfach. 2. Die Brücke von relationalem SQL und Objektorientierung ist mir irgendwie schleierhaft, warum sprechen Datenbänkler sonst von relationalen und objektorientierten Datenbanken??? 3. Nur weil du ein paar Programme angesehen hast, die C++ verwenden und die nicht so toll waren, heißt das nicht, dass man in C++ keine tollen Programme schreiben kann (s. oben). Ich gebe es zu: C++ ist durchaus schwer zu erlernen und zu beherschen, man muss sich halt einfach überlegen, welche Eigenschaften der Sprache man in C++ wirklich verwenden will: Verzichtest du z.B. auf virtuelle Methodden, RTTI, Exceptions, ... ist es kein Problem Programme zu schreiben, die in ihrem Ressourcenbedarf identisch zu C sind, man verliert aber wesentlich Eigenschaften der Sprache. Mehr noch, oft implementiert man solche Sachen in C teuer von Hand nach, spitze - das kann ein Compiler mit Sicherheit besser als der Programmierer.Wer natürlich diese teuren Konstrukte unbedacht einsetzt, wird schnell ein Programm erhalten, dass aus allen Nähten platzt. 4. Mir fallen sofort zwei schöne Beispiele für effiziente C++-Programm e aus dem Betriebssystembereich ein: PURE und eCos, alles Betriebssysteme deren Kern oder die sogar komplett in C++ implementiert wurden und ja - das erste läuft sogar wunderbar auf AVRs, übrigens dürfte der Windows Kern in C geschrieben sein. 5. Sind dir in C++ eigentlich schonmal Templates aufgefallen, damit kann man ganz wunderbar und effizient typsicher programmieren - versuche das mal in C! 6. Für große Projekte ist C z.B. einfach komplett ungeeignet - warum? Weil das Modulkomzept, das in C implementiert ist, einfach lächerlich ist (nicht mal Namensräume gibt es in dieser Sprache) und den Programmierer einfach dazu einläd Unfug zu machen, z.B. stark statt lose gekoppelte Module zu entwickeln. Man muss sicherlich nicht gleich eine objektorientierte Sprache nehmen, Modula macht das z.B. auch sehr viel besser als C, aber C jetzt irgendwie als Programmiersprache für große Projekte anzupreisen war nicht so geschickt. Have a nice day, Fabian
> Ja ja, bis das Ding platzt....den stack sollte man eigendlich sparsam > benutzen, aber vieleicht liegt das daran das ich noch aus der Gilde > der Speichersparer komme. Ach ja, du behauptest aus der Gilde der Speicherspare zu kommen und würdest dir immer eine dynamische Speicherverwaltung ans Bein binden, abgesehen davon, dass die Laufzeit auch noch verbrät und man eben damit Memory Leaks erzeugt. Versuche dann doch bitte mal ein vollkommen statische Programm zu schreiben, ohne malloc-Zeug, wie weit kommst du dann ohne Stack? Ciao, Fabian
Templates sind eigendlich ne tolle Sache, aber nur oberflächlich! Man baut eine TEXT-VERARBEITUNGS-Schablone (template) für einen Algorithmus, z.B. einen binären Baum, eine verkettete Liste oder gar eine Matrix, was auch immer. Man hat nun 5 verschiedene Datentypen "int" bis "double" zu verarbeiten. C++ templates machen nix anderes als 5 mal den selben Algorithmus textuell zu codieren und dabei 5 mal einen anderen Datentyp einzusetzen. Man hat also nach der Compilation 5 mal den selben Algorithmus als Objectcode im Speicher nur weil man 5 verschiedene Datentypen verarbeiten will! Auf die Idee zu kommen einmal einen Algorithmus zu schreiben der alles an verschiedenen Datentypen verarbeiten kann, in dem er die Daten mittels void-pointer adressiert als dynamischen Container der mittels Vergleichsfunktion und der sizeof() funktion die offsets in der Struktur oder Klasse errechnet, ist anscheinend noch niemand gekommen. Aber im Gigabyte-RAM-Zeitalter ist das ja alles kein Problem mehr. Man denke mal an den Quicksort in C, qsort() da geht das offenbar alles ohne Probleme. Ausserdem, ein sauberer Programmierer weis, das man RAM-Speicher den man anfordert auch wieder abgeben muß wenn er nicht mehr gebraucht wird. Hinter den Konstruktoren verbergen sich nämlich grade bei C++ new() nichts anderes als malloc() und calloc() aus dem guten alten C. So jedenfalls im Buch von Nicolai Josuttis einem der C++ Päpste. Wenn ich weis, das ich nicht an eine FILE-Struktur heran darf so greife ich auch nicht intern mittels Tricks darauf zu, weil jede FILE-struktur bei jedem C-compiler intern vom Hersteller anders aufgebaut ist. Es ist also eine Frage der eigenen Disziplin und eben nicht der Privatisierung (encapsulation) von Daten und Funktionen. Was den Stack betrifft ist dieser im regelfall oft vom verwendeten betriebssystem Begrenzt, und wächst im regelfall on oben nach unten. das Heapsegment ist allerdings frei und kann bis speicherende wachsen. Ausserdem fällt beim stackhandling viel Kopierarbeit an wenn man call by value, statt call by reference benutzt und die kostet reichlich zeit im gegensatz nur eine Adresse zu übergeben. Last but not least: Bei SUN Microsystems (bekannt durch Solaris-Unix und Sparc-CPUs) ist derzeit ein Transpiler namens GCC2C in der Version 1.0 frei erhältlich, der C++ in reines C umwandelt, mit dem Ergebnis, das der so erzeugte C-code nach der Compilation durch einen Ansi-C-compiler ohne Änderungen schon 30% schneller läuft als das original unter einem C++ compiler..........Woran das wohl liegt ???? Theo
> Man baut eine TEXT-VERARBEITUNGS-Schablone (template) für einen > Algorithmus, z.B. einen binären Baum, eine verkettete Liste oder gar > eine Matrix, was auch immer. Das ist völliger Blödsinn - Templates bieten eine vollständige funktionale Programmierung zur Compilierzeit. Nur mal so als Hinweis: der c't-Würfel ist noch ein Begriff - dort wurden Lösungen abgegeben, die Templates benutzen und vollständig vom Compiler berechnet werden, zur Lauzeit wird nur noch eine Konstante zurück gegeben. > Man hat nun 5 verschiedene Datentypen "int" bis "double" zu >verarbeiten. > C++ templates machen nix anderes als 5 mal den selben Algorithmus > textuell zu codieren und dabei 5 mal einen anderen Datentyp > einzusetzen. > Man hat also nach der Compilation 5 mal den selben Algorithmus als > Objectcode im Speicher nur weil man 5 verschiedene Datentypen > verarbeiten will! Hier kommt zum Zuge, dass man gewisse Features mit Hirn einsetzen sollte - verwendest du Templates z.B. vor allem mit Pointern wird überhaupt kein Code dupliziert - ansonsten ist der Compiler einfach Müll. > mittels void-pointer adressiert als dynamischen Container der > mittels Vergleichsfunktion und der sizeof() funktion die offsets in > der Struktur oder Klasse errechnet, ist anscheinend noch niemand > gekommen. das mit dem sizeof zeigst du mir, wenn der Compiler anfängt Padding-Bytes einzufügen, das hier ist übriegns auch ein Musterbeispiel für schlechte Programmierung - du verletzt hier eine Schnittstelle und zwar die der Programmiersprache C! > Ausserdem, ein sauberer Programmierer weis, das man RAM-Speicher den > man anfordert auch wieder abgeben muß wenn er nicht mehr gebraucht > wird. > Hinter den Konstruktoren verbergen sich nämlich grade bei C++ new() > nichts anderes als malloc() und calloc() aus dem guten alten C. Darum ging es in meinem Post auch nicht - ich habe den Fall angesprochen, wenn man keine Speicherverwaltung hat, z.B. weil man von den 16K Flash und den 2K RAM nix für eine Heap-Verwaltung verschleudern will, dann ist der Stack neben statischen, globalen Variablen, nunmal die einzige Möglichkeit. Um Klarheit zu schaffen: natürlich sollte man z.B. greoße Arrays nicht unbedingt auf den Stack klatschen (es sei denn, man braucht sie wirklich nur in diesem Kontrollfluss). > Wenn ich weis, das ich nicht an eine FILE-Struktur heran darf so > greife ich auch nicht intern mittels Tricks darauf zu, weil jede > FILE-struktur bei jedem C-compiler intern vom Hersteller anders > aufgebaut ist. > Es ist also eine Frage der eigenen Disziplin und eben nicht der > Privatisierung (encapsulation) von Daten und Funktionen. Da gebe ich dir prinzipiell völlig Recht - der ideale Programmierer bestitzt die perfekte Disziplin - aber wir sind keine idealen Programmierer: wir machen Fehler! Solche Sachen wie Kapselung helfen uns Fehler zu finden, z.B. wenn wir Schnittstellen verletzen, das bietet dir C nicht in diesem Maße. Außerdem kostet public/protected/private ja auch keine Ressource, das wird alles komplett zur Übersetzungszeit gehandhabt. > Bei SUN Microsystems (bekannt durch Solaris-Unix und Sparc-CPUs) ist keine Sorge, ich kenne SUN, durfte mich auch schon bei SUN in Palo Alto umsehen und in unserem Serverraum verrichten vornehmlich SUN-Server ihren Dienst (zwar nicht die richtig dicken Eisen, dir brauchen wir nicht, aber die SUN X4200 finde ich auch sehr schick ;-)) > derzeit ein Transpiler namens GCC2C in der Version 1.0 frei > erhältlich, der C++ in reines C umwandelt, mit dem Ergebnis, das der > so erzeugte C-code nach der Compilation durch einen Ansi-C-compiler > ohne Änderungen schon 30% schneller läuft als das original unter > einem C++ compiler..........Woran das wohl liegt ???? das Teil kenne ich, hast du mir mal angesehen, wie alt das Teil ist, das ist von 2002 und ist ein Patch für den GCC 3.2 - abgesehen davon: klar, es ist höllisch schwer einen echt guten Compiler für C++ zu schreiben (GCC 2.95 war noch richtig grottenschlecht - polymorphe Methodenaufrufe bei Mehrfachvererbung eine Katastrophe, 3.4.x produziert schon recht annehmbaren Code und bei 4.x.x staunt man teilweise wirklich, man ist aber - auch bei kommerziellen Compilern, auch nicht beim Intel, am Ende der Fahnenstange angelangt - vorkompilierte Template implementiert meines Wissens bisher immer noch kein Compiler), aber nur weil es schwierig ist effiziente Übersetzer zu schreiben (oder wir aber nicht wissen, wie man diese Sprache effizient gebraucht) und es zu diesem Zeitpunkte noch keine gab, heißt das nicht, dass die Sprache Mist ist. Der Erfolg dieses Tools ist vor allem darauf begründet, dass der damalige Sparc-Compiler einfach Mist war, heute kräht nach dem GCC2C eigentlich kein Mensch mehr. Abegsehen davon: wenn du ein C++-Programm, dass RTTI, Polymorphismus, Exceptions, ... nach C und dann in Maschinencode übersetzt, und wir davon ausgehen, dass der Übersetzunsvorgang für C++-Code und C-Code nach Maschinencode jeweils ideal sind, dann kann keines der beiden Programme schneller sein als das andere - den idealen Übersetzer gibt es natürlich leider nicht (kleiner Punkt für dich - der ideale C-Übersetzer existiert aber natürlich auch nicht!). Ciao, Fabian
Ich kenne solche Leute wie dich. Ihr haltet euch für kreative Querdenker, seid schlussendlich aber nur bremsende Querköpfe. Leute, die ein paar Prozent Laufzeitperformance gegen robuste Programme, Effizienz und Produktivität bei der Programmierung und eine ungemein höhere Wartbarkeit eintauschen wollen, haben essentielle Punkte der professionellen Softwareentwicklung nicht begriffen. Und das soll keine Lobpreisung für C++ werden, jeder weiß um die Unzulänglichkeiten von C++, nicht wenige davon werden direkte von C geerbt (in deiner Sprache "Copy&Paste"), weitere folgen aus der rückwärts gerichteten Kompatibilität mit C. Soviel zu deinem geliebten C. Höhere Abstraktionsebenen und Automatisierung diverser Prozesse sind Konzepte von Hochsprachen vor denen du dich scheinbar fürchtest, weil der Compiler hier bessere Arbeit als du leisten könnte? Programmierer sollen sich eben nicht mit malloc() rumärgern müssen, sondern viel "weiter oben" ihr eigentliches Problem lösen. Ein Compiler ist dazu da, dem Programmierer Arbeit abzunehmen (!), deswegen soll ein Compiler und nicht die Disziplin des Programmieres die Einhaltung möglichst strikter Regeln überwachen. Zugriffsverwaltung zum Beispiel bringt doch absolut keinen Vorzug, wenn allein dem Programmierer überlassen. Aber was schreib ich hier, Leute wie du hören nicht auf Leute wie mich.
Ich befürchte von UML hältst du auch nicht viel...Da kann die einzelnen Klassen und die Beziehungen zwischen diesen zeichnen. Was für ein Programmieren...;) Einer unserer Professoren hat mal was schlaues gesagt: "Programmieren kann inzwischen jede Hausfrau. Das ist nichts schweres. Sie aber müssen nach Ihrem Studium wissen wie man ein Programm entwickelt das auch funktioniert..." Und das geht bei den heutigen komplexen Programmen nicht mehr wenn man in Assembler oder C schreibt. Man muss sich Hilfsmittel bedienen die die Abstraktionslücke zwischen den Problem (z.B. Software für Hartz4 ;)) und dem Lösungsraum (010001010-Folgen auf dem Rechner) verringert. OOP ist eine, eine weitere wird in den nächsten Jahren UML sein. Wär natürlich die Probleme der er mit Software lösen will, noch in C lösen kann. Der kann bei C bleiben. Jede Programmiersprache hat seine berechtigung.... Zitat von Dijkstra "Als es noch keine Computer gab, war das Programmieren noch relativ einfach. Als es dann ein paar leistungsschwache Computer gab, war das Programmieren ein kleines Problem und nun, wo wir gigantische Computer haben, ist auch das Programmieren zu einem gigantischen Problem geworden. In diesem Sinne hat die elektronische Industrie kein einziges Problem gelöst, sondern nur neue geschaffen. Sie hat das Problem geschaffen, ihre Produkte zu benutzen."
"Wär natürlich die Probleme der er mit Software lösen will, noch in C lösen kann. Der kann bei C bleiben. Jede Programmiersprache hat seine berechtigung...." Ha,ha,ha - dann schau Dir mal den Arbeitsmarkt an, nichts mehr mit C, nur noch C++, C# bzw. Java Programmierer gesucht. Irgendwann gibt's dann die nächste noch "bessere" Programmiersprache, ich denke da nur zurück an Pascal, das damals daa Maß der Dinge war. Fakt ist nun mal, daß C Programme ein besseres Laufzeitverhalten als C++ Programme haben. Das Ganze kommt mir vor wie bei der Markteinführung bei den Videorecordern (damals gabs 3 unterschiedliche Systeme, das schlechteste hatte sich damals durchgesetzt. Ergebnis heute: DVD Recorder sind auf dem Markt, Video ist tot; genauso wird das mit C++ enden, auch im Bereich der Mikrocontroller. Heute ist keine Effizienz mehr gefragt, da die Hardware immer besser wird; stattdessen aufgeblähte Programme mit Popup-Menüs und allerlei unsinnigen Funktionen aktivierbar per Untermenü - nein, Danke! Da es heute aber auf Klingeltöne, etc. mit allerlei bunten Menüs ankommt, werden sich die Klickibunti Experten schon durchsetzen - ob das jedem gefällt bzw. das Programm aufgrund seiner Komplexität zu kompliziert wird, ist eine andere Frage.
Cool, das driftet hier ja immer mehr ab. Windows wird halt in C++ oder C# programmiert. Da werden die Jungs gesucht. Persönliche Vorlieben lasse ich hier lieber weg. Deshalb finde ich auch die Aussage: "Fakt ist nun mal, daß C Programme ein besseres Laufzeitverhalten als C++ Programme haben." sehr plakativ. Hast Du da wirklich Fakten? Welche, und wer hat die programmiert? Hier ein kleiner Fakt von mir: Local ACM programming contest: http://www.informatik.uni-ulm.de/acm/Locals/2006/submissions2006.html Die meisten accepted Lösungen sind in C++ oder Java. Hier geht es sehr wohl um zeitkritische Probleme (zu sehen an Time-Limit exceeded). Bei C sieht man da oft den Wald wegen den Bäumen nicht. Ist eben schön, wenn ich eine Hashtable oder eine Priority Queue schon in der Standart-Library habe. Und es spart Speicherplatz wenn die nicht jedes Programm neu implementieren muss. Bei C gibt es eben nur eine Liste mit Q-sort und selbst das wissen viele nicht. Und von wegen Effizienz. Vier Mb mehr mehr Speicher kosten zwar nur ein paar Cent mehr, aber multipliziere das mal mit 10 Millionen! Desshalb muss selbst bei Klickibunti Handys ein Java-programm so klein wie möglich sein. Ach, und apropos unsinnige Funktionen: Wenn Du mit ein paar Wochen Arbeit 1% mehr (also so etwa 100000) verkaufst, dann gibt es eben noch mal ein Untermenü wo Du den Klingelton für jeden Anrufer extra einstellen kannst.
"das driftet hier ja immer mehr ab." -> kann ich nicht ganz erkennen "Windows wird halt in C++ oder C# programmiert. Da werden die Jungs gesucht." -> das Schlechteste System setzt sich eben immer durch, weil sich die Leute vom Marketing blenden lassen ... womit wir wieder beim Thema sind: C++ oder die lukrativen Lügen der Softwareindustrie "Hast Du da wirklich Fakten? Welche, und wer hat die programmiert?" Aber sicher doch! 1. http://www.c-plusplus.de/cms/modules.php?op=modload&name=mbBooks&file=index&func=isbn&isbn=3893193766 Kauf Dir die C und die C++ Version des Buches und mach selbst den Test. Mein Tip: Spar die Mühe und schau Dir 4. an! 2. C++ ist eine Obermenge von C; wie sollen die Instruktionen einer Obermenge gleich schnell oder gar schneller umgesetzt werden? Kannst Du mir diese Paradox mal erklären?! 3. Hier hat sich einer mal die Mühe gemacht: http://www.blindschleiche.de/shownews.php3/120 3. komplexere Programme in reinem C: http://www.dillo.org/ mach mal den Browser-test in Bezug auf Schnelligkeit! Funktionsumfang ist eine andere Sache, schon klar. 3. Hier hat sich einer mal die Mühe gemacht: http://www.blindschleiche.de/shownews.php3/120 Lad Dir die PDF Datei herunter und schau Dir die Performance-Vergleiche der Diagramme ab Seite 14 folgende genau an. C schneidet gegenüber C++ bis auf eine Ausnahme in den Laufzeiten besser ab. Schlimmer aber noch (für Euch als C++ Anhänger), es gibt inzwischen Skriptsprachen, die bei vereinfachter Programmierung um Faktor 2 die gleiche Arbeit tun - damit wird das Argument der Einfachheit gegenüber C über Board geworfen; wenn Laufzeiten für Euch keine Rolle spielen und sich ein Programm mittels Skriptsprache um den Faktor 2 schneller entwickeln läßt, wählt man doch den Zeitvorteil - das nennt man Fortschritt. Jetzt Dein supertolles Beipiel: Local ACM programming contest: http://www.informatik.uni-ulm.de/acm/Locals/2006/submissions2006.html contest heißt Wettbewerb und den Rest kann man sich wohl denken ???!!! Je nach Tagesverfassung und Können des jeweiligen Programmierers entsteht da (womöglich auch noch unter Zeitdruck) ein Programm. Klar, daß da C++ als Sieger abschneidet. Daß C schwieriger zu programmieren ist als C++ mag ja sein, nur dann die Schlußfolgerung zu ziehen, sich nicht mehr mit C befassen zu müssen, sondern gleich auf c++ zu gehen nur weil das einfacher in der Programmierung sein soll, hinkt doch gewaltig. Welche grandiosen Vorteile gibt es nun, außer das man diese Sprache eben "noch" für Windows braucht und diese Sprache in einigen Nischenbereichen noch führend ist ?! Ich stufe c++ eher als eine Übergangssprache ein, die ähnlich wie Pascal mittelfristig verschwinden wird - man sollte sich überlegen, ob es dann Sinn macht, sich damit überhaupt eingehend zu beschäftigen. "Und von wegen Effizienz. Vier Mb mehr mehr Speicher kosten zwar nur ein paar Cent mehr, aber multipliziere das mal mit 10 Millionen! Desshalb muss selbst bei Klickibunti Handys ein Java-programm so klein wie möglich sein." ->Schlag mal bei ein paar alten c't Zeitschriften nach und schau Dir die Rechnerentwicklung an oder schauh Dir nur mal die rasente Entwicklung im Bereich der Speicherchips an im letzten halben Jahr an, das Problem speicherminimaler Programme wird sich sehr schnell von selbst erledigen. "Ach, und apropos unsinnige Funktionen: Wenn Du mit ein paar Wochen Arbeit 1% mehr (also so etwa 100000) verkaufst, dann gibt es eben noch mal ein Untermenü wo Du den Klingelton für jeden Anrufer extra einstellen kannst" Das wär ja noch eine halbwegs vernünfigtes Programm :-) Nur das ganze Programmkonzept ist doch der Wahnsinn - durchhangeln durch etliche Untermenüs, um endlich mal etwas richtig einstellen zu können - den Kiddies macht das vielleicht Spaß (das sind ja auch die Endkonsumenten) ich sag nur: ätzend programmiert.
kleiner Fehler, 3. ist mehrfach vorhanden, da ich noch was reingepostet und nicht gelöscht habe und nicht umbenannt habe in 4.
Damits auch richtig OT wird Java vs. Net vs C/C++ bei numerischen Problemen http://www.shudo.net/jit/perf/ SciMark: Visual C 329 MFlops Sun JDK 1.4.2 Server VM 324 MFlops icc 306 MFlops C#, Net 1.1 240MFlops Sun JDK 1.5.0 Client VM 199 MFlops Unterschied bester Compiler/bester JIT ~1% Linpack: icc 402 MFlops Visual C 399 MFlops C#, Net 1.1 382 MFlops Sun JDK 1.4.2 Server 379 MFlops. Sun JDK 1.5.0 Client VM 339 MFlops Differenz "" ~5% Zur Effizenz bei der Programmierung mal ein paar SLOCS/Function Point-Werte (die Datenbasis umfasst über 7000 Projekte, wobei der größte Teil zw. 10T und 300T ESLOCs liegt, etliche auch über 1000T ESLOCs) Avg Median Ada 154 C 148 104 C++ 60 53 C# 59 59 Java 60 59 Smalltalk 35 32 http://www.qsm.com/FPGearing.html
Also gut. Ihr habt mich überzeugt. Hier meine persönliche Wahl der Programmiersprachen: Assembler: Wenn möglich nie C: Für Programme unter 1000 Zeilen ohne viel Algorithmen C++: Für alles, für das ich kein Perl nehmen kann Perl: Nur mit strict und -W, dann aber für soviel wie möglich. Java: Wenn es GUI haben muss, und Platform kompatibel. Python: Sobald sie sinnvolle Syntax checks bauen probiere ich es nochmal Alles andere nur in Ausnahmefällen. Und nochmal was: Ich suche mir lieber einen guten Programmierer aus, als eine gute Programmiersprache.
Nur dazu: > 2. C++ ist eine Obermenge von C; wie sollen die Instruktionen > einer Obermenge gleich schnell oder gar schneller umgesetzt > werden? Erstens ist C++ keine Obermenge von C, da die meisten C-Programme von einem heutigen C++-Compiler zurückgewiesen werden. Aber das weißt du bestimmt. Bei C++ ist das Schöne, dass du die ganzen Features, die es im Vergleich zu C mehr bietet, nicht nutzen musst. Solange du die nicht nutzt, hast du genau 0,0% Overhead im Vergleich zu C. Soviel also zu dem vermeintlichen "Paradoxon". Wenn du die C++-Features allerdings nutzt, sieht es anders aus: Dann gewinnt häufig C++. Denn zu z.B. Polymorphie oder Exceptions äquivalente Funktionalitäten müsste man in C eben "per Hand" implementieren, was man höchstwahrscheinlich nicht so gut hinbekommt wie ein heutiger C++-Compiler. Außerdem wird ein Compiler besser werden, deinen C-Code wirst du jedoch erstmal nicht so gerne verbessern wollen, wenn er "akzeptabel läuft". Meine Erfahrung ist, dass sogar schon bei 20-Zeilern C++ schneller als C ist, sowohl in der Entwicklung als auch in der Ausführung. Denn die C++-Features kosten nichts, solang du sie nicht nutzt. Du kannst dir also gezielt die raussuchen, die dir etwas nutzen, ohne teuer zu sein.
"3. Hier hat sich einer mal die Mühe gemacht: http://www.blindschleiche.de/shownews.php3/120 Lad Dir die PDF Datei herunter und schau Dir die Performance-Vergleiche der Diagramme ab Seite 14 folgende genau an. C schneidet gegenüber C++ bis auf eine Ausnahme in den Laufzeiten besser ab. (...) contest heißt Wettbewerb und den Rest kann man sich wohl denken ???!!!" Dein angegebener Link scheint dem Text im pdf nach auch 'nur' ein Wettbewerb zu sein, denn der Autor hat auch Programme von mehreren anderen Leute die sich dort beteiligt haben herangezogen. Damit erklärst du diesen Vergleich selbst für nichtig.
"Erstens ist C++ keine Obermenge von C da die meisten C-Programme von einem heutigen C++-Compiler zurückgewiesen werden. Aber das weißt du bestimmt." -> Nein, ist mir neu, da ich mich nicht so eingehend mit C++ beschäftigt habe - danke für die Aufklärung - im Web wird das zumindest verschiedentlich so behauptet, aber es sind dann wohl ältere Compiler-Versionen gemeint ?! Sind diese neueren Compiler eigentlich noch ANSI compatibel? Bei C++ ist das Schöne, dass du die ganzen Features, die es im Vergleich zu C mehr bietet, nicht nutzen musst. Solange du die nicht nutzt, hast du genau 0,0% Overhead im Vergleich zu C. Soviel also zu dem vermeintlichen "Paradoxon". -> das mag natürlich stimmen (insbesondere bei kleineren Programmen), nur dann kann ich ja auch bei C bleiben, oder aber C# verwenden, daß ja möglicherweise noch mehr Features aufweist, die ich nicht nutzen muß und ich bin auf dem neuesten Stand. (Ich kenne die Möglichkeiten von c# nicht, wer weiß mehr?) Wenn du die C++-Features allerdings nutzt, sieht es anders aus: Dann gewinnt häufig C++. Denn zu z.B. Polymorphie oder Exceptions äquivalente Funktionalitäten müsste man in C eben "per Hand" implementieren, was man höchstwahrscheinlich nicht so gut hinbekommt wie ein heutiger C++-Compiler. -> okay, 1:0 für Dich; schwieriger wird das mit Sicherheit, nur dann kann man auch überlegen z.B. auf das plattformunabhängige Java auszuweichen. Außerdem wird ein Compiler besser werden, deinen C-Code wirst du jedoch erstmal nicht so gerne verbessern wollen, wenn er "akzeptabel läuft". -> es sollte dann ja auch normalerweise reichen, wenn man sein Zielvorstellungen erreicht hat Im übrigen müssen die Compiler-Entwickler ja den vorgegebenen ANSI Standard für C++ nach Möglichkeit noch einhalten, irgendwo wird sicher auch da mal das Ende der Optimierung eines Compilers erreicht sein. Dann gibt es auch immer wieder mal überraschende Neuauflagen alter Programmiersprachen mit verbesserten Compiler, siehe http://www.m3.org/ (Danke Theo für den Link) Insofern wär ich da vorsichtig C++ als das NonplusUltra darzustellen. "Meine Erfahrung ist, dass sogar schon bei 20-Zeilern C++ schneller als C ist, sowohl in der Entwicklung als auch in der Ausführung. Denn die C++-Features kosten nichts, solang du sie nicht nutzt. Du kannst dir also gezielt die raussuchen, die dir etwas nutzen, ohne teuer zu sein." -> Wenn man Erfahrung hat kein Problem; aber auch hier stellt sich mir die Frage, ob es dann nicht sinnvoll ist gleich auf die Nachfolgesprache C# überzuspringen, das wär ja dann die logische Konsequenz. Dein angegebener Link scheint dem Text im pdf nach auch 'nur' ein Wettbewerb zu sein, denn der Autor hat auch Programme von mehreren anderen Leute die sich dort beteiligt haben herangezogen. Damit erklärst du diesen Vergleich selbst für nichtig. -> wenn es so, ja; ich hab die Datei nur schnell überflogen, werd aber noch mal nachschauen. Es ist leider schwer was zu finden. Dann müßtest Du nur noch das Beispiel von arc wiederlegen und ich gebe mich geschlagen, was nachweisbare Beweise angeht: Avg Median Ada 154 C 148 104 C++ 60 53 C# 59 59 Java 60 59 Smalltalk 35 32 http://www.qsm.com/FPGearing.html Vielen Dank übrigens für diesen OT Vergleich, war ganz aufschlußreich in Bezug auf neuere Programmiersprachen.
> Dann müßtest Du nur noch das Beispiel von arc wiederlegen und ich > gebe mich geschlagen, was nachweisbare Beweise angeht: > > Avg Median > Ada 154 > C 148 104 > C++ 60 53 > C# 59 59 > Java 60 59 > Smalltalk 35 32 Da ich nicht weiss was ein 'Function Point' ist, ist es schwer zu erkennen was diese Tabelle exakt aussagt. Aus dem Text auf der Seite ist das auch nicht so klar erkennbar. Ich denke allerdings dass es sich hier um sowas wie 'Wieviele Lines of Code braucht man für eine Funktionseinheit' handelt. Mit anderen Worten: je kleiner, desto besser. Diese Interpretation wird auch dadurch unterstützt, dass der bei weitem höchste Wert von Assembler erreicht wird. Und wir alle wissen, dass Assembler am geschwätzigsten ist. Interessant sind allerdings die extrem hohen Werte für ADA und C. Wobei die Min und Max Werte für C einen wesentlich grossen Bereich abdecken als bei allen anderen. Ich würde das mal so interpretieren: In C gibt es einen grossen Spielraum zwischen guten und schlechten Programmierern: Die guten sind extrem gut und die schlechten sind extrem schlecht. Bei C++ ist der Bereich wesentlich kleiner. Mit anderen Worten: Die schlechten Programmierer schaffen es in C++ wesentlich bessere Programme zu schreiben als die schlechten Programmierer in C. Der Unterschied auf der 'guten' Seite ist hingegen bei weitem nicht so gravierend: Ein guter C Programmierer braucht auch nicht wesentlich weniger Code als ein guter C++ Programmierer. Und im Mittel sind C++ Programme kürzer als C Programme. Das deckt sich im übrigen mit der Erfahrung die die meisten C++ Programmierer gemacht haben. Ein guter C++ Programmierer erzeugt Code, der: kürzer ist als ein funktional äquivalenter C Code. meist schneller ist als ein funktional äquivalenter C Code. Warum betone ich: funktional äquivalent dermassen stark? Weil in den meisten Vergleichen es eben nicht so ist, dass funktional äquivalenter Code verlgichen wird. Die Grundfunktionalität ist bei solchen Vergleichen meist tatsächlich entsprechend. Wenn es aber dann darum geht, dass das Programm auch mit Fehlersituationen umgehen können muss, dann sieht es bei den meisten C Programmen mehr als düster aus.
>Das deckt sich im übrigen mit der Erfahrung die die meisten C++ >Programmierer gemacht haben. Ein guter C++ Programmierer erzeugt >Code, der: >kürzer ist als ein funktional äquivalenter C Code. Optisch vieleicht, aber sicher nicht im Compilat! Allein schon die C++ header sind schon ein Molloch für sich. Die Zweifel steigen, weil ich den vergleich C - Modula3 gelesen habe, wo der Autor mit "hello world" auf 335 kb Code kam, wärend er einen Amigasystem samt grafischer Oberfläche 250 kb hatte. >meist schneller ist als ein funktional äquivalenter C Code. Ebenfalls zweifelhaft, vieleicht wenn man nur C in C++ benutzt, aber nicht den anderen Firlefanz. Aber nehmen wir das mal als richtig an, was kostet das dann an Speicher ? >Warum betone ich: funktional äquivalent dermassen stark? >Weil in den meisten Vergleichen es eben nicht so ist, dass >funktional äquivalenter Code verlgichen wird. Die >Grundfunktionalität ist bei solchen Vergleichen meist tatsächlich >entsprechend. Wenn es aber dann darum geht, dass das Programm auch >mit Fehlersituationen umgehen können muss, dann sieht es bei den >meisten C Programmen mehr als düster aus. Ist dir schonmal aufgefallen das viele HochsprachenCompiler oftmals weit grösser sind als reine C-Compiler ? Das liegt daran das man viel bzgl. der Sprachsicherheit in diese Compiler seitens der Konzeption gesteckt hat, was bei C meist wegfällt. Wer das in C auch haben will, kann den Syntax-Checker "lint" nehmen (standart unter Unix), der nörgelt fast alles an und lässt schnell Erinnerungen an Pascal hochkommen, nur das das Ding nicht die Programmausführung verweigert oder unterbindet, bis der letzte unsaubere Trick beseitigt ist. Oder mit anderen Worten, diese verschärfte Prüfung hat man auf kosten der Unsicherheit bei dem einfachen C-Check weggelassen. Man kann es ggf. auch mit CINT programmieren, einem C/C++ Interpreter, der sich lt. aussage der Ersteller auch gut zum lernen eigne. http://root.cern.ch/root/Cint.html Was mir allerdings bei C++ auffiel ist das diese Syntaxprüfung weit schärfer ist als bei C. Selbst Kleinigkeiten nörgelte der Compiler an, was man aber je nach Hersteller abschalten kann. Man könnte also sagen das die nix anderes gemacht haben, als wegen C++ nen erweiterten "lint" in den Präprozessor eingebaut zu haben. Meine Meinung zum Thema ist, das es besser ist viele kleine bis mittlere Module sauber zu entwickeln, das kann man ruhig in C machen, diese gründlich zu testen und dann zu linken mit passende *.h Dateien. Das wird mit Sicherheit viel kleiner als alles Marke STL. Jedenfalls finde ich das besser als hinter dem Rücken des Programmierers eine heimliche Textersetzung weit über das Maß von Makros hinaus zu betreiben und das dann als Innovation zu verkaufen. Ich mag grundsätzlich nicht bezweifeln das ein moderner C++ Compiler weit mehr Sicherheiten bietet, als ein gewöhnlicher C-Compiler ohne "lint", allerdings werde ich das Gefühl dabei nicht los, das das am Ende auf Kosten des Laufzeitsystems geht (Speicherverbrauch), eigentlich das, was andere Sprachen schon bei der Entwicklung abfangen, wie die beispiele C/C++ versus Modula-3 zeigen. Ergänzend kann ich nur sagen, das ich C mangels Geld für edlere Maschinen noch in der späten MSDOS-Ära (win3.11/win95) auf ebensolcher Kiste im Dos-Mode gelernt habe (TurboC 2.0) wobei ich die Kiste öfter mal abgeschossen habe (Lehrgeld). Mit TurboPascal ist mir das beim Lernen der Sprache Vers.5.0, als auch bei deren Anwendung fast nie passiert. Meist war meine Unachtsamkeit schuld, weil Pascal einem Trivialfehler meist meckernd vor die Nase gehalten hat und nicht eher lief bis das Bemeckerte korrigiert war und vieleicht ist diese Strenge sogar auch für erfahrene Programmierer immer noch gut, gerade bei sehr großen Projekten mit vielen Teilnehmern Was Geschwindigkeiten betrifft: QuickSort auf 30.000 Random-Integer's unter MSDOS, 1 MB RAM, 286-Prozessor, 10 MHz Takt: Getestet die rekursive Variante, (es gibt auch eine iterative) TPascal 5.0 ~ 5,5 sec. TC 2.0 OHNE Registervariablen (Laufindex) ~ 5,5 sec TC 2.0 MIT Registervariablen (Laufindex) ~ 4,5 sec TC-2.0 mit BuildIn qsort() ~ 4 sec. ...and the winner's are: Stony Brook Pascal-Compiler ~ 3,1 sec. Borlands-X86 TurboAssembler ~ 3,0 sec. Stony Brook Homepage (Übergangsweise weiter unten): Bei Pascal schienen die wohl bei bei Win95 vers.7.0 Schluss gemacht zu haben.ggf kann man bei denen auch Ada bekommen. Wie die Daten oben zeigen war der Code den der Stony PascalCompiler damals erzeugte extrem schnell (fast wie Assembler). Dann bieten die hier bei Modula gezeigt, auch portable GUI's für Windows, Unix, MacOS an. http://www.modula2.org/sb/websitearchive/productinfo.htm Noch Wünsche in Sachen Sprachen ? Es muss also nicht immer Borland, GCC, oder Microsoft sein.... Und außerdem muss schon garnicht das Bekannteste das Beste sein!!! Man sieht also, das es nicht an einer Sprache als solcher liegt, wie schnell was läuft, sondern eher wie sauber und effizient der Compiler ist. Eindrucksvoll hat das ja auch die Liste mit den C/C++ und JAVA-Compilern gezeigt wo grade mal ~5% Unterschiede zu verzeichnen waren. Und 5% merkt man nicht mal auf meiner jetzt wieder uralten PII-Kiste. Vorteilhaft finde ich bei der Java, das es plattform-portabel ist, wärend C/C++ immer wieder etliche Hilfsbibliotheken brauchen, insbesondere was die Menüerstellung betrifft, denn man möge mir mal zeigen, wie man Visual-C++.Net Quellcode ohne Änderungen direkt auf einer Solaris-Maschine via Rekompilation mit dem C++SUN-Compiler zum laufen bekommt ? Wer das drauf hat, dürfte als bald sehr reich werden... Alternative wären unter vielen anderen die Stony-Brook Compiler: Was mich allerdings bei den Marktanteilen wundert ist, weil Microsoft immer noch gut ~80% der reinen PC-Clientsysteme bestückt, (Linux ~ 10-15% / Rest andere wie Solaris, MacOS-X), das noch niemand auf den Trichter kam, den Microsoft C/C++ Dialekt auf andere Zielmaschinen zu portieren, was eine 1:1 Übersetzung zumindest bei den grafischen Menüs ermöglicht, sozusagen ein Nachbau der MFC - Befehle auf Unix. Umgekehrt von Linux Richtung Microsoft findet man allerdings einiges davon, z.B. minGW für gtk2 auf Windows oder die Qt von trolltech usw. Alternativ und kostenfrei bietet sich: www.japi.de an, nicht zuletzt weil Java in den vergleichen recht gut abgeschnitten hat. langsam kann das nicht sein, denn wenn die JVM als Interpreter im Hintergrund nur die grafischen Maschinenroutinen aufruft, und das alles unter einem Pentium-1 mit 90 MHz und 32 MB RAM ordentlich läuft, so der Autor. Außerdem gibt's heute kaum einen DesktopRechner bei dem keine JVM läuft, weshalb man sich deren Dienste eigentlich nutztbar machen sollte, auch dann wenn mit anderen Sprachen als Java programmiert wird, so das Ziel von JAPI, denn so bleiben unter MS entwickelte Programme auch unter Solaris oder Linux 1:1 übersetzbar. Und was das Einspielen von UNIX-Systemen betrifft, ist grafische Installation keinesfalls 'ne Erfindung von Microsoft oder später Linux, sondern sowas gabs schon zumindest meiner Erfahrung nach 1994-95 bei Solaris 2.6 auf Sparc-Maschinen samt sofortiger voller Auflösung im InstallationsModus, direkt beim reinpfeffern der CD. Nur das gab's bei der Solaris-Intelvariante damals natürlich nicht! Das selbe bei optischen Mäusen bei Sparc's absoluter Standart samt SCSI-Platten. Optische Mäuse kamen bei Microsoftmaschinen so ab Jahr 2000 mit ins Paket. Woher ich wissen ? Ich hatte seinerzeit das Glück Mitte der 90er für eine kurze zeit während eines 1,5 Jährigen Studentenjobs an der Fern-Uni Hagen so wie mir die Mitarbeiter sagten, die schnellste SUN der ganzen Uni zu haben. Das Ding wurde geliefert und ich sollte Solaris installieren als totaler Unix-Novize!.....holla! Dual-Sparc CPU mit 128 MB Ram, die anderen hatten nur eine CPU mit 64 MB, aber alles an sehr anspruchsvollen Anwendungen lief auf den Dingern, was heute überhaupt nicht mehr denkbar ist. Selbst grafisch recht anspruchsvolle WySiWyG-Textsysteme wie FrameMaker unter Unix, wo die Doc's und Prof's ihre Proceedings samt Grafiken schrieben, zu einer Zeit wo Microsoft-Word, grade mal für nen Bewerbungsschreiben oder ne Einkaufsliste taugte. Einziger Wehmutstropfen bei den Sparc's damals: Man musste noch mit einem normalen Editor meistens Xedit arbeiten (zum Glück kein vi) und dann von Hand via Konsolefenster per Kommandozeilen-Befehl Modula-2 compilieren, da die Uni derzeit noch keine IDE-Systeme angeschafft hatte. Da war dann in Sachen Bequemlichkeit T-Pascal besser, wenn auch nur im TextMode unter DOS. So programmierte man dann zu hause vor, in T-Pascal bis alles lief und änderte nur an der Sparc auf Modula ab, weil beides sehr ähnlich ist, und dann passte das meistens um sich nicht mit Xedit und Konsole herum schlagen zu müssen. Und da kam doch immer, so alle paar Tage ein mit mir angestellter Uni-DO-Student in meine BüroBude und fragte ob ich ihm ne verkette Liste programmieren könnte, er wüsste das nicht, obwohl in Semester 10! Aber von abstrakten theoretischen Papier-Automaten Marke Turing hatte der Gute ne Menge Plan....:-) Theo
"eine CPU mit 64 MB" da musste ich erstmal lachen...
> Das liegt daran das man viel bzgl. der Sprachsicherheit in diese > Compiler seitens der Konzeption gesteckt hat, was bei C meist > wegfällt. Unsinn. Ich rede nicht vom Compiler sondern von den fertigen Endprogrammen. Das liegt einzig und alleine daran, dass C Programmierer faule Hunde sind (wie alle Programmierer). Fehlerwerten nicht abzufragen und entsprechend zu reagieren ist bei denen sehr oft einfach nur ein Kavaliersdelikt. > Meine Meinung zum Thema ist, das es besser ist viele kleine bis > mittlere Module sauber zu entwickeln, Da stimme ich absolut zu > das kann man ruhig in C machen, Du hast offensichtlich noch nie ein Industrieprojekt gemacht. Sonst wüsstest du, dass bei einige zig-tausend LOC das Ganze in C einfach nur noch der Horror wird, egal wie sauber du arbeitest. Tut mir leid, aber dein Micky Mouse Program zur Diplomarbeit zählt noch nicht als mittleres Program. Für die meisten Industrie- programmierer ist das immer noch ein Winzig-Programm. Der grosse Vorteil von C++ ist nicht die Code-Size oder die Dinge auf die du da rum reitest, sondern dass dir C++ Möglichkeiten in die Hand gibt, grosse Projekte im Griff zu behalten.
> Jedenfalls finde ich das besser als hinter dem Rücken des > Programmierers eine heimliche Textersetzung weit über das Maß von > Makros hinaus zu betreiben und das dann als Innovation zu verkaufen. Sag mal. Was lernt mein eigentlich im Studium heutzutage. Jeder Compiler (mit Ausnhame vielleicht von Prolog) ist letztendlich nur ein Textersetzer: Er ersetzt den Quelltext durch funktionsgleichen Maschinencode. Das ist aber auch nicht der springende Punkt. Der springende Punkt ist: Welche Möglichkeiten ich mit dieser 'Textersetzung' kriege und welche Abstraktionsebenen sich eröffnen.
> Und außerdem muss schon garnicht das Bekannteste das Beste sein!!!
Wer bitte sagte, dass C++ das Beste seit geschnittenem Brot ist?
Niemand, das sagst nur Du. Selbst die C++-Gurus wissen, und
diskutieren offen darüber, dass es in der Sprache mehr als eine
einzige Problemstelle gibt.
> das noch niemand auf den Trichter kam, den Microsoft C/C++ Dialekt > auf andere Zielmaschinen zu portieren, Aehm. C++ ist seit 1998 genormt. Es gibt einen ISO/ANSI Standard der genau (na ja) beschreibt, was C++ ist und was nicht. Und jetzt wirst du lachen: Microsoft hat in den letzten Jahren enorme Anstrengungen unternommen seinen Compiler ISO/ANSI konform zu machen. Die Ergebnisse sind sehr gut. > was eine 1:1 Übersetzung zumindest bei den grafischen Menüs > ermöglicht, sozusagen ein Nachbau der MFC - Befehle auf Unix Jetzt disqualifizierst du dich selbst. Es ist sinnlos mit dir zu diskutieren da du von C++ keine Ahnung hast. Du hälts eine herstellerspezifische Bibliothek für C++ selbt. Wenn du von C++ nur ein bischen Ahnung hättest (und zb. mal für 2 Wochen in comp.lang.c++ mitgelesen hättest) dann wüsstest du, dass in C++ nichts, aber auch gar nichts, was auch nur irgendwie hardwareabhängig sein könnte oder in die Kategorie 'Benutzer- schnittstelle' fällt, in der Sprache selbst definiert ist. C++ hat für I/O streams und das wars dann auch schon. Alles weitergehende wird über herstellerspezifische Libraries geregelt. Und tschüss.
Und wieder mal bewahrheitet sich der Spruch: "Software ist komplizierter als Wurst" Ja Theo, es reicht eben bei C++ nicht aus, einfach irgendwo drauf zu drücken, damit was raus kommt.
" Ich denke allerdings dass es sich hier um sowas wie 'Wieviele Lines of Code braucht man für eine Funktionseinheit' handelt. Mit anderen Worten: je kleiner, desto besser." Hört sich stark danach an. Bloss wie ermittelt man soetwas bei HTML?? Ausserdem, was ist es für ein Schwachfug seine Software nach einer möglichst gleichmäßigen Funktionslänge zu optimieren, wie auf der Seite empfohlen. Scheint eher, dass ein paar Esoterik-Freaks sich von den Atomstromfiltern zur Programmierung gewandt haben um dort ihren Unfug zu treiben. "Ebenfalls zweifelhaft, vieleicht wenn man nur C in C++ benutzt, aber nicht den anderen Firlefanz. Aber nehmen wir das mal als richtig an, was kostet das dann an Speicher ?" C++ läßt sich durch reine Textersetzung zu C umwandeln (+ ein bisschen zur Compilezeit prüfen obs erlaubt ist). Warum sollte C++ langsamer sein, als ein C Code, der die gleiche Mächtigkeit hat? ">kürzer ist als ein funktional äquivalenter C Code. Optisch vieleicht, aber sicher nicht im Compilat! Allein schon die C++ header sind schon ein Molloch für sich." Un noch einmal disqualifiziert... Wo vergrößern C++-Header denn das Compilat? @Theo Verrat uns mal, was du denn studiert hast..
Programmiersprachen sind nur Werkzeuge für Programmierer. Man muss halt wissen für welche Projekte oder Projektteile welches Werkzeug am geeignesten ist. Für eine kleine 'Hello World' Konsolenapplication würde ich Pascal oder C nehmen, klar. Vielleicht zusammen mit einer MatLab Visualisierung und Datenerfassung mit LabView etc... Warum soll ich mich abrackern mit TCP/IP oder anderen tausendmal geschriebenen Sachen die im Betriebssystem stecken wo es ein .NET etc. Framework gibt? Stellt euch die APIs von Betriebssystemen mit einem 'flachen' (ohne Klassen und/oder Namespaces) -Framework vor? Bei grösseren Projekten mit mehreren Entwicklern ist C++ eine feine Sache, grade weil man die Anderen nicht nur Module (bzw. Funktionen) schreiben lassen kann, sondern Aufgaben: Projektteile (Objekte) mit einem schmalen Interface. Beim µC programmiere ich einzelne Funktionen gerne Assembler, dann eventuell einen schönes C-Outfit drumherum... Kommunikationspartner zum Debuggen ein PC mit einem schnell zusammengeklickten Delphi-Programm (mit Object-Pascal ;) ) Alle Sprachen machen nur einen Compilierten Datenbrei, in manchen Sprachen bekommt man das halt schneller hin, andere sind länger, andere langsamer etc... Wichtig sind halt auch die Quelltexte: Übersichtlichkeit, Funktionalität, Design erkennber (falls man für ISO zertifizierte Unternehmen programmiert nicht zu unterschätzen), erweiterbar, evtl. portierbar...
>> [C++ ist nicht Obermenge von C] > -> Nein, ist mir neu, da ich mich nicht so eingehend mit C++ > beschäftigt habe - danke für die Aufklärung - im Web wird das > zumindest verschiedentlich so behauptet, aber es sind dann > wohl ältere Compiler-Versionen gemeint ?! Der folgende Link zeigt z.B. auf eine ganz gute Seite, die die Unterschiede zwischen aktuellem C und aktuellem C++ erklärt: http://david.tribble.com/text/cdiffs.htm Es gibt inzwischen so viele Unterschiede, dass C und C++ IMHO sehr berechtigt als zwei nebeneinander existierende, unabhängige Sprachen zu betrachten sind. Die Seite vergleicht das "neueste" C (C99) mit dem aktuellen C++ (C++98). Bei früheren C-Versionen waren die Unterschiede zu C++ zwar etwas geringer, z.B. gab es keine variablen Arrays auf dem Stack, aber sie waren dennoch zahlreich vorhanden. Eines der einfachsten Beispiele ist wie immer malloc. In C würde man schreiben: char* bytes = malloc(1024); In C++ dagegen benötigt man dort zwingend einen reinterpret_cast, weil malloc einen void-Pointer liefert: char* bytes = reinterpret_cast<char*>(malloc(1024)); Ein C-Style-Cast ginge für C++ hier natürlich auch, aber in C wird eben gar kein Cast benötigt. Daher wird dieser häufig weggelassen, was den Code aber für einen C++-Compiler ungültig werden lässt. Ein anderer, vielleicht noch offensichtlicherer Punkt sind die neuen Keywords, die C++ im Vergleich zu C besitzt. In C darf man eine Funktion problemlos "export()" oder eine Variable "new" nennen, was in C++ nicht mehr funktioniert.
Ein paar Dinge zu den Function-Points: - sind eine Software-Metrik die ursprünglich Ende der 70er bei IBM entwickelt wurden - sind mittlerweile ein ISO-Standard (ISO/IEC 20926) - haben nichts mit Esoterik zu tun (ausser man vergleicht Software aus völlig unterschiedlichen Bereichen) - Function-Points sind nicht Funktionen oder Methoden - auch HTML bzw. GUIs allgemein lassen so bewerten http://www.ifpug.com/fpafund.htm http://www.ifpug.com/Function%20Point%20Training%20Booklet%20New.pdf
Hier lesen: http://de.wikipedia.org/wiki/Standard_Template_Library Da steht wörtlich: { Die bei HP entwickelte STL geht auf sehr alte Wurzeln zurück. Schon 1971 gab es erste Entwürfe generischer Bibliotheken von Dave Musser. 1979 begann Alexander Stepanov mit der Entwicklung seiner Ideen auf diesem Gebiet. Die Umsetzung in einer großen Programmiersprache erfolgte jedoch erst 1987 mit der Programmiersprache Ada. # Und das 7 Jahre vor C++! Stepanov und Meng Lee, damals Mitarbeiter bei Hewlett-Packard, nannten die von ihnen entwickelte Programmbibliothek STL. Später wurde diese Bibliothek gemeinfrei. Danach, im Jahr 1993, also zu einer Zeit als sich C++ noch in einem frühen Entwicklungsstadium befand, stellten sie die Bibliothek dem C++-Standardisierungskomitee vor, das daraus im Laufe der Zeit einen konkreten Vorschlag zur Aufnahme in die Programmiersprache C++ ausarbeitete, was schließlich zur Integration führte. } ADA kennt generische Datentypen und zwar schon seit 1987. Ergo kann man davon ausgehen das ADA-95 diese sauber verinnerlicht hat und dies bei ADA-2005 noch weiter ausgebaut wurde. Der zu lesende Negativartikel das es nur wenige Entwicklungswerkzeuge für ADA gibt ist eher darauf zurück zu führen, das ADA nicht so stark auf kleinen Signalprozessoren gerade in der Haushaltselektronik vorhanden ist. Schliesslich kann nen Handy nicht alleine aus 10.000 Metern höhe abstürzen oder ne Waschmaschine an irgend ne Raumstation andocken..:-) Wenn ich also mal sporadisch kombiniere, frage ich mich wenn es das die STL 1987 unter ADA schon gab, mit einem Sicherheitstandart an den C/C++ nicht ran kommen, warum ist die Situation heute dann so wie sie ist ? Die Ada-Entwickler können in dieser Richtung keinesfalls geschlafen haben, denn die haben ach die Weiterentwicklung der Bibliothek unter C++ beobachtet um evt. neue features gleich in die generische Bibliothek von Ada zu übernehmen. Das ADA diese generischen Möglichkeiten eingebaut hat, weit und lange vor C++, erklärt auch die hohe Effizienz der Sprache gegenüber C geschweigedenn C++ und Java, über die sich Karl Heinz wunderte. Die diskussion wäre kürzer gewesen wenn man sofort in der Wikipedia nachgesehen hätte! http://de.wikipedia.org/wiki/Ada_(Programmiersprache) Und was ADA und ARIANE-5 betrifft steht da wörtlich Meine Kommentare hinter # { Doch solche Spracheigenschaften alleine können offensichtlich Fehler nicht verhindern: Eine Ariane 5 der ESA ging durch einen arithmetischen Überlauf verloren, weil der entsprechende Test ausgeschaltet worden war. Allerdings war das nicht die Schuld der Programmiersprache: Das Management des Programms hatte verlangt, Code, der für Ariane 4 geschrieben worden war (und dort auch korrekt war), ohne weitere Überprüfung der Voraussetzungen zu übernehmen. # Klingt wie bei Eschede mit ~101 Toten bei dem Bahnunfall nicht ? Da Ariane 5 ein anderes Flugprofil besaß als Ariane 4, musste dieses Vorgehen scheitern. # Da fragt sich nur wer dafür die Birne hinhalten mußte, # diese MammaNager sicherlich nicht... # Also iss wohl nix mit 1:1 Wiederverwendung, # egal welche Sprache man nimmt! } Außerdem meckern die im nächten Link ebenfalls diese dauernde Duplizierung von Code bei C++ an, obwohl es bessere ansätze gibt! http://de.wikipedia.org/wiki/Generische_Programmierung Zum Vergleich: http://de.wikipedia.org/wiki/Generische_Programmierung_in_Java_5.0 Last but not least, finde ich diese aufgewühlte Diskussion was auch beabsichtigt war recht nett, obgleich einige Leute ihre in Richtung Diskreditierung sprich Beleidigung grenzenden Kommentare nicht für sich behalten konnten. Aber offensichtlich gilt das, was in anderen Bereichen auch so ist, wo sich die "Wissenschaft" über Konzepte und Theorien streitet. Na ja, möge am ende die Vernunft siegen..... Es gibt zu dieser Diskussion schöne Analogien z.B. aus der Medizin mit sogar großem historischen Hintergrund hier z.B. http://www.melhorn.de/Herzinfarkt/index.htm Theo
> Außerdem meckern die im nächten Link ebenfalls diese > dauernde Duplizierung von Code bei C++ an, obwohl es bessere > ansätze gibt! Der Java-Ansatz ist nicht "besser" als der von C++, es ist eine grundlegend andere Herangehensweise. Die Funktionalitäten von C++-Templates lassen sich nicht im geringsten mit denen der Java-Generics vergleichen. Der gravierendste Unterschied ist, dass C++-Templates turing-komplett und nicht auf nicht-eingebaute Typen beschränkt sind. AFAIK bieten Java-Generics auch keine teilweise Spezialisierung, d.h. man kann nicht für bestimmte Typparameter gezielt ohne if-Abfrage anderes Verhalten festlegen. C++-Templates und Java-Generics sind einfach zwei unterschiedliche Konzepte, auch wenn sie auf den ersten Blick ähnlich aussehen und ähnlich heißen. Dass beide Konzepte beim ersten Ansehen ähnlich erscheinen, ist IMHO nicht dem Zufall zuzuschreiben.
Hi C++ ist mit Sicherheit nicht der Weisheit letzter Schluß aber eigentliche die einzige objektorientierte Programmiersprache die es auf beinahe jedem System gibt. C# (bzw. die .NET Laufzeitumgebung) gibt es eben nur auf x86. Mono läuft zwar auch auf mehr Architekturen aber der JIT ist außerhalb von x86 wohl alles andere als toll. Ähnliches gilt für Java. Scriptsprachen (perl, phython, shell usw.) sind zwar auch beinahe überall verfügbar (der Interpreter ist ja meist in C/C++ geschrieben) aber die Auslieferung des Quelltexts einer Anwendung ist nicht das Ziel jedes Anwendungsentwicklers. Ein Großteil der heutzutage erstellten Software läuft auf völlig anderen Architekturen als x86. Und da die erste verfügbare Hochsprache für eine Architektur fast immer C ist folgt darauf dann alsbald ein C++ Compiler da sich das Backend (also die eigentliche Generierung von Code aus dem Syntaxbaum) nicht so sehr von dem des C Compiler unterscheidet. Das Frontend eines C++ Compilers ist natürlich weit komplexer läßt sich aber für alle Architekturen verwenden. Niemand hindert einen aber in C++ darin böse Dinge zu tun: char a[10]; a[-2] = a[14]; ist auch in C++ gültiger Code. Zum Thema Templates: Eigentlich eine schöne "Erfindung" und enorm mächtig. Templates gehen weit über std::vector<foo> hinaus. Wer mal den richtigen Einsatz von C++ Templates sehen will sollte sich mal http://www.antigrain.com/ anschauen :-) Matthias
Sagt mal Leute, kennt einer diesen C++? So sauer wie der Thread-opener auf den ist hat er ihm wohl die Freundin ausgespannt.
>Sagt mal Leute, >kennt einer diesen C++? So sauer wie der Thread-opener auf den ist >hat er ihm wohl die Freundin ausgespannt. Also die scheinbare Geschichte wie bei alfred Nobel ist es keinesfalls, denn a.Noble solte angeblichein Mathematiker die tusse ausgespannt haben (gilt aber als umstritten) weshalb er angeblich für Mathematik keinen Nobelpreis ausgesetzt hat. was mich bei dieser Sprache so ankotzt ist das sie so irrsinnig kryptisch ist und extrem speicher verbraucht. Wollte mir letztens VisualC++ von MikroMurks runterladen aber als ich las Minimum 192 MB um es überhaupt starten kann hab ichs gleich wieder gelassen...... Was mich wundert ist das es so lange gedauert hat, fast 20 Jahre bis endlich c++ in der EmbeddetElektronik gelandet ist. 20 Jahre war C gut genug für die "Waschmaschinen"........:-) eben klein schlank schnell. wobei ich allerdings letztens bemerkte das bei ADA auch Qperatoren-Überladung möglich ist. Das heist dann so ähnlich wie: function +( links :Integer ; rechts Integer ) :Integer Und es gibt wohl dabei weit mehr Compilerware als zu erst angenommen. Theo
> ... Nobel ...
Was dich jetzt auf eine Stufe mit ihm stellt?
Geh weg, bitte!
> was mich bei dieser Sprache so ankotzt ist das sie so > irrsinnig kryptisch ist und extrem speicher verbraucht. Ersetze "kryptisch" durch "komplex" und ich stimme dir im ersten Punkt zu. Der zweite ist an den Haaren herbeigezogen; du setzt den Downloadumfang einer sehr umfangreichen IDE mit dem Speicherverbrauch der Sprache gleich. Selbst wenn du diesen Vergleich nicht so meinen solltest: C++ verbraucht nicht mehr Speicher als C, wenn es um äquivalente Funktionalitäten geht. Wo soll der zusätzliche Speicherverbrauch auch herkommen?
Vergiss es, da ist Hopfen und Malz verloren. Da kannst du dir den Mund fusselig reden oder die Finger krumm schreiben, du änderst nichts. Im Endeffekt darf der OP sich ja auch von C++ angekotzt fühlen, aber deswegen muss er doch nicht uns allen auf'n Sack gehen. Vielleicht mal weniger Silber nehmen, evtl. hilft es ja.
"Im Endeffekt darf der OP sich ja auch von C++ angekotzt fühlen, aber deswegen muss er doch nicht uns allen auf'n Sack gehen." -> super Lebenseinstellung! Das ist ungefähr so: "Ich programmiere in xy, weil da jeder mit programmiert. Womit die Mehrheit programmiert ist natürlich automatisch besser als der Rest, das war und ist immer so. Diesen dummen Kritikern alles erklären zu müssen geht mir auf die Nerven; ich weiß sowieso, daß das, was ich verwende besser ist und die Mehrheit weiß das auch, das muß Dir als dummer Kritiker schon als Begründung reichen - geh mir deshalb nicht auf den Sack" Tja, ich kenne solche Leute ... Spezielle Frage an Christoph (Chris), der ja sachlich Unterschiede zwischen c und c++ aufgezeit hat. Welchen c++ Compiler würdest Du denn verwenden bzw. empfehlen unten dem Aspekten Downloadumfang, Funktionalität und eventuell Kompatibilität zu c (falls das überhaupt Sinn macht), sowie kommerzielle Anwendung, falls ich mich doch noch mit c++ auseinandersetze? Reicht ein Gnu c++ Compiler aus oder am Ende doch Visual C++, weil das jeder hat und in Bezug auf berufliche Aspekte das beste ist.
Das mit dem falsch verwerteten Code bei Ariane 5 kenne ich irgendwoher: Für ne Motorsteuerung hammse bei Bosch auch schon mehrfach alte Software ausgeliefert, wenn die neue nicht fertig geworden ist. Geht der Motor halt nicht so optimal. Da arbeiten auch viele noch mit C, waehrend moderne Abteilungen dieselbe Hardware schon in C++ programmieren.
Hi auch wenn ich nicht Christoph heiße: Grundsätzlich ist es IMHO keine schlechte Idee wenn man mit der GCC und den zugehörigen Tools (make, cvs, ...) umgehen kann oder sie mal bediehnt hat. Die Chance das man außerhalb der Windowswelt auf diese Tools trifft ist nicht gerade klein. Der Visual-C++ Compiler ist in Versionen > 6 eigentlich garnicht so schlecht. Eher sogar sehr gut im Vergleich zu <= 6 der dann doch so seine Probleme hatte. Und mit der M$-IDE umgehen zu können ist auch kein Fehler. Was die reine Umsetzung der Sprache C++ angeht schenken sich VC++ und ein aktueller GCC nicht viel und es ist von diesem Standpunkt aus betrachtet egal welchen man zum Erlernen von C++ verwendet. Was Performance angeht ist aber wohl der Intel-Compiler (auf x86!) allen anderen überlegen. Matthias
habe jetzt nur einen Teil gelesen. Programmiere selber seit 11 Jahren in C/C++, und habe mich ehrlich gesagt nie mit beiderlei Sprachen anfreunden können. Bevor ich C programmiere, benutze ich lieber Assembler, und bevor ich was mit C++ anfange aufzubauen nehme ich lieber Java oder C# her. Die Sprachen C und C++ taugen meiner Meinung nach beide nichts.
@Smörre: Ich kann Matthias nur zustimmen. Es schadet nicht den g++ zu kennen. Visual-C++ bringt eine IDE mit, die den Einstieg vereinfacht. g++ hat eine offenere Lizenz, aber beide Compiler sind inzwischen kostenlos erhältlich (VC++ in der "Express Version") [1]. In der Umsetzung des C++-Standards sind mittlerweile beide Compiler ziemlich ausgereift. Wenn du denen eine Datei mit Endung .c gibst oder das manuell einstellst, können beide Compiler problemlos C-Code kompilieren. Der g++ kann soweit ich weiß den neuesten C-Standard, der Visual C++ hängt da noch ein wenig hinterher. Solange du keine hersteller-spezifischen Bibliotheken wie MFC (für VC++) verwendest, sollte sich ein Programm auch mit geringem Portier-Aufwand auf beiden Compilern kompilieren lassen. Allzu entscheidend ist die Wahl zwischen g++ und VC++ also nicht. Ich würde für den Einstieg aufgrund der gut zu bedienenden IDE eher zu Visual C++ raten, muss aber dazu sagen, dass ich die Express Version nie selbst eingesetzt habe. Außerdem gibt es inzwischen mit Code::Blocks[2] auch für Windows eine ziemlich gute g++-IDE. Was man auf keinen Fall machen sollte, was Matthias aber auch schon erwähnt hat, ist Visual C++ 6 einzusetzen. Die IDE ist zwar nicht schlecht, aber der Compiler ist aus heutiger Sicht eine mittlere Katastrophe. Immer mehr moderne C++-Bibliotheken stellen deswegen übrigens nach und nach die Unterstützung von VC6 ein. Leider war dieser Compiler früher sehr verbreitet und auf vielen Heft-CDs zu finden. [1] http://msdn.microsoft.com/vstudio/express/support/install/ [2] http://www.codeblocks.org/
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.