In C89 zu programmieren...
-
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".
-
knivil schrieb:
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?
-
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.
-
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?
-
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.
-
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.
-
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
-
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.
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.
-
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?
-
Scherzbold. Stackobjekte mit Heapobjekten vergleichen
. Da weiß man gleich, dass ein kompetenter Programmierer am Werk ist.Im übrigen werden in C++ auch Heapobjekte nicht initialisiert, wenn's nichts zu initialisieren gibt und in C werden Stackobjekte genau so wie in C++ initiailisiert, wenn es was zu initialisieren gibt. Also nächstes Mal lieber erst mal informieren, worüber man redet, bevor man alte Legenden unreflektiert nachplappert. Was kommt als nächstes? Die Feststellung, dass ein Compiler bei virtueller Vererbung Code erzeugt?
-
Z schrieb:
Lies das: http://www.fefe.de/c++/c%2B%2B-talk.pdf
Inhaltsangabe: Mimimi, es gibt eine Programmiersprache, die ich nicht verstehe!
-
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.
Ich glaub du bringst da etwas durcheinander. In den Konstruktor kommt das, was du sowieso machen musst, um etwas ausführen zu können. Als C-Beispiel: fopen, wenn du mit einer Datei arbeiten möchtest.
In den Destruktor kommt dann das, was du sowieso machen musst, um aufzuräumen. Als C-Beispiel: fopen, um nichts zu leaken.
Im Endeffekt wird kein Byte mehr Code generiert. Außer man macht Mist. Ansonsten aber nicht.
-
Z schrieb:
Ich finde, wer auf VLAs angewiesen ist, macht etwas falsch.
Wohl wahr.
-
TyRoXx schrieb:
C ist für Anfänger eher unattraktiv, weil man Hintergrundwissen benötigt, um die Sprachkonzepte zu verstehen und sinnvoll anzuwenden.
C ist von Programmierern für Programmierer oder wenn man so will von Praktikern für Praktiker entwickelt worden und das damals mit einem KONKRETEN Hintergrund, nämlich UNIX. Und weil sie schon dabei waren, haben sie auch gleich noch Compiler selbstentwickelt und ihn sogar eingesetzt, im Gegensatz zu Stroustrup.
Und auch deswegen hat damals niemand Wert auf C als Lernsprache gelegt, wie bei anderen, d.h. C erhebt überhaupt keinen Anspruch, leicht erlernbar, anschaulich, unkryptisch zu sein oder sonst irgendwelchen Ansprüchen zu genügen. Und wenn irgendwelche Lehrer heutzutage, 40 Jahre später, C doch für Lernzwecke einsetzen, ...
Stroustrup hat bei seinem C mit Klassen eben keinen konkreten und vor allem akuten Hintergrund gehabt und lehrt jetzt noch als Professor irgendwo in Texas.TyRoXx schrieb:
Aus Kompatibilitätsgründen verwendet man meist C89 und gut ist.
Ein strikt konformes ANSI C(89) Programm ist maximal portabel.
Keine andere Sprache mit irgendwelchen Ausprägungen bietet das, wenn man sich auf originale Betriebs- und Embeddedsysteme beschränkt und heutige Browserumgebungen mal außen vor lässt.
-
[quote="Steffo"]
Z schrieb:
Stell dir vor, du macht am Anfang des Funktionsrumpfes ein malloc() und am Ende ein free(). Nach dem malloc() kommen jedoch verschiedene switch cases und eins davon macht ein return... Glückwunsch: Du hast ein Memory Leak.
Ich weiß... so etwas passiert DIR natürlich nicht...Selbst wenn: dank der heutigen Verfügbarkeit toller Tools wie Valgrind kann man sowas glücklicherweise meist verdammt schnell erkennen. Wer irgendwelchen Code raushaut, ohne zumindest vorher mal mit Valgrind drübergegangen zu sein, hat es auch nicht anders verdient.
Übrigens finde ich durchaus, dass VLAs eine Berechtigung haben. Was sie aber definitiv nicht tun, ist einen davon zu befreien, sich Gedanken um den verwendeten Speicher zu machen.
-
Horst Hansen schrieb:
Selbst wenn: dank der heutigen Verfügbarkeit toller Tools wie Valgrind kann man sowas glücklicherweise meist verdammt schnell erkennen. Wer irgendwelchen Code raushaut, ohne zumindest vorher mal mit Valgrind drübergegangen zu sein, hat es auch nicht anders verdient.
Übrigens finde ich durchaus, dass VLAs eine Berechtigung haben. Was sie aber definitiv nicht tun, ist einen davon zu befreien, sich Gedanken um den verwendeten Speicher zu machen.
Was, wenn der Memory Leak nur in bestimmten Konstellationen auftaucht? Valgrind alleine hilft dir da nicht weiter. Du müsstest dein Programm sinnvoll mit Parameter füttern, um möglichst viele Konstellationen zu testen.
-
Steffo schrieb:
Was, wenn der Memory Leak nur in bestimmten Konstellationen auftaucht? Valgrind alleine hilft dir da nicht weiter. Du müsstest dein Programm sinnvoll mit Parameter füttern, um möglichst viele Konstellationen zu testen.
Na hier spricht ja der Profi, leider sehr schwammig und vage. Natuerlich haben sich auch andere Gedanken gemacht, du bist nicht der erste. Tools fuer Code Coverage und Testgenerierung existieren auch.
-
C ist alt...
-
nachtfeuer schrieb:
C ist alt...
ROFL
Was ein Argument!
-
nachtfeuer schrieb:
C ist alt...
Die aktuellste Version von C ist gerade mal ein paar Wochen alt: http://gcc.gnu.org/gcc-4.7/
