[Unterschiede] Was geht in C nicht was in C++ geht bzw. umgekehrt ...

CStoll

Tim schrieb:

CStoll schrieb:

Kommentare //... sind neu in C++

*räusper*

Na gut - und in C99 (zum "alten" C Standard gehörten sie jedenfalls nicht)

Ahh, das mit der Parameterliste wusste ich auch gar nicht. Dann schau ich mir die Seite doch mal an ...

Vorden

CStoll schrieb:

Einige Punkte, die mir so bekannt sind:

C struct's haben keine Methoden

struct, union und enum definieren keine freistehenden Datentypen:
struct test
{
  int x,y;
};

//C++ (in C ein Fehler):
test var;
//C (auch in C++ erlaubt):
struct test var;
C erlaubt implizite Umwandlung von void* in typisierte Zeiger (C++ nicht)

Kommentare //... sind neu in C++

Edit: Achja, recht wichtig ist auch, daß eine leere Parameterliste in C und C++ etwas anderes bedeutet

...

(lies dir die Seite doch mal durch, da sind einige relevante Punkte erwähnt)

(und natürlich funktionieren die ganzen schönen C++ Features wie Überladung, Klassen oder Templates nicht in C)

du könntest allerdings für des struct nen netten typedef anlegen, so wie:

typedef struct
{
  int x,y
} test;

dann kannste des auch so benutzen:

test var;
var.x = 128;

CStoll

Vorden schrieb:

du könntest allerdings für des struct nen netten typedef anlegen, so wie:
typedef struct
{
  int x,y
} test;
dann kannste des auch so benutzen:
test var;
var.x = 128;

Darum ging es nicht - in C mußt du typedef verwenden, um der struct einen "vollwertigen" Namen zu geben, in C++ ist das nicht nötig.

Vorden

ich hab ja auch bloß geschrieben, dass du nen typedef verwenden könntest, um des zu verwenden, wie du es unter umständen gewohnt bist

KasF schrieb:

Wo könnte man als C++ Programmiere in die Fallen von C tappen ???

na, indem du in C++ wie in C programmierst, dann kannst du in alle fallen von C tapsen. C++ allein hat schon genug fussangeln.

this-*gt*that

Das hier geht (sinnvollerweise) in C++, aber in C nicht:

const int moep = 10;
int foo[moep];

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.

CStoll

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.

CStoll

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.

CStoll

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.

Don06

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

OhneName

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