In C89 zu programmieren...

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

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

Sieht halt dann entsprechend aus...

- 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=minix.git;a=commitdiff;h=f0f34dd8d9dc89a607730dbc697bd505c2773182

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.

- 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

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

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

Steffo schrieb:

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

http://git.minix3.org/?p=minix.git;a=commitdiff;h=f0f34dd8d9dc89a607730dbc697bd505c2773182

Ich sehe da kein VLA.

Kenner der Wichtigtuer schrieb:

Steffo schrieb:

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

http://git.minix3.org/?p=minix.git;a=commitdiff;h=f0f34dd8d9dc89a607730dbc697bd505c2773182

Ich sehe da kein VLA.

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

Man muss mit VLAs tatsächlich vorsichtig umgehen:

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

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

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

Bashar

Wie denn?

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.

Bashar

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

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.

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.

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