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

Unregistrierter 22:05:35 11.04.2012 Titel:

... verursacht heutzutage mehr Probleme als es löst...

Hab mich mit Erlaubnis davon distanziert!

Das musste mal gesagt werden! :mad:

cooky451 Mitglied 22:19:39 11.04.2012 Titel:

Haha, geil.

Z Mitglied 22:54:47 11.04.2012 Titel:

Steffo schrieb:

... verursacht heutzutage mehr Probleme als es löst...

Hab mich mit Erlaubnis davon distanziert!

Das musste mal gesagt werden! :mad:

Welche Probleme?

Zeus Mitglied 22:57:37 11.04.2012 Titel:

Z schrieb:

Steffo schrieb:

...

Welche Probleme?

Umgang mit der Sprache, welche sonst? :P

Unregistrierter 23:16:07 11.04.2012 Titel:

Zeus schrieb:

Z schrieb:

Welche Probleme?

Umgang mit der Sprache, welche sonst? :P

:P

Problem war hauptsächlich, dass ich eine POSIX-Funktion srandom() mit gcc und den Optionen -ansi -pedantic kompilieren wollte. Ging natürlich nicht, weil das ja kein Standard ist.

Die Man-Page sagt dazu:

Code:
Feature Test Macro Requirements for glibc (see feature_test_macros(7)): random(), srandom(), initstate(), setstate(): _SVID_SOURCE \|\| _BSD_SOURCE \|\| _XOPEN_SOURCE >= 500 \|\| _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED

Ich hab dann mit der Option -D_XOPEN_SOURCE=600 kompiliert und es hat wunderbar unter Fedora kompiliert.

Ich gebe also meine Lösung und mein Makefile dem Tutor ab und 1 Woche später sehe ich, dass ich 5% Abzug bekommen habe, weil die C-Datei mit srandom() nicht kompilieren wollte. Ich wollte das zuerst nicht glauben, aber unter Ubuntu an der Hochschule wollte das tatsächlich nicht kompilieren! Die Fehlermeldung war absolut nichtssagend und kryptisch. Jedenfalls ging das dann ohne den Optionen -ansi und -pedantic.

Aber auch der 89er-Standard an sich nervt mich:

- Keine statischen Array-Größen per Variablen angebbar, so dass man malloc() benutzen muss --> unsicher und unperformant.

- Variablen müssen immer am Anfang des Funktionsrumpf definiert werden. Mehrfache Verwendung von abgekapselte Variablen sind so nicht möglich (z. B. in for-Schleifen).

- Kommentare: // nicht möglich.

- Kein restrict: Performance-Nachteil

Diese Dinge stören mich am meisten...

L. G.
Steffo

Unregistrierter

Warum hast du nicht einfach srand benutzt?

Was for-Schleifen angeht, so kann man das Scope-Verhalten von C99 nachbauen, wenngleich das dann nicht sonderlich hübsch aussieht:

C++:
{ int i; for(i = 0; i < 10; ++i) { ... } }

Ansonsten kannst du in deine Makefile natürlich statt -ansi auch -std=c99 schreiben, obwohl srandom auch in C99 nicht enthalten ist.

Wenn du aber wirklich mal Produktionscode in C schreiben musst, wird der Umstand, dass Microsoft sich nicht um die Erfüllung des C99-Standards schert, auf absehbare Zeit an C89 ketten (es sei denn, Portabilität spielt überhaupt keine Rolle). Das muss man nicht mögen, aber Drohbriefe brächten wahrscheinlich auch nichts.

Z Mitglied 23:50:36 11.04.2012 Titel:

Steffo schrieb:

Zeus schrieb:

Z schrieb:

Welche Probleme?

Umgang mit der Sprache, welche sonst? :P

:P

Problem war hauptsächlich, dass ich eine POSIX-Funktion srandom() mit gcc und den Optionen -ansi -pedantic kompilieren wollte. Ging natürlich nicht, weil das ja kein Standard ist.

Die Man-Page sagt dazu:

Code:
Feature Test Macro Requirements for glibc (see feature_test_macros(7)): random(), srandom(), initstate(), setstate(): _SVID_SOURCE \|\| _BSD_SOURCE \|\| _XOPEN_SOURCE >= 500 \|\| _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED

Ich hab dann mit der Option -D_XOPEN_SOURCE=600 kompiliert und es hat wunderbar unter Fedora kompiliert.

Ich gebe also meine Lösung und mein Makefile dem Tutor ab und 1 Woche später sehe ich, dass ich 5% Abzug bekommen habe, weil die C-Datei mit srandom() nicht kompilieren wollte. Ich wollte das zuerst nicht glauben, aber unter Ubuntu an der Hochschule wollte das tatsächlich nicht kompilieren! Die Fehlermeldung war absolut nichtssagend und kryptisch. Jedenfalls ging das dann ohne den Optionen -ansi und -pedantic.

