In C89 zu programmieren...

@knivil: Sorry, aber was ist das für ein idiotischer Beitrag?
Die, die sich für echte Programmierer halten, sind meist die, die ziemlich unsichere, unwartbare Bananensoftware schreiben.
VLAs sind auch nicht sicher, das sehe ich jetzt, aber hat nicht jeder mal klein angefangen und aus Fehlern gelernt?

Bashar

Steffo schrieb:

@knivil: Sorry, aber was ist das für ein idiotischer Beitrag?

knivil kann nicht anders. Was ist mit dir, wieso musst du darauf antworten?

cooky451 schrieb:

Und ja, C hat definitiv ein Problem was Resource-Management angeht.

Nein, C hat gar kein eingebautes Ressource Management. Das ist kein "Problem", das ist so gewollt.

cooky451 schrieb:

Und ja, du hast recht. Warum sollte man in C Programmieren? Es gibt aus sprachlicher Sicht eigentlich keine Gründe dafür.

Einen standardkonformen C-Code kannst du für fast jeden Prozessor compilieren lassen und er verhält sich überall gleich. Insbesondere dann, wenn du keine Library-Funktionen zum Speichermanagement benötigst. Keine andere Sprache leistet das.

cooky451

Z schrieb:

Nein, C hat gar kein eingebautes Ressource Management.

Sag ich ja.

Z schrieb:

Das ist kein "Problem", das ist so gewollt.

Sagte ich auch, was dem aufmerksamen Leser aufgefallen wäre. Edit: Also, ich sagte es ist gewollt. Ein Problem ist das natürlich trotzdem.

Z schrieb:

Einen standardkonformen C-Code kannst du für fast jeden Prozessor compilieren lassen und er verhält sich überall gleich. Insbesondere dann, wenn du keine Library-Funktionen zum Speichermanagement benötigst. Keine andere Sprache leistet das.

Doch. Jede Sprache lässt sich theoretisch für jeden Prozessor kompilieren. Und praktisch braucht g++ nur einen C Compiler. Wenn du also einen C Compiler hast, hast du auch einen C++ Compiler. [Allerdings gehört die Praxis natürlich nicht zur Sprachlichen Ebene, nur um das noch mal anzumerken.]

cooky451 schrieb:

Ein Problem ist das natürlich trotzdem.

Nein. Für dich vielleicht.

cooky451 schrieb:

Doch. Jede Sprache lässt sich theoretisch für jeden Prozessor kompilieren.

Aber nur theoretisch.

cooky451 schrieb:

Und praktisch braucht g++ nur einen C Compiler. Wenn du also einen C Compiler hast, hast du auch einen C++ Compiler.

Verschiedene Programmiersprachen u.ä. erzeugen C-Code als Output, C++ insbesondere, benötigt ein dynamisches Speichermanagement, spätestens wenn du mit Klassen hantierst. Hast du das nicht, wird dir C++ nicht viel nutzen.

SeppJ

Z schrieb:

cooky451 schrieb:

Doch. Jede Sprache lässt sich theoretisch für jeden Prozessor kompilieren.

Aber nur theoretisch.

~~Nein.~~ edit: Hier stand "Nein", weil es gut zu den anderen Neins passt. Aber im Prinzip hast du natürlich recht, da es in der Praxis nicht für jede Sprach und Prozessorkombination einen Compiler gibt. Aber
1. habe ich den starken Verdacht, dass du mit "nur theoretisch" meintest, dass das gar nicht geht, was aber nicht stimmt, daher mein "Nein".
2. gibt es natürlich auch Prozessoren, für die es keinen C-Compiler gibt.

Verschiedene Programmiersprachen u.ä. erzeugen C-Code als Output, C++ insbesondere, benötigt ein dynamisches Speichermanagement,

Nein.

spätestens wenn du mit Klassen hantierst.

Nein.

Hast du das nicht, wird dir C++ nicht viel nutzen.

Nein.

SeppJ schrieb:

Z schrieb:

cooky451 schrieb:

Doch. Jede Sprache lässt sich theoretisch für jeden Prozessor kompilieren.

Aber nur theoretisch.

~~Nein.~~ edit: Hier stand "Nein", weil es gut zu den anderen Neins passt. Aber im Prinzip hast du natürlich recht, da es in der Praxis nicht für jede Sprach und Prozessorkombination einen Compiler gibt. Aber
1. habe ich den starken Verdacht, dass du mit "nur theoretisch" meintest, dass das gar nicht geht, was aber nicht stimmt, daher mein "Nein".
2. gibt es natürlich auch Prozessoren, für die es keinen C-Compiler gibt.

Verschiedene Programmiersprachen u.ä. erzeugen C-Code als Output, C++ insbesondere, benötigt ein dynamisches Speichermanagement,

Nein.

spätestens wenn du mit Klassen hantierst.

Nein.

Hast du das nicht, wird dir C++ nicht viel nutzen.

Nein.

Doch, doch, doch, doch. Ohne Speichermanagement ist C++ so gut wie wertlos.

SeppJ

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.

cooky451

Um das also noch mal zusammenzufassen: Wo C geht, da geht auch C++. Obwohl das immer noch nicht gefragt war. Lesen wir noch mal nach:

cooky451 schrieb:

Es gibt aus sprachlicher Sicht eigentlich keine Gründe dafür.

Hm.. was dieses sprachlich da wohl zu suchen hat.

Aber mal zum "interessanteren" (a.k.a. nicht völlig am Thema vorbeigehenden) Teil der Diskussion:

Z schrieb:

Hast du das nicht, wird dir C++ nicht viel nutzen.

"Nicht viel" ist ziemlich viel*. Aber die Frage die sich jetzt natürlich stellt ist: Welchen Nachteil hast du denn?

* Templates (!), Referenzen, viel bessere OOP Unterstüzung, auto, Lambdas, ach, quasi jedes Sprachfeature von C++ ist total unabhängig von dynamischem Speicher.

knivil

Steffo schrieb:

@knivil: Sorry, aber was ist das für ein idiotischer Beitrag?

Super, ist doch passend zum Thread.

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

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

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

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

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.

SeppJ

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.

knivil

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

knivil

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.

cooky451

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?