c++.de :: In C89 zu programmieren...

Z Mitglied 09:56:02 13.04.2012 Titel:

SeppJ schrieb:

Och nö. Auf so eine Debatte habe ich um diese Zeit keine Lust. Du kannst also entweder
a) sowas einfach mal glauben, wenn dir jemand mit Erfahrung das sagt
b) dich selbstständig kundig machen über C++
c) dumm sterben

Insbesondere da deine Punkte tatsächlich sachlich falsch sind (ich bin besonders über den 2. und 3. entsetzt, dass du das nicht weißt) und keine bloßen Meinungsverschiedenheiten, sollte es ein leichtes für dich sein, sich darüber zu informieren.

Lies das: http://www.fefe.de/c++/c%2b%2b-talk.pdf

SeppJ Moderator 11:47:19 13.04.2012 Titel:

Ja, jemand auf der Welt hat keine Ahnung von C++. Das ist nichts neues. Ist das von dir?

Außerdem adressiert es gar nicht das worum es geht, ihm gefällt C++ eben nicht. Aber das was du behauptet hast ist schlichtweg falsch, so wie 1==2, nicht wie "ich mag kein Himbeereis".

cooky451 Mitglied 13:51:05 13.04.2012 Titel:

knivil schrieb:

Zitat:

jedes Sprachfeature von C++ ist total unabhängig von dynamischem Speicher

Move-Semantik nicht. Bzw. es sollte nicht der Stack verwendet werden.

Ja, und new/delete auch nicht. Hast du das quasi überlesen oder trollst du?

Unregistrierter

Sorry, aber diese Diskussion ist doch schon im Grundsatz falsch. Wenn es nur darum geht, ob man eine Sprache auf Grund schönerer Programmiermöglichkeiten/persönlicher Vorlieben/sonstiger akademischer Krümelkackereien verwendet oder nicht, ist die Fragestellung doch schon verkehrt.

In der Praxis beantwortet doch letztenendes der Einsatzzweck diese Frage. Und spätestens, wenn es um wirklich leistungsschwache Embedded Hardware mit wenig Speicher geht, kommt man an C nach wie vor nicht vorbei. Diese ganzen tollen (und zugegebenermaßen teilweise auch sehr bequemen) Abläufe und Konstrukte in C++ kosten nämlich dermaßen Zeit, dass man die bei wirklich rechenzeitkritischen Anwendungen nach wie vor nicht benutzen kann.

Wer es nicht glaubt: einfach mal im Debugger durch die Konstruktion und Dekonstruktion eines Objektes mit ein paar Parametern steppen (aber wirklich step-in, so dass auch das letzte Stückchen Code auftaucht, dass dabei intern aufgerufen wird). Diesen ganzen Wasserkopf kann bei knappen Ressourcen keiner gebrauchen - weswegen C auf diesen Systemen auch in 50 Jahren noch nicht ausgestorben sein wird.

SeppJ Moderator 14:27:37 13.04.2012 Titel:

Wupper schrieb:

Wer es nicht glaubt: einfach mal im Debugger durch die Konstruktion und Dekonstruktion eines Objektes mit ein paar Parametern steppen (aber wirklich step-in, so dass auch das letzte Stückchen Code auftaucht, dass dabei intern aufgerufen wird). Diesen ganzen Wasserkopf kann bei knappen Ressourcen keiner gebrauchen - weswegen C auf diesen Systemen auch in 50 Jahren noch nicht ausgestorben sein wird.

Ok, habe ich gemacht. Nichts ist passiert, denn es war gar kein Code da. Ich bin nicht überrascht. Du etwa?

Unregistrierter

SeppJ schrieb:

Ok, habe ich gemacht. Nichts ist passiert, denn es war gar kein Code da. Ich bin nicht überrascht. Du etwa?

LOL! Bist du hier der Forentroll? Oder hast du den Teil mit den Parametern nicht gelesen? Oder für die Objekterzeugung kein new/delete ausgeführt? Oder...oder du bist der Forentroll.

knivil Mitglied 14:39:55 13.04.2012 Titel:

Fuer Objekterzeugung braucht es nicht zwingend ein new. Man kann auch den Stack benutzten. Darueber hinaus programmiere ich gern in C++ auch fuer eingebettete Systeme. Nein, damit meine ich keinen 8-Bit Mikrocontroller, eher was im 32 Bit Bereich, beispielsweise Cortex-M4.

Unregistrierter

knivil schrieb:

Fuer Objekterzeugung braucht es nicht zwingend ein new. Man kann auch den Stack benutzten.

Richtig. Nur wird es dann halt schwierig, im Debugger nachzuvollziehen, was da alles passiert. @SeppJ: nur weil man etwas auf Grund äußerer Bedingungen nicht sieht, kann es trotzdem da sein!

Ansonsten ist der Begriff "Embedded" mittlerweile in der Tat sehr verwaschen. Genau genommen sind diese ganzen Android-Geräte auch irgend wie Embedded Systeme - und darauf läuft dann trotzdem Java :-)

knivil Mitglied 14:50:49 13.04.2012 Titel:

Zitat:

Nur wird es dann halt schwierig, im Debugger nachzuvollziehen, was da alles passiert.

1.) Ich programmiere nicht fuer den Debugger. 2.) Kann man sehr wohl mit dem Debugger das Geschehen verfolgen.

Zitat:

nur weil man etwas auf Grund äußerer Bedingungen nicht sieht, kann es trotzdem da sein

Jeder Compiler kann ASM-Code ausgeben. Wenn es dort nicht dabei ist, dann ist es auch nicht da.