Aber auch der 89er-Standard an sich nervt mich:

- Keine statischen Array-Größen per Variablen angebbar, so dass man malloc() benutzen muss --> unsicher und unperformant.

- Variablen müssen immer am Anfang des Funktionsrumpf definiert werden. Mehrfache Verwendung von abgekapselte Variablen sind so nicht möglich (z. B. in for-Schleifen).

- Kommentare: // nicht möglich.

- Kein restrict: Performance-Nachteil

Diese Dinge stören mich am meisten...

L. G.
Steffo

- Nimm einfach rand() und srand(). Das geht immer und dann brauchst du auch nicht mit irgendwelchen komischen Compiler-Options herumzufummeln.

- Auch in C89 kannst du schleifenlokale Variablen anlegen (direkt nach der öffnenden, geschweiften Klammer).

- C ist eine Art portable Assemblersprache, deshalb finde ich Automatismen, die sich hinter VLAs verbergen, eher unpassend. Ich finde, wer auf VLAs angewiesen ist, macht etwas falsch.

- Der Rest wird von dir überbewertet. Restricted Pointers z.B. sind ein nettes Feature um dem Compiler zu helfen, aber nicht wirklich lebensnotwendig.

Unregistrierter

war ansi nicht c90? In c89 sollte es auch kein const geben.

Zitat:

Variablen müssen immer am Anfang des Funktionsrumpf definiert werden. Mehrfache Verwendung von abgekapselte Variablen sind so nicht möglich (z. B. in for-Schleifen)

wohl eher am Anfang eines Blocks.

Unregistrierter 02:11:12 12.04.2012 Titel:

Z schrieb:

- Nimm einfach rand() und srand(). Das geht immer und dann brauchst du auch nicht mit irgendwelchen komischen Compiler-Options herumzufummeln.

Wir benutzen ziemlich oft POSIX-Schnittstellen. Der C-Standard wird nicht alles abdecken können...

Zitat:

- Auch in C89 kannst du schleifenlokale Variablen anlegen (direkt nach der öffnenden, geschweiften Klammer).

Sieht halt dann entsprechend aus...

Zitat:

- C ist eine Art portable Assemblersprache, deshalb finde ich Automatismen, die sich hinter VLAs verbergen, eher unpassend. Ich finde, wer auf VLAs angewiesen ist, macht etwas falsch.

VLAs sind sehr praktisch: Man braucht keinen Malloc-Funktionsaufruf, die Ausnahmebehandlung entfällt, das free() und der Gedanke, wann man Speicher wieder frei gibt, ebenso.

Versuch mal beim Minix-Kernel einen malloc() zu finden!
Hier siehst du einen Patch, der einen malloc() durch ein VLA ersetzt:

http://git.minix3.org/?p= ....... 607730dbc697bd505c2773182

So etwas ist einfach nicht gerne gesehen...

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...

Tanenbaum ist sich selbst gegenüber kritisch genug, um mallocs zu vermeiden wo es nur geht. Im Kernel selbst kommt kein einziges malloc() vor. In einigen Treiber können sie vereinzelt vorkommen.

Zitat:

- Der Rest wird von dir überbewertet. Restricted Pointers z.B. sind ein nettes Feature um dem Compiler zu helfen, aber nicht wirklich lebensnotwendig.

Man kann damit verdammt gut optimieren...

L. G.
Steffo

cooky451 Mitglied 02:53:14 12.04.2012 Titel:

Steffo schrieb:

VLAs sind sehr praktisch

Nein, VLAs sind schrecklich. Also wirklich, absolut schrecklich. Das Grauen auf Erden. Wenn die Menschheit ausstirbt, dann wegen VLAs!
Was aber wirklich nett wäre, wäre ein alloca Äquivalent im Standard.

Und ja, C hat definitiv ein Problem was Resource-Management angeht. Und ja, du hast recht. Warum sollte man in C Programmieren? Es gibt aus sprachlicher Sicht eigentlich keine Gründe dafür. Selbst wenn man keine Exceptions und keine Polymorphie will, Destruktoren sind etwas, das C einfach fehlt. (Obwohl es natürlich nicht zur Sprache passen würde.)

Allerdings stellt sich die Frage, was du mit diesem Thread bezwecken willst. Die meisten User hier werden wohl C++ bevorzugen, und niemand hier wird den Lehrplan deiner Uni ändern können. Wenn du diese Diskussion führen willst, dann bitte gleich mit dem MOC (Master Of C) persönlich: Linus.

TyRoXx Mitglied 08:01:13 12.04.2012 Titel:

cooky451 schrieb:

