Unterschied c c++ c#

[TrollEyes]

Sebastian Pizer schrieb:

Ich verweise jetzt einfach mal auf zwei Texte.
- Eine Antwort dazu von Stephen Dewhurst

The argument that abstraction and efficiency are mutually-exclusive or that they're mutually exclusive in the context of C++ is demonstrably false. Lately, much of my work involves writing embedded code in C++ with heavy use of inheritance and templates, and the results have been more than promising. The resultant code is typically smaller and faster than the equivalent (well-written) C code provided by the board's manufacturer

Hier steht eine verwaschene Aussage gegen die andere. Man sollte wirklich mal nachforschen, wer von beiden recht hat. Warum benutzt beispielsweise Apple ObjectiveC anstatt C++? Hatte Linus' Meinung darauf Einfluss?

[Marc++us]

TrollEyes schrieb:

Hier steht eine verwaschene Aussage gegen die andere. Man sollte wirklich mal nachforschen, wer von beiden recht hat.

Wahrscheinlich keiner und beide.

Es macht kaum Sinn, letztlich kann man in jeder der hier genannten Sprachen Programme schreiben, die nicht funktionieren und den Anwender nerven. Und das ist ja in der Masse der Fälle das, was die Entwickler tun.

[Sebastian Pizer]

TrollEyes schrieb:

Sebastian Pizer schrieb:

Ich verweise jetzt einfach mal auf zwei Texte.
- Eine Antwort dazu von Stephen Dewhurst

The argument that abstraction and efficiency are mutually-exclusive or that they're mutually exclusive in the context of C++ is demonstrably false. Lately, much of my work involves writing embedded code in C++ with heavy use of inheritance and templates, and the results have been more than promising. The resultant code is typically smaller and faster than the equivalent (well-written) C code provided by the board's manufacturer

Hier steht eine verwaschene Aussage gegen die andere. Man sollte wirklich mal nachforschen, wer von beiden recht hat.

Das Problem ist -- wie so oft -- dass viele Leute, die sich an solchen Diskussionen beteiligen nur einen kleinen Teil des Ganzen sehen. Ich will mich da auch gar nicht komplett ausschließen. Wenn man nicht offen für Argumente ist, ist das hier doch sowieso Zeitverschwendung.

Wenn Dir das also eher wie eine verwaschene Aussage vorkommt, dann liegt das vielleicht daran, dass Du den Teil des Ganzen nicht kennst, welcher für Steven selbstverständlich ist und als Grundlage für diese Aussage verwendet wird. Um's dann überzeugender zu machen, müsste er alles detaillierter beschreiben und mehr Beispiele bringen, damit auch Leute, die nicht wissen, wovon er redet, nicht im Regen stehen gelassen werden.

Ich denke, dass ein erfahrener C++ Programmierer einen etwas besseren Überblick über die Sprachen hat, als einer, der in C++ kaum Erfahrungen hat -- allein deswegen, weil C++ den Programmierstil von C erlaubt, aber nicht umgekehrt. Daher traue ich einem erfahrenen C++ Programmierer einen fairen Vergleich zu. Anderen nicht. Ich halte es für plausibel, dass "andere" eher durch Vorurteile beeinflusst werden.

Ich war aber trotzdem wieder überrascht, als ich die Texte von anderen Autoren aus der git Mailingliste erneut gelesen habe. Vorurteile, Doppelmoral, Verallgemeinerungen, etc etc etc. Die Stimmung, die da rüber kommt, ist auch keine gute Diskussionsgrundlage.

TrollEyes schrieb:

Warum benutzt beispielsweise Apple ObjectiveC anstatt C++? Hatte Linus' Meinung darauf Einfluss?

Die Entwicklung von ObjC und C++ verlief, wie es aussieht, einigermaßen parallel in den 80ger Jahren. Das NeXTStep Betriebssystem hatte 1989 schon eine ObjC-basierte Benutzeroberfläche, welches auch Grundlage für Apple's Cocoa ist. Linus Torvalds wurde erst später bekannt. Der Mann hat die Weisheit auch nicht mit Löffeln gefressen. Er unterliegt selbstverständlich auch der Problematik, nicht den kompletten Überblick zu haben. (Wer hat den schon?) Und über Geschmäcker muss man auch nicht streiten.

Gruß,
SP

[erik.vikinger]

Hallo,

TrollEyes schrieb:

Hier steht eine verwaschene Aussage gegen die andere. Man sollte wirklich mal nachforschen, wer von beiden recht hat.

