Von Christian Meyer am So, 2. Februar 2003 um 00:25 #
Das C++ speziell, und Objektorientierung im allgemeinen, höhere Erfolgschances bietet als Iterative Prozedursprachen, haben die Programmierer dieser Welt (naja, nicht alle...) schon früh erkannt. Selbstverstaendlich kann jedes Konstrukt in C++ in C, oder Assembler, oder Basic emuliert werden. Das ist auch keine Neuigkeit.
Korrekt, aber es ging darum, ob es ueberhaupt moeglich ist, gewissen Sache in C zu machen, die in C++ moeglich sind; und mit gtk+ ist es das.
Der Punkt ist aber: nach all den Jahren ist beim Entwickeln von Software nach wie vor ein Mensch mit von der Partie, und der ist der unsichere Faktor, nicht der Computer. Deswegen muessen Semantiken entwickelt werden, die es einfacher machen, Anweisungen präzise auszudrücken. Warum gibt es bei Projekten der Größenordnung von KDE Wohl dedizierte Refaktorisierungs-Zyklen, bei denen nichts anderes gemacht wird als Quellcode in minimalen Schritten umzuformulieren (selbstverständlich bei gleichem Effekt)? Sicher nicht weil der Compiler sich drum schert, dem ist es doch egal ob er C++ oder C oder Assember vor sich hat.
Auch hier stimme ich dir zu. Mit der Einfuehrung von JAVA hat auch jeder gemeint, dass C++ ueberfluessig wird, bzw. alles ab sofort in JAVA programmiert wird. Aber wie gesagt, darum geht es nicht.
....
Deswegen ist C++ angebrachter für Projekte einer kritischen Größenordnung, die KDE definitiv weit überschritten hat.
Es ist definitiv leichter ein grosses Projekt in C++ zu schreiben als in C, nur wenn der Programmierer sein Programm lieber in C schreibt, und, sagen wir mal, besseren Code damit erstellt als ein anderer mit C++, dann helfen die Vorteile von C++ auch nicht. Es gibt Leute die: * guten C-Code * guten C++-Code * schlechten C-Code * schlechten C++-Code schreiben bzw. suboptimalen Code.
...können sinnvoll entwickelte Semantiken die Fehleranfälligkeit signifikant reduzieren.
Richtig, weil sie helfen dem Programmierer dabei. Wenn man allerdings fit in einer Sprache ist, und weiss was man tut, dann ist die Fehlerhaeufigkeit dennoch geringer als bei unerfahrenen C/C++-Programmieren.
Ich würde nicht so weit gehen und C++ eine sinnvolle Semantik bescheinigen, aber Gegenwärtig repräsentiert C++ eine Kombination aus Verbreitungsgrad, Skalierbarkeit und Compilersupport, die von keiner anderen Sprache erreicht wurde.
Dem kann ich nur bedingt zustimmen. Beispiel JAVA: * Verbreitungsgrad enorm hoch, manche sagen hoeher als C++ * Skalierbarkeit mag noch nicht das Optimum sein, aber wird stetig besser * Compilersupport: Firmen wie IBM bieten exzellente JAVA-Compiler an (jikes), auch gcj, den ich getestet habe, ist schon recht gut zu gebrauchen und erstellt desweiteren nativen Code. Die Plattformunabhaengigkeit mag zwar verlorengehen, jedoch erkauft man sich dadurch auch einen hoehere Performanz.
Nein... mit C können nur OO-Konstrukte emuliert werden, aber echtes OO ist damit nicht möglich. Echtes OO bedeutet immer Unterstützung des Übersetzers/Präprozessors damit letztlich die Interna des Denkmodells dem Entwickler verborgen bleiben. Bei C bin ich ständig damit beschäftigt Strukturen zu verlängern oder durch Casting auf Speicherbereiche des Struktur-Abbildes eine andere Sichtweise auf das Objekt zu bekommen. Das ganze ist äusserst Fehleranfällig und beschäftig den Codierer mehr mit dem Überbau als mit der eigentlichen Logik seine Programmes.
Von Christian Meyer am So, 2. Februar 2003 um 11:11 #
Klar, muss der Programmierer bei C sein Gehirn etwas mehr einschalten, als bei C++. ABER: Es ging darum, ob OO Programmierung in C moeglich ist oder nicht. Ich kann auch in funktionalen Programmiersprachen OO programmieren. Es geht nicht um die Frage ob es elegant ist.
Bei C bin ich ständig damit beschäftigt Strukturen zu verlängern...
verlaengern?
Das man in C viel casten muss, weiss jeder. Das ist auch ohne den OO Ansatz der Fall. Eerfahrene C-Programmierer kennen jedoch die Probleme und koennen trozt der Komplexitaet guten Code erstellen.
Korrekt, aber es ging darum, ob es ueberhaupt moeglich ist, gewissen Sache in C zu machen, die in C++ moeglich sind; und mit gtk+ ist es das.
Der Punkt ist aber: nach all den Jahren ist beim Entwickeln von Software nach wie vor ein Mensch mit von der Partie, und der ist der unsichere Faktor, nicht der Computer. Deswegen muessen Semantiken entwickelt werden, die es einfacher machen, Anweisungen präzise auszudrücken.
Warum gibt es bei Projekten der Größenordnung von KDE Wohl dedizierte Refaktorisierungs-Zyklen, bei denen nichts anderes gemacht wird als Quellcode in minimalen Schritten umzuformulieren (selbstverständlich bei gleichem Effekt)? Sicher nicht weil der Compiler sich drum schert, dem ist es doch egal ob er C++ oder C oder Assember vor sich hat.
Auch hier stimme ich dir zu. Mit der Einfuehrung von JAVA hat auch jeder gemeint, dass C++ ueberfluessig wird, bzw. alles ab sofort in JAVA programmiert wird.
Aber wie gesagt, darum geht es nicht.
....
Deswegen ist C++ angebrachter für Projekte einer kritischen Größenordnung, die KDE definitiv weit überschritten hat.
Es ist definitiv leichter ein grosses Projekt in C++ zu schreiben als in C, nur wenn der Programmierer sein Programm lieber in C schreibt, und, sagen wir mal, besseren Code damit erstellt als ein anderer mit C++, dann helfen die Vorteile von C++ auch nicht.
Es gibt Leute die:
* guten C-Code
* guten C++-Code
* schlechten C-Code
* schlechten C++-Code schreiben
bzw. suboptimalen Code.
...können sinnvoll entwickelte Semantiken die Fehleranfälligkeit signifikant reduzieren.
Richtig, weil sie helfen dem Programmierer dabei. Wenn man allerdings fit in einer Sprache ist, und weiss was man tut, dann ist die Fehlerhaeufigkeit dennoch geringer als bei unerfahrenen C/C++-Programmieren.
Ich würde nicht so weit gehen und C++ eine sinnvolle Semantik bescheinigen, aber Gegenwärtig repräsentiert C++ eine Kombination aus Verbreitungsgrad, Skalierbarkeit und Compilersupport, die von keiner anderen Sprache erreicht wurde.
Dem kann ich nur bedingt zustimmen.
Beispiel JAVA:
* Verbreitungsgrad enorm hoch, manche sagen hoeher als C++
* Skalierbarkeit mag noch nicht das Optimum sein, aber wird stetig besser
* Compilersupport: Firmen wie IBM bieten exzellente JAVA-Compiler an (jikes), auch gcj, den ich getestet habe, ist schon recht gut zu gebrauchen und erstellt desweiteren nativen Code. Die Plattformunabhaengigkeit mag zwar verlorengehen, jedoch erkauft man sich dadurch auch einen hoehere Performanz.
gruesse,
Christian
Bei C bin ich ständig damit beschäftigt Strukturen zu verlängern oder durch Casting auf Speicherbereiche des Struktur-Abbildes eine andere Sichtweise auf das Objekt zu bekommen. Das ganze ist äusserst Fehleranfällig und beschäftig den Codierer mehr mit dem Überbau als mit der eigentlichen Logik seine Programmes.
Ich kann auch in funktionalen Programmiersprachen OO programmieren. Es geht nicht um die Frage ob es elegant ist.
Bei C bin ich ständig damit beschäftigt Strukturen zu verlängern...
verlaengern?
Das man in C viel casten muss, weiss jeder. Das ist auch ohne den OO Ansatz der Fall.
Eerfahrene C-Programmierer kennen jedoch die Probleme und koennen trozt der Komplexitaet guten Code erstellen.