Und ja, C hat definitiv ein Problem was Resource-Management angeht. Und ja, du hast recht. Warum sollte man in C Programmieren? Es gibt aus sprachlicher Sicht eigentlich keine Gründe dafür. Selbst wenn man keine Exceptions und keine Polymorphie will, Destruktoren sind etwas, das C einfach fehlt. (Obwohl es natürlich nicht zur Sprache passen würde.)

Allerdings stellt sich die Frage, was du mit diesem Thread bezwecken willst. Die meisten User hier werden wohl C++ bevorzugen, und niemand hier wird den Lehrplan deiner Uni ändern können. Wenn du diese Diskussion führen willst, dann bitte gleich mit dem MOC (Master Of C) persönlich: Linus. ;)

Der Blödmann ist gegen C++, weil man damit viel leichter Scheiße produzieren kann. C++ ist "in", jeder Vollidiot kopiert sich aus dem Internet etwas zusammen. C ist für Anfänger eher unattraktiv, weil man Hintergrundwissen benötigt, um die Sprachkonzepte zu verstehen und sinnvoll anzuwenden.
C++ hat eine lange Entwicklung von C mit Klassen zu C++11 erlebt. Compiler kommen langsam hinterher, Literatur wird nicht jünger und die Nähe zu C verleitet zu scheußlichen Hacks. C++ ist also ein großes Durcheinander und nur erfahrene Programmierer können damit guten Code bauen, weil sie schon viele Fehler kennen, die man machen kann.
C ist viel schlanker, es gibt nicht zig Möglichkeiten, etwas zu lösen. Zum Beispiel gibt es keine Methoden, Lambdas, Konstruktoren, überladbare Operatoren, sondern einfach nur Funktionen, die man nicht einmal überladen kann. C hat sich auch nicht stark verändert. Aus Kompatibilitätsgründen verwendet man meist C89 und gut ist.
C++ ist als Sprache überlegen, aber das ist in der Praxis nicht das einzige Kriterium. Bei Linux reicht C eben aus und man vermeidet die Probleme von C++.

Unregistrierter

Steffo schrieb:

Hier siehst du einen Patch, der einen malloc() durch ein VLA ersetzt:

http://git.minix3.org/?p= ....... 607730dbc697bd505c2773182

Ich sehe da kein VLA.

Unregistrierter 10:57:12 12.04.2012 Titel:

Kenner der Wichtigtuer schrieb:

Steffo schrieb:

Hier siehst du einen Patch, der einen malloc() durch ein VLA ersetzt:

http://git.minix3.org/?p= ....... 607730dbc697bd505c2773182

Ich sehe da kein VLA.

OK, ich nehme alles zurück und behaupte das Gegenteil.

Unregistrierter 11:46:05 12.04.2012 Titel:

Man muss mit VLAs tatsächlich vorsichtig umgehen:

Code:
One problem that may be hidden by a language's support for VLAs is that of the underlying memory allocation: in environments where there is a clear distinction between a heap and a stack, it may not be clear which, if any, of those will store the VLA. For example, the GNU C Compiler allocates memory for VLAs on the stack. If a VLA is too large, no error occurs immediately; instead, attempts to use the VLA may lead to segmentation faults later in the execution of the program.

http://en.wikipedia.org/wiki/Variable-length_array

Unregistrierter

Dieses spezielle Problem besteht allerdings auch bei Arrays fester Länge.

Unregistrierter 15:56:27 12.04.2012 Titel:

Allerdings kannst du das dann besser kontrollieren, weil dir die Größe bekannt ist.

Bashar Mitglied 16:05:47 12.04.2012 Titel:

Wie denn?

Unregistrierter 16:46:28 12.04.2012 Titel:

Wenn ich weiß, ich brauch einen Puffer von 1 MB, dann würde ich nicht auf die Idee kommen den Puffer auf dem Stack zu alloziieren. :P

Bashar Mitglied 16:51:51 12.04.2012 Titel:

Und wenn du einen Puffer von 128 Bytes brauchst? Woher weißt du dann, ob der Stack ausreicht?

Rhetorische Frage, kürzen wirs ab: Du weißt es nicht.

knivil Mitglied 16:57:01 12.04.2012 Titel:

Zitat:

VLAs sind sehr praktisch: Man braucht keinen Malloc-Funktionsaufruf, die Ausnahmebehandlung entfällt, das free() und der Gedanke, wann man Speicher wieder frei gibt, ebenso.

Benutze bitte keine Messer, du koenntest dich sehr oft schneiden. Nimm bitte Java und ueberlasse C den echten Programmierern.

Zitat:

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...

Genau. Auch gibt es "Lint"-Tools, die das ueberpruefen. Und nochmal: Bitte benutze kein Messer.

Das musste mal gesagt werden! Ach ja, ich distanziere mich sofort wieder davon.

Unregistrierter 18:06:25 12.04.2012 Titel:

@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? :rolleyes:

Bashar Mitglied 18:11:18 12.04.2012 Titel:

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?