Solange alle Programme auf der exakt selben Hardware laufen sollte man theoretisch mit C und C++ gleich schnelle Programme hin bekommen. In C++ kann man sich auf C beschränken und in C kann man C++ händisch nachbauen. Beide Compiler erzeugen Maschinen-Code und wenn einer von beiden besseren Maschinen-Code erzeugt dann weil der entsprechende Programmierer die Problemlösung besser formuliert hat. Theoretisch, entsprechend Know-How und Masochismus vorausgesetzt, kann man C++ auch in Assembler nachbauen und damit funktionsgleichen Maschinen-Code erzeugen. Wenn man in C++ sehr viel mit Vererbung und virtuellen Methoden (was zusätzlichen Code erzeugt) macht kann ein geübter C Programmierer sicherlich effizienteren Code erstellen, dafür ist das C++ Gegenstück eventuell besser wartbar oder leichter wiederverwendbar. Wenn man die Features von C++ nur so viel wie wirklich nötig einsetzt kann man IMHO effizienten und wartbaren Code schreiben, aber dafür braucht man einiges an Erfahrung in C++ und C.

Nur allein mit dem Kriterium Effizienz kann man C und C++ IMHO nicht unterscheiden da beide auf die selbe Basis aufsetzen.

C# und Java dagegen erlauben es nicht in dem Umfang an der Effizienz zu drehen weil dort einige Dinge (z.B. Pointer) vor dem Programmierer versteckt bzw. in Sicherheit gebracht wurden. Für normale Anwendungsprogramme ist das eher von Vorteil und der minimale Effizienz-Rückgang fällt auf heutigen PCs kaum auf. Wenn man aber sehr kritischen oder hardware-nahen Code schreibt kann es schon zum Problem werden wenn man nicht die totale Kontrolle hat.

C und C++ erlauben dem Programmierer mehr aber erwarten auch mehr vom Programmierer.

Grüße
Erik

[Shade Of Mine]

erik.vikinger schrieb:

Solange alle Programme auf der exakt selben Hardware laufen sollte man theoretisch mit C und C++ gleich schnelle Programme hin bekommen.

Durch unterschiedliche Abstraktionsebenen hat der Compiler unterschiedliche Ansätze zur Optimierung.

[rüdiger]

@erik.vikinger
Ich würde soger eher sagen, dass man mit C++ durch Templates einen Performancevorteil rausholen kann. Einfaches Beispiel ist ja std::sort vs qsort .

[Trollinger]

rüdiger schrieb:

@erik.vikinger
Ich würde soger eher sagen, dass man mit C++ durch Templates einen Performancevorteil rausholen kann. Einfaches Beispiel ist ja std::sort vs qsort .

Aber nur mit Integers, nicht mit beliebigen Objekten.
Dafür kann C# sogar zu Laufzeit Optimierungen vornehmen :p

[Shade Of Mine]

Trollinger schrieb:

Aber nur mit Integers, nicht mit beliebigen Objekten.

Warum nicht mit beliebigen Objekten?

Der Performance Vorteil von std::sort gegenüber qsort liegt ja darin begraben, dass der Compiler bei std::sort die compare Funktion inlinen kann, bei qsort aber nicht.

[loks]

Sebastian Pizer schrieb:

Ich denke, dass ein erfahrener C++ Programmierer einen etwas besseren Überblick über die Sprachen hat, als einer, der in C++ kaum Erfahrungen hat -- allein deswegen, weil C++ den Programmierstil von C erlaubt, aber nicht umgekehrt. Daher traue ich einem erfahrenen C++ Programmierer einen fairen Vergleich zu. Anderen nicht. Ich halte es für plausibel, dass "andere" eher durch Vorurteile beeinflusst werden.

Die Logik hinter der Aussage ist zwar korrekt, jedoch geht es in der Realität leider nicht logisch zu. Trotzdem ein erfahrener C++ Programmierer theoretisch tatsächlich genug Überblick haben sollte sehen die meisten C++ Programmierer "ihre" Sprache durch die Rosarote Brille und haben besonders wenn es im die Schwächen dieser Sprache geht diverse "Blind Spots" in Ihrer Wahrnehmung.

Ich hab selbst über 15 Jahre das gleiche Problem gehabt... Erst durch intensiven Kontakt zu Sprachen wie C# und, nennen wir es eine gewisse C++-Abstinez von ein paar Jahren fing ich an die Sprache auch mal kritisch zu betrachten. Nicht falsch verstehen, ich sehe in C++ nach wie vor eine mächte Sprache in der ich gerne arbeite, aber heute sehe ich auch ihre Schwächen.