cooky451 Mitglied 15:07:00 13.04.2012 Titel:

Wupper schrieb:

Diese ganzen tollen (und zugegebenermaßen teilweise auch sehr bequemen) Abläufe und Konstrukte in C++ kosten nämlich dermaßen Zeit, dass man die bei wirklich rechenzeitkritischen Anwendungen nach wie vor nicht benutzen kann.

Falsch. Falsch, falsch, falsch und noch mal falsch. Dann zeige doch mal ASM Code, der das unterstützt. Mit deiner Klasse, die Konstruktoren/Destruktoren hat. Release natürlich. Ich bin gespannt.
C++ ist an vielen Stellen sogar schneller als C. z.B. wenn man Lambdas statt Funktionszeigern verwenden kann. Oder expression Templates hat.

Und weil ich nichts zu tun habe: @Z
Seite 1: -
Seite 2: Ja, Template-Fehlermeldungen sind nicht schön.
Seite 3, 4, 5: Ja, immer noch nicht.
Seite 6: -
Seite 7: Oh nein, C++ hat sich seit 1997 (da gab es noch nicht mal nen C++ Standard) verändert.
Seite 8: Ja...
Seite 9: -
Seite 10: -
Seite 11: Ja, interessant. Aber ich kann auch ganz viele Klammern hintereinander setzen, das packt der Compiler auch nicht.
Seite 12: Ja.. das dauert bei ca. ~0.1 Sekunden.
Seite 13:
1. Tjoa, dann macht man halt die Klammern weg. Zugegeben, nicht besonders schön, aber auch nicht die Welt.
2. Ja, Operatorüberladungen vertrauen darauf, dass derjenige weiß was er tut. (Genau so wie Funktionen..)
3. Ja super, und das ist in C jetzt anders oder wie? Vor allem hat C++ eine neue Castsyntax, C nicht.
4. Ja, 2. gilt immer noch.
Seite 14: Ok, die implizite Konvertierung von bool nach int ist nicht so hübsch.
Seite 15:
1. Falsch. Natürlich kann man Exceptions aus Destruktoren werfen. (Auch wenn man das nicht sollte.)
Aber wichtiger: Man sollte aus Konstruktoren werfen!
2. Ja, wie schlimm.
3. auto_ptr ist vor allem deprecated.
4. Ehm.. doch.
5. Ja, das ist der Sinn von operator []. Aber: Das schöne ist ja, er darf machen was er will. Man hat also volle Kontrolle im Debug- und volle Geschwindigkeit im Releasemode.
6. Wozu auch? Macht nicht wirklich Sinn.
Seite 16:
1. Ja, das hatten wir schon mal mit den Exceptions im Destruktor.
2., 3., 4., Falsch: http://ideone.com/2wp02
Seite 17: Hatten wir doch schon. Etwas viel Redundanz für einen Programmierer.
Seite 18: Ja, immer noch deprecated.
Seite 19: Und was davon können Pointer jetzt? Abgesehen davon bringt das a.erase(b.begin()) zumindest beim MSVC und GCC ein assert() hervor. Nix silent.
Seite 20: Hatten wir doch auch schon.. so viele Sachen hat er dann wohl doch nicht gefunden, der gute Fefe.
Seite 21: Aber.. das hatten wir doch auch schon!

Seite 22: Ja, die Typen die man benutzt sollte man kennen.
Seite 23: -
Seite 24: -
Seite 25: Interessiert es wirklich ob bar ein Funktionszeiger oder eine Memberfunktion ist? Referenzen erkennt man nicht, das stimmt.
Seite 26: Ja, indem man überall using namespace xyz; einbaut kann man Code versauen. (Es sei denn man klickt auf "go to definition")
Seite 27: Jau, go to definition ist immer noch toll.
Seite 28: Ok, ist das noch ernst gemeint? Jetzt wettert er noch gegen Vererbung virtuelle Funktionen?
Seite 29: Ja, go to definition ist immer noch toll.
Seite 30: Nun ja, wenn die Typen bekannt sind, dauert das alles 2 Minuten.
Seite 31: Tja.

Seite 32: Na ja, kann ich nichts zu sagen.
Seite 33: Ein Blick auf die Funktionssignatur reicht trotzdem.
Seite 34: -
Seite 35: Ja..
Seite 36:
1. Und für const ist das richtige Verhalten definiert? Man greift einfach auf einen ungültigen Index zu.
2. Nicht schön. Aber kein Problem. Alternativvorschläge?
3. Nervig, aber in der Praxis nicht wirklich relevant.
4. Ja..
5. Nicht mehr.
Seite 37: -
Seite 38: -
Seite 39: Ja, hier kann man sehr schön schlechten C++ Code sehen.
Seite 40: Falsch, es ruft delete[] auf.
Seite 41: -
Seite 42: -
Seite 43: Ja, da hat er recht.
Seite 44: Da auch.
Seite 45: -
Seite 46: Hm.. ich meine da was gelesen zu haben. Moment.
Seite 47: Noch ein schönes Beispiel für schlechtes C++.
Seite 48: Ist Duke nicht draußen? Jetzt muss nur noch Hurd nachziehen.

Was bleibt also? auto_ptr ist lange ersetzt und Templatefehlermeldungen sind hässlich, aber so schlimm ist das auch nicht, es ist immer noch ein Compilerfehler. (Siehe Concepts für Arbeit daran.)
Und ja, mehr Sprachmittel lassen mehr Raum für Fehler. Da hat er Recht und das wird immer so sein. Aber schlechten Code kann man immer schreiben. Auch in C, auch in Java. Die Frage ist doch: Wie gut kann man guten Code schreiben?