Z Mitglied 00:23:33 13.04.2012 Titel:

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 Mitglied 00:28:01 13.04.2012 Titel:

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.]

Z Mitglied 00:42:06 13.04.2012 Titel:

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 Moderator 00:52:04 13.04.2012 Titel:

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.

Zitat:

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

Nein.

Zitat:

spätestens wenn du mit Klassen hantierst.

Nein.

Zitat:

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

Nein.

Z Mitglied 01:06:38 13.04.2012 Titel:

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.

Zitat:

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

Nein.

Zitat:

spätestens wenn du mit Klassen hantierst.

Nein.

Zitat:

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

Nein.

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

SeppJ Moderator 01:22:52 13.04.2012 Titel:

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 Mitglied 01:28:15 13.04.2012 Titel:

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 Mitglied 08:50:46 13.04.2012 Titel:

Steffo schrieb:

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

Super, ist doch passend zum Thread.

Zitat:

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

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

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?

SeppJ Moderator 15:08:05 13.04.2012 Titel:

Scherzbold. Stackobjekte mit Heapobjekten vergleichen :rolleyes:

. 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?

TyRoXx Mitglied 17:58:55 13.04.2012 Titel:

Z schrieb:

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

Inhaltsangabe: Mimimi, es gibt eine Programmiersprache, die ich nicht verstehe!
:rolleyes:

Ethon Mitglied 19:07:43 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.

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.

Wutz Mitglied 14:09:22 14.04.2012 Titel:

Z schrieb:

Ich finde, wer auf VLAs angewiesen ist, macht etwas falsch.

Wohl wahr.

Wutz Mitglied 14:28:36 14.04.2012 Titel:

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.

Unregistrierter

[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.

Unregistrierter 21:45:10 14.04.2012 Titel:

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.

knivil Mitglied 02:14:25 15.04.2012 Titel:

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.

nachtfeuer Moderator 06:30:28 15.04.2012 Titel:

C ist alt...

Cybertec Mitglied 11:06:53 15.04.2012 Titel:

nachtfeuer schrieb:

C ist alt...

ROFL

Was ein Argument! :rolleyes:

Unregistrierter 11:32:51 15.04.2012 Titel:

nachtfeuer schrieb:

C ist alt...

Die aktuellste Version von C ist gerade mal ein paar Wochen alt: http://gcc.gnu.org/gcc-4.7/

Unregistrierter

Es gibt einen Unterschied zwischen einem C-Compiler und dem C-Standard (dessen letzte Revision im Oktober 2011 verabschiedet wurde). Allerdings ist das eine etwas seltsame Art, das Alter zu messen - wenn du gestern Geburtstag hattest, bist du ja auch nicht unbedingt erst einen Tag alt.

Unregistrierter 14:35:51 15.04.2012 Titel:

seldon schrieb:

Es gibt einen Unterschied zwischen einem C-Compiler und dem C-Standard (dessen letzte Revision im Oktober 2011 verabschiedet wurde). Allerdings ist das eine etwas seltsame Art, das Alter zu messen - wenn du gestern Geburtstag hattest, bist du ja auch nicht unbedingt erst einen Tag alt.

Macht aber schon irgendwie Sinn, schließlich wird C ja weiterentwickelt, d. h. man hat mehr Möglichkeiten, mehr Macht. Wenn du das jetzt auf den Menschen überträgst, kommt nicht unbedingt dasselbe raus...

Unregistrierter 18:38:44 15.04.2012 Titel:

Eigentlich dachte ich die Ironie wäre nicht zu übersehen...

nachtfeuer Moderator 20:46:05 15.04.2012 Titel:

Tim schrieb:

nachtfeuer schrieb:

C ist alt...

Die aktuellste Version von C ist gerade mal ein paar Wochen alt: http://gcc.gnu.org/gcc-4.7/

ach, gcc...(

)

http://www.phrack.com/issues.html?issue=67&id=11#article
http://shootout.alioth.de ....... languages-are-fastest.php

aber...
Fortran ist alt...

knivil Mitglied 09:38:56 16.04.2012 Titel:

nachtfeuer schrieb:

C ist alt...

Lisp ist auch alt, aber alle kopieren dieses und jenes aus der Sprache. Darueber hinaus ist Alter ein sehr schwaches Kriterium.

nachtfeuer Moderator 03:50:47 17.04.2012 Titel:

knivil schrieb:

nachtfeuer schrieb:

C ist alt...

Lisp ist auch alt, aber alle kopieren dieses und jenes aus der Sprache. Darueber hinaus ist Alter ein sehr schwaches Kriterium.

In diesem Zusammenhang würde ich sagen, C ist zu jung, noch viel zu grün hinter den Ohren.
( http://archive.vector.org.uk/art10500180)

Aber
http://www.henning-thielemann.de/CHater.html