[erik.vikinger]

Hallo,

rüdiger schrieb:

Ich würde soger eher sagen, dass man mit C++ durch Templates einen Performancevorteil rausholen kann. Einfaches Beispiel ist ja std::sort vs qsort .

Der C Programmierer kann aber für jeden benutzten Datentyp eine eigene qsort -Variante bauen. Mit einer guten Vorlage und sed geht das sogar recht einfach, im Prinzip eine compiler-unabhängige Template-Sache, läuft aber auf das selbe Ergebnis hinaus. So ein Trick mit sed hab ich mal gemacht wo ich zwei nahezu, aber nicht ganz, identische Code-Stücke gebraucht hatte, war aber für Assembler-Code.

Eben weil man in C alles machen kann kann man damit auch C++ nachbauen und die selben Abstraktionsmöglichkeiten ausschöpfen (das selbe gilt auch für Assembler), das der Code dann wahrlich scheußlich aussieht ist ein anderes Thema. C++ unterstützt den Programmierer vor allem deutlich besser dabei effizienten und wartbaren/abstrakten Code zu schreiben als C. Deshalb verwende ich per Default immer C++ und beschränke mich notfalls auf die Teilmenge welche keinen Overhead erzeugt. Wenn man Exceptions, RTTI und virtuelle Klassen-Member/Methoden weg lässt hat man im Prinzip auch nur C aber mit schönerer Syntax (z.B. Operatorüberladung) und mehr Compilerunterstützung (z.B. Templates). Wenn ich die genannten Features trotzdem benutzen möchte muss ich eben einen Kompromiss aus Effizienz und Design eingehen, wobei es oft so ist das sich durch das bessere Design wieder zusätzliche Effizienz einstellt also der Kompromiss meistens nicht so übel ist.

Grüße
Erik

[Sebastian Pizer]

loks schrieb:

[...] Trotzdem ein erfahrener C++ Programmierer theoretisch tatsächlich genug Überblick haben sollte sehen die meisten C++ Programmierer "ihre" Sprache durch die Rosarote Brille und haben besonders wenn es im die Schwächen dieser Sprache geht diverse "Blind Spots" in Ihrer Wahrnehmung.

Und das trifft auf C-Programmierer und "deren" Sprache nicht zu?

[Dravere]

Sebastian Pizer schrieb:

loks schrieb:

[...] Trotzdem ein erfahrener C++ Programmierer theoretisch tatsächlich genug Überblick haben sollte sehen die meisten C++ Programmierer "ihre" Sprache durch die Rosarote Brille und haben besonders wenn es im die Schwächen dieser Sprache geht diverse "Blind Spots" in Ihrer Wahrnehmung.

Und das trifft auf C-Programmierer und "ihrer" Sprache nicht zu?

Und auf Ada-Programmierer? Auf C#-Programmierer? Auf Java-Programmierer? Auf PHP-Programmierer? Auf Python-Programmierer? Auf X-Programmierer?

Es trifft auf alle zu. Ich denke aber trotzdem, dass in der Aussage von loks etwas wichtiges drin war:
Es ist wichtig, dass man auch mal andere Programmiersprachen kennen gelernt hat. Und zwar nicht nur mal gelernt, sondern wirklich damit beschäftigt und gearbeitet. Wie hat man Probleme in anderen Sprachen gelöst? Wie geht man es in anderen Sprachen an? Und an diese Fragen sollte man probieren ein wenig neutral heranzugehen und nicht einfach mit "Scheisse" abtun, sondern es halt wirklich anwenden und verwenden.

Ich möchte ja mal Linus Tovalds fragen, wieviele C++ Programme er schon geschrieben hat und was das für Programme waren

Keine Sprache ist ideal, jede hat ihren Verwendungszweck. Die richtige Programmiersprache für das richtige Programm und dann in Verbindung gesetzt, ergibt das beste Projekt. Naja, braucht dann natürlich noch ein wenig mehr

Grüssli

[Sebastian Pizer]

Dravere schrieb:

Ich denke aber trotzdem, dass in der Aussage von loks etwas wichtiges drin war:
Es ist wichtig, dass man auch mal andere Programmiersprachen kennen gelernt hat. Und zwar nicht nur mal gelernt, sondern wirklich damit beschäftigt und gearbeitet. Wie hat man Probleme in anderen Sprachen gelöst? Wie geht man es in anderen Sprachen an? Und an diese Fragen sollte man probieren ein wenig neutral heranzugehen und nicht einfach mit "Scheisse" abtun, sondern es halt wirklich anwenden und verwenden.

