[Unterschiede] Was geht in C nicht was in C++ geht bzw. umgekehrt ...
-
this->that schrieb:
Das hier geht (sinnvollerweise) in C++, aber in C nicht:
const int moep = 10; int foo[moep];
<klugscheiss>
je nach Kontext geht das auch in C(99).
</klugscheiss>
-
this->that schrieb:
Das hier geht (sinnvollerweise) in C++, aber in C nicht:
const int moep = 10; int foo[moep];
in C vor '99 macht man sinnvollsterweise das 'moep' mit einem #define.
-
Old School C User schrieb:
this->that schrieb:
Das hier geht (sinnvollerweise) in C++, aber in C nicht:
const int moep = 10; int foo[moep];
in C vor '99 macht man sinnvollsterweise das 'moep' mit einem #define.
In C89 muß man das 'moep' per #define festlegen - ob das sinnvoller ist, bezweifle ich.
@Nerd (und im weitesten Sinne auch Vorden): Es geht hier vor allem um Probleme, über die ein erfahrener C++'ler stolpern kann, wenn er mit C anfängt
(und als C++'ler ist man nicht gewohnt, struct's mit typedef anzulegen)
-
CStoll schrieb:
Old School C User schrieb:
this->that schrieb:
Das hier geht (sinnvollerweise) in C++, aber in C nicht:
const int moep = 10; int foo[moep];
in C vor '99 macht man sinnvollsterweise das 'moep' mit einem #define.
In C89 muß man das 'moep' per #define festlegen - ob das sinnvoller ist, bezweifle ich.
das kannst du bezweifen
in C ist es manchmal sehr sinnvoll.
topic: vor dem pre-increment operator muss man sich in C auch nicht fürchten. allgemein gesehen sind viele dinge, die in C++ zum 'guten ton' gehören, in C völlig fehl am platz.
-
Cthulhu schrieb:
CStoll schrieb:
Old School C User schrieb:
this->that schrieb:
Das hier geht (sinnvollerweise) in C++, aber in C nicht:
const int moep = 10; int foo[moep];
in C vor '99 macht man sinnvollsterweise das 'moep' mit einem #define.
In C89 muß man das 'moep' per #define festlegen - ob das sinnvoller ist, bezweifle ich.
das kannst du bezweifen
in C ist es manchmal sehr sinnvoll.
In C ist der Präprozessor nur aus einem Grund "sinnvoll" - weil einige Konstrukte nicht ohne seine Hilfe gelöst werden können.
topic: vor dem pre-increment operator muss man sich in C auch nicht fürchten. allgemein gesehen sind viele dinge, die in C++ zum 'guten ton' gehören, in C völlig fehl am platz.
"völlig fehl am platz" ist wohl ein wenig übertrieben. Der Unterschied zwischen Prä-Inkrement und Post-Inkrement ist zwar in C nicht so bedeutend wie in C++ (ohne Operator-Überladungen ist es leichter zu optimieren), aber deswegen sind solche C++ Stil-Tips in C zumindest nicht kontraproduktiv (will heißen, es schadet niemandem, wenn ich konsequent '++i' schreibe).
-
CStoll schrieb:
In C ist der Präprozessor nur aus einem Grund "sinnvoll" - weil einige Konstrukte nicht ohne seine Hilfe gelöst werden können.
[/quote]
du bist wohl auch so ein freund von präprozzi-losen sprachen? ich z.b. wünschte, in Java gäbe es einen.CStoll schrieb:
topic: vor dem pre-increment operator muss man sich in C auch nicht fürchten. allgemein gesehen sind viele dinge, die in C++ zum 'guten ton' gehören, in C völlig fehl am platz.
"völlig fehl am platz" ist wohl ein wenig übertrieben. Der Unterschied zwischen Prä-Inkrement und Post-Inkrement ist zwar in C nicht so bedeutend wie in C++ (ohne Operator-Überladungen ist es leichter zu optimieren), aber deswegen sind solche C++ Stil-Tips in C zumindest nicht kontraproduktiv (will heißen, es schadet niemandem, wenn ich konsequent '++i' schreibe).
schaden nicht direkt, aber man muss sich mit solchem unsinn auch nicht belasten, der nur vom wesentlichen ablenkt.
-
Abdul Alhazred schrieb:
CStoll schrieb:
In C ist der Präprozessor nur aus einem Grund "sinnvoll" - weil einige Konstrukte nicht ohne seine Hilfe gelöst werden können.
du bist wohl auch so ein freund von präprozzi-losen sprachen? ich z.b. wünschte, in Java gäbe es einen.
Nein, ich verteufele den Präprozessor nicht, aber ich kenne seine Grenzen (die wichtigste: der Präprozessor führt nur blinde Textersetzungen durch, ohne sich um die Sprachstruktur von C zu kümmern). Und wenn ich die Wahl habe, ein Problem mit sprachinternen Mitteln oder mit Hilfe eines Präprozessors zu lösen, wähle ich ersteres.
CStoll schrieb:
schaden nicht direkt, aber man muss sich mit solchem unsinn auch nicht belasten, der nur vom wesentlichen ablenkt.
Und was ist "das wesentliche"?
PS: Das Zitieren üben wir aber noch
-
CStoll schrieb:
schaden nicht direkt, aber man muss sich mit solchem unsinn auch nicht belasten, der nur vom wesentlichen ablenkt.
Und was ist "das wesentliche"?
das wesentlich an den pre/post-inc/dec's ist, ob man den alten wert oder den bereits veränderten wert haben will und nicht, ob vielleicht irgendwelche überflüssigen objektkopien erzeugt werden könnten (was in C++ passieren kann). in C brauchst du dich nicht mit solch fiesen sprachmängeln herumzuärgern, die mit dem eigentlichen problem nichts zu tun haben.
-
Das geht total am Thema vorbei, da, wie CStoll schon erwähnt hat, dies kein Fallstrick ist, in den ein "C++ auf C"-Umsteiger reinlaufen könnte. Im übrigen wird dies hier auch kein C <-> C++ Flame werden.
Edit: Etwas entfernt weil verlesen.
-
this->that schrieb:
Das hier geht (sinnvollerweise) in C++, aber in C nicht:
const int moep = 10; int foo[moep];
Ist es nicht so, dass man in C soger sowas machen kann:
int moep = 10; int foo[moep];
Meine da mal was gelesen zu haben... dynamische Stack-Arrays, oder so.EDIT: ahja, VLAs
Gruß
Don06
-
C99 unterstützt VLAs (Variable-Length-Arrays), C89 noch nicht. Damit ist dann sowas möglich:
void foo(size_t size) { int bar[size]; // mache was mit bar }
-
OhneName schrieb:
C99 unterstützt VLAs (Variable-Length-Arrays), C89 noch nicht.
in c89/90 konnte man sich damit behelfen: http://blogs.sun.com/ambiguous/entry/a_safe_way_of_using
-
OT:
Die ganzen Unreg-Beiträge haben immer eine Smiley () am Schluss. Das erinnert mich an jemanden, oder die Unregs wollen uns nur täuschen ...
-
KasF schrieb:
OT:
Die ganzen Unreg-Beiträge haben immer eine Smiley () am Schluss. Das erinnert mich an jemanden, oder die Unregs wollen uns nur täuschen ...
du täuschst dich nicht. ich bin jetzt unreg.
(hast du bestimmt auch am geläster über C++ gemerkt).
-
Das ist mir auch aufgefallen
-> komisch wie sehr man einen schreibstil und die dahintrliegende person erkennen kann[] autobahn; ... ..., ...