Das sehe ich ganz genauso und es ist auch Teil von dem, was ich mit "nur einen kleinen Teil des Ganzen sehen" (12:02:45 16.02.2010) meinte.

Dravere schrieb:

Ich möchte ja mal Linus Tovalds fragen, wieviele C++ Programme er schon geschrieben hat und was das für Programme waren

Das frage ich mich auch.

Gruß,
SP

[supertux]

loks schrieb:

Die Logik hinter der Aussage ist zwar korrekt, jedoch geht es in der Realität leider nicht logisch zu. Trotzdem ein erfahrener C++ Programmierer theoretisch tatsächlich genug Überblick haben sollte sehen die meisten C++ Programmierer "ihre" Sprache durch die Rosarote Brille und haben besonders wenn es im die Schwächen dieser Sprache geht diverse "Blind Spots" in Ihrer Wahrnehmung.

Rosarote Brille, hehe das erinnerte mich an:

<a href= schrieb:

If programming languages were religions...">
C++ would be Islam - It takes C and not only keeps all its laws, but adds a very complex new set of laws on top of it. It's so versatile that it can be used to be the foundation of anything, from great atrocities to beautiful works of art. *Its followers are convinced that it is the ultimate universal language, and may be angered by those who disagree. Also, if you insult it or its founder, you'll probably be threatened with death by more radical followers.
*

Dravere schrieb:

Ich möchte ja mal Linus Tovalds fragen, wieviele C++ Programme er schon geschrieben hat und was das für Programme waren

wem interessiert es? Hauptsache er schreibt guten C Code für linux.

[Bashar]

supertux schrieb:

wem interessiert es? Hauptsache er schreibt guten C Code für linux.

Das ist ja nicht alles, was er tut. Er äußert auch sehr gerne kontroverse Meinungen, und viele hören ihm dabei zu, also wäre es doch sehr interessant zu erfahren, wie gut diese Meinungen fundiert sind, meinst du nicht?

[TrollEyes]

Marc++us schrieb:

TrollEyes schrieb:

Hier steht eine verwaschene Aussage gegen die andere. Man sollte wirklich mal nachforschen, wer von beiden recht hat.

Wahrscheinlich keiner und beide.
Es macht kaum Sinn, letztlich kann man in jeder der hier genannten Sprachen Programme schreiben, die nicht funktionieren und den Anwender nerven. Und das ist ja in der Masse der Fälle das, was die Entwickler tun.

Wahrscheinlich. Und wahrscheinlich ist es in C++ um einiges leichter, Programme zuschreiben, die Anwender nerven, wo andere Entwickler nicht durchblicken und die der Programmierer selbst nach einiger Zeit nicht mehr versteht.

Sebastian Pizer schrieb:

TrollEyes schrieb:

Sebastian Pizer schrieb:

Ich verweise jetzt einfach mal auf zwei Texte.
- Eine Antwort dazu von Stephen Dewhurst

The argument that abstraction and efficiency are mutually-exclusive or that they're mutually exclusive in the context of C++ is demonstrably false. Lately, much of my work involves writing embedded code in C++ with heavy use of inheritance and templates, and the results have been more than promising. The resultant code is typically smaller and faster than the equivalent (well-written) C code provided by the board's manufacturer

Hier steht eine verwaschene Aussage gegen die andere. Man sollte wirklich mal nachforschen, wer von beiden recht hat.

Wenn Dir das also eher wie eine verwaschene Aussage vorkommt, dann liegt das vielleicht daran, dass Du den Teil des Ganzen nicht kennst, welcher für Steven selbstverständlich ist und als Grundlage für diese Aussage verwendet wird. Um's dann überzeugender zu machen, müsste er alles detaillierter beschreiben und mehr Beispiele bringen, damit auch Leute, die nicht wissen, wovon er redet, nicht im Regen stehen gelassen werden.

Das müsste er wohl tun, denn ich wäre sehr interessiert, wie man mit 'heavy use of inheritance and templates' Code hinbekommt, der 'typically smaller and faster' als ein äquivalenter C-Code ist. Zumindest Ersteres halte ich für eine schlichte Lüge.

Sebastian Pizer schrieb:

loks schrieb:

[...] Trotzdem ein erfahrener C++ Programmierer theoretisch tatsächlich genug Überblick haben sollte sehen die meisten C++ Programmierer "ihre" Sprache durch die Rosarote Brille und haben besonders wenn es im die Schwächen dieser Sprache geht diverse "Blind Spots" in Ihrer Wahrnehmung.

Und das trifft auf C-Programmierer und "deren" Sprache nicht zu?

Typischerweise haben C-Programmierer, die nichts von C++ wissen wollen, schon mal Bekanntschaft damit gemacht.

[loks]

TrollEyes schrieb:

Typischerweise haben C-Programmierer, die nichts von C++ wissen wollen, schon mal Bekanntschaft damit gemacht.

Ja, so einen kenne ich sogar beruflich. Jedoch fehlt da ein Teilsatz:

Typischerweise haben C-Programmierer, die nichts von C++ wissen wollen, schon mal Bekanntschaft damit gemacht weil sie OOP nicht verstehen.

[µngbd]

loks schrieb:

Typischerweise haben C-Programmierer, die nichts von C++ wissen wollen, schon mal Bekanntschaft damit gemacht weil sie OOP nicht verstehen.

Wie ist das? Die machen Bekanntschaft mit C++, weil sie OOP nicht verstehen? Das beleuchtet die Psyche der militanten C++'ler ein wenig.

Aber wahrscheinlich darf man nicht zu viel von einer Sprache erwarten, die nicht einmal die Gamma-Funktion über den reellen Zahlen kennt. (oder doch?)

[asc]

TrollEyes schrieb:

Wahrscheinlich. Und wahrscheinlich ist es in C++ um einiges leichter, Programme zuschreiben, die Anwender nerven, wo andere Entwickler nicht durchblicken und die der Programmierer selbst nach einiger Zeit nicht mehr versteht.

C++ Programme können ebenso verständlich sein wie Programme in anderen Sprachen, und genauso kryptisch, wie dies auch in jeder Sprache möglich ist (Es kommt auf den Programmierstil an).

TrollEyes schrieb:

...denn ich wäre sehr interessiert, wie man mit 'heavy use of inheritance and templates' Code hinbekommt, der 'typically smaller and faster' als ein äquivalenter C-Code ist. Zumindest Ersteres halte ich für eine schlichte Lüge.

Ob typischerweise weiß ich nicht, aber es ist definitiv möglich. Alleine schon dadurch das bei Templates nur der Code generiert wird der tatsächlich verwendet wird, Klassen ggf. weggestrichen werden (Die zur Steuerung bestimmter Sachverhalte dienen, die man zur Compilezeit auswerden kann) und der Tatsache das man auf Typen zugeschnittene Konstrukte leicht umsetzen kann, ohne das Konvertierungen nötig werden. Bei letzteren werden auch mal eben viele Sprünge und switches die unter C für die gleiche Arbeit nötig wären einfach mal gestrichen.

Und davon abgesehen gibt es auch zwei Formen der Vererbung unter C++: Über virtuell oder über Templatetechniken (statische Vererbung vs. dynamischer Vererbung). Und mit letzteren kann man häufig arbeiten, wenn die Unterscheidung nicht erst zur Laufzeit möglich ist (Sondern sich zur Compilezeit auswerten lässt).

Ich habe die Links damals nicht gesammelt, aber es gab ein paar sehr schöne Beispiele im Netz.

TrollEyes schrieb:

Sebastian Pizer schrieb:

Und das trifft auf C-Programmierer und "deren" Sprache nicht zu?

Typischerweise haben C-Programmierer, die nichts von C++ wissen wollen, schon mal Bekanntschaft damit gemacht.

Ich kenne kaum einen C-Programmierer der C++ wirklich mal verstanden hat (ebenso wenig wie was mit Templates überhaupt möglich ist, oder wie man OO wirklich anwendet). Auch ich tat mich damals mit C++ sehr schwer (wenn ich auch nicht von C sondern einigen anderen prozeduralen Sprachen kam), und hinter den wirklichen Sinn von OO und Templates kam erst nach vielen Jahren, und langen Lernen.

Ich kenne viele die C++ verteufeln, aber wenn du deren C++ Code siehst, verstehst du als C++ Programmierer auch warum. Wer C++ im wesentlichen wie C programmiert, hat C++ nicht verstanden, und hat häufig auch garnicht die Bereitschaft dazu.

[Sebastian Pizer]

asc schrieb:

TrollEyes schrieb:

Sebastian Pizer schrieb:

Und das trifft auf C-Programmierer und "deren" Sprache nicht zu?

Typischerweise haben C-Programmierer, die nichts von C++ wissen wollen, schon mal Bekanntschaft damit gemacht.

Ich kenne kaum einen C-Programmierer der C++ wirklich mal verstanden hat (ebenso wenig wie was mit Templates überhaupt möglich ist, oder wie man OO wirklich anwendet).

Ich kann mir auch nicht vorstellen, dass die meisten von den C Programmierern, die C++ ablehnen, überhaupt verstanden haben, was die Spracherweiterungen leisten und wie sie effizient kombiniert und benutzt werden können.

Als Gegenbeispiel zu Deinem zweiten Teil kann man sich mal den Quellcode des Linux Kernels runter ziehen. Ich würde nicht behaupten, dass OO dort nicht verstanden worden ist. Ich finde es aber schon sehr putzig, wie sie "C++ Features emulieren". Ich habe mir von dem Quellcode bisher nicht viel angesehen, nur mal ein bisschen in die Doku geschaut (zB kobject.txt und kref.txt) und da fällt mir folgendes auf:

• Emulation von Vererbung durch Einbetten eines "Basis-Structs" in einem "Derived-Struct" und ein relativ "hackiges" Zeiger-Konvertierungs-Makro, welches solche Dinge wie ((Derived*)0)->basis_subobjekt_member) enthält.
• kobjects haben einen Referenzzähler und einen Zeiger auf einen Typ-Descriptor, welcher sogar einen Zeiger auf eine "release"-Funktion enthält. --> shared_ptr, RTTI, virtual Destructor

mit dem Unterschied das es nicht Typ-sicher ist und leichter falsch benutzt werden kann:

• Man muss manuell Referenzzähler über Hilfsfunktionen verändern, was fehleranfällig ist.
• Beim Aufrufen der Makros muss der übergebene Typ stimmen oder sonst explodiert das ganze "GeCaste" zur Laufzeit.

Man findet oft Kommentare a la "Böse! Nicht das und das machen! Lieber so und so!" und einiges davon wäre in einem guten C++ Design durch die besseren Abstraktionsmittel überflüssig. Beispiel:

Der Referenzzähler soll erhöht werden BEVOR man den Zeiger an eine andere Funktion übergibt -- und ja nicht vergessen! -- ausser man interessiert sich danach nicht mehr für das objekt. Also, folgendes

kref_get(&obj->ref); // Erhöhen des Referenzzählers
  einer_funktion_uebergeben(obj);
  kref_put(&obj->ref); // ich interessiere mich jetzt nicht
                       // mehr dafür, obj darf ich jetzt
                       // nicht mehr benutzen.

darf als Optimierung durch

// Referenzzähler muss nicht angepasst werden
  einer_funktion_uebergeben(obj);
  // weil wir uns ein kref_put sparen.
  // *obj nicht mehr anfassen ab jetzt !!

ersetzt werden. Schön! Das gleiche bekomme ich mit

meine_cpp_funktion(mein_shared_zeiger);
   // kann den zeiger noch verwenden

oder:

   meine_cpp_funktion(move(mein_shared_zeiger));
   // explizites move() signalisiert: ich sollte
   // den zeiger jetzt nicht mehr lesend benutzen

auch hin -- sogar ohne, dass ich da viel falsch machen kann. Neee, sorry, also wenn das da in C nicht low-level Frickelei ist, ...

Ich muss mich echt zügeln, nicht über C Programmierer her zu ziehen, die das verzapft haben und dann auch noch C++ bashen ... mann mann mann ... nicht, dass der C Code mies wäre -- es geht ja leider nicht besser -- in C. :p

Deren verkette Liste habe ich mir auch angeguckt. Ist im Prinzip das gleiche wie boost::intrusive::list, nur ohne Typ-Sicherheit -- mal ganz davon abgesehen, dass structs in C kein member access control haben.

asc schrieb:

Auch ich tat mich damals mit C++ sehr schwer (wenn ich auch nicht von C sondern einigen anderen prozeduralen Sprachen kam), und hinter den wirklichen Sinn von OO und Templates kam erst nach vielen Jahren, und langen Lernen.

Ich kenne viele die C++ verteufeln, aber wenn du deren C++ Code siehst, verstehst du als C++ Programmierer auch warum. Wer C++ im wesentlichen wie C programmiert, hat C++ nicht verstanden, und hat häufig auch garnicht die Bereitschaft dazu.