c++

[Jennesta]

Aber vielleicht kann sich jemand zu dem Thema äussern, der mit C++ begonnen hat? Würde mich auch interessieren

Dann mache ich das mal.

Ich habe mit C++ privat angefangen und musste in der Uni zwangsläufig C lernen. Das war dann etwas kompliziert, weil man gerade als Anfänger nicht richtig unterscheiden kann was nun noch C ist oder schon C++ (im Grunde kein Problemw enns keien Klausuren gäbe).
Geschadet hat mir das nun aber auch nicht. Gerade in meinem Umfeld, wo es auf die Geschwindigkeit des Codes ankommt habe ich die Möglichkeiten auf die Eigenschaften von C zurückzugreifen, aber auch die Vorzüge von C++ zu nutzen. Man sollte ggf. nur wissen was man wann und warum macht.

Ich denke die Wahl hängt auch einfach auch extrem vom Kontext ab, indem man programmiert. Leute die die Windows API für GUIs nutzen greifen möglicherweise weniger auf C++ Eigenschaften zurück als Leute, die z.B. Qt nutzen. Leute die sehr hardwarenah programmieren wie z.B. bei Microcontrollern greifen auf C zurück.

Man sollte einfach beides kennen, wenn man nicht ganz eingeschränkt programmieren will. Auch sollte man wissen was der Compiler wirklich macht, soll heißen das C-Code nicht automatisch C-Code ist, wenn ein C++Compiler benutzt wird.

Gruß,
Jennesta

 

[cwriter]

Dann mache ich das mal.

Ich bitte darum

Ich habe mit C++ privat angefangen und musste in der Uni zwangsläufig C lernen. Das war dann etwas kompliziert, weil man gerade als Anfänger nicht richtig unterscheiden kann was nun noch C ist oder schon C++ (im Grunde kein Problem wenn's keine Klausuren gäbe).

Was denkst du, wäre heute anstrengender? C++ zu C oder umgekehrt?

Geschadet hat mir das nun aber auch nicht. Gerade in meinem Umfeld, wo es auf die Geschwindigkeit des Codes ankommt habe ich die Möglichkeiten auf die Eigenschaften von C zurückzugreifen, aber auch die Vorzüge von C++ zu nutzen. Man sollte ggf. nur wissen was man wann und warum macht.

Das ist immer wünschenswert

Ich denke die Wahl hängt auch einfach auch extrem vom Kontext ab, in dem man programmiert. Leute die die Windows API für GUIs nutzen, greifen möglicherweise weniger auf C++ Eigenschaften zurück als Leute, die z.B. Qt nutzen. Leute die sehr hardwarenah programmieren wie z.B. bei Microcontrollern greifen auf C zurück.

Kann ich so unterschreiben.

Man sollte einfach beides kennen, wenn man nicht ganz eingeschränkt programmieren will. Auch sollte man wissen was der Compiler wirklich macht, soll heißen das C-Code nicht automatisch C-Code ist, wenn ein C++-Compiler benutzt wird.

C-Code ist nicht automatisch C-Code? Wie meinen?

Gruss
cwriter

 

[sheel]

zB. das Name mangling, das zum Problem werden kann, wenn man als C kompiliertes Zeug damit verlinken will.
Oder ein paar Codesachen, die in beiden Sprachen gültig sind, aber verschiedene Sachen machen.
Oder...

Hab mit C angefangen und zurzeit nichts, was nicht schon gesgat wurde, sorry

 

[cwriter]

zB. das Name mangling, das zum Problem werden kann, wenn man als C kompiliertes Zeug damit verlinken will.

Hm. Wenn derselbe Compiler verwendet wird (und das sollte er...), dann dürfte zumindest das statische Linken mit der korrekt mit extern "C"{} ummantelten Headerdatei kein Problem sein. Ich hatte zumindest mit Visual Studio noch nie Probleme damit. Ausser natürlich, wenn man mit GetProcAddr() und Co. arbeiten will.

Was hat denn in C und C++ unterschiedliche Wirkung bei gleichem Namen (mal von den üblichen Verdächtigen wie float/double/int Überladungen bei math.h abgesehen)? Ich zähle mich selbst zu den Missetätern der C/C++-Mischer, aber das schlimmste, was ich an Problemen hatte, war inline asm mit cdecl und stdcall.

Gut, damals haben mich Reference Pointer verwirrt, als ich sie zum ersten Mal gesehen und mich gewundert habe, warum & jetzt plötzlich in der Parameterliste ist und warum z.B. bei Structs dann '.' und nicht '->' stehen soll. Aber die Wirkung ist nicht undefined, also auch nicht soo schlimm.

Gruss
cwriter

 

[sheel]

Hier ein paar Sachen: http://stackoverflow.com/questions/...and-c-produce-different-behavior-when-compile

Und extern"C" ist ein C++-only-Ding (nur VS kapiert das nicht).
Also in C-Code das immer von Anfang an reintun wird in reinen C-Situationen dann nicht kompilieren.

 

[Jennesta]

Hm. Wenn derselbe Compiler verwendet wird (und das sollte er...), dann dürfte zumindest das statische Linken mit der korrekt mit extern "C"{} ummantelten Headerdatei kein Problem sein. Ich hatte zumindest mit Visual Studio noch nie Probleme damit. Ausser natürlich, wenn man mit GetProcAddr() und Co. arbeiten will.

Das Problem ist, dass gerade bei MS eben nicht gewährleistet ist, dass der selbe Compiler auch derselbe Compiler ist. Es reicht schon ein Servicepack, Hotfix oder Update für dieselbe VS Version zu installieren und der Code ist unter Umständen nicht mehr binärkompatibel.

Allerdings wollte ich mit dem Kommentar sogar eher darauf hinaus, das man darauf aufpassen muss, wie man diverse Dateien kompiliert. Bei VS z.B. kann man angeben ob der Code als C oder C++ Code kompiliert werden soll. Und nicht immer wird automatisch mit der Dateiendung *.c auch C Code assoziiert. Auch wenn ich jetzt kein Experte bin, was die Compiler angeht. Jedoch ist es schon ein gravierender Unterschied.

Allerdings sind das nun auch keine Anfängerprobleme

Was denkst du, wäre heute anstrengender? C++ zu C oder umgekehrt?

Schwer zu sagen. Da der Umfang aber gerade durch C++11 eher gewachsen ist, kommt man möglicherweise einfacher mt C in die Materie und kann sein gelerntes einfach erweitern. Auf der anderen Seite hat man es gerade als Anfänger mit den streams und strings sehr viel einfacher schnell Ausgaben ohne Fehler zu machen (man denke an den Unterscheid zwischen char* und const char* und das man immer die Länge wissen muss für alle möglichen Funktionen, etc. ...)

 

[cwriter]

Hier ein paar Sachen: http://stackoverflow.com/questions/...and-c-produce-different-behavior-when-compile

Ich habe mal einige angeschaut. Aber fast alle Beispiele beinhalten "schlechten" Code. Z.B. beim struct-Beispiel: Wer nutzt denn schon gleiche Variabelnnamen? Oder die sizeof('a')-Sache: Die tatsächliche Relevanz dürfte sich in Grenzen halten. Grundsätzlich würde ich ohnehin nie sizeof(variable), sondern immer nur sizeof(Typ) nutzen. Das funktioniert gerade auch bei memcpy()-Operationen um ein Vielfaches besser.

Klar, du hast Recht mit der Aussage, dass C/C++ nicht immer dasselbe ist. Aber dass man neue Keywords wie z.B. auto nicht durch einen C-Compiler jagen sollte, zähle ich mal zu gesundem Menschenverstand.

Und bei extern "C" {} hilft ein #ifdef __cplusplus.

@Jennesta
Meinst du die Updates? Z.B. bei VS2012 gab es halt VS2012U[1-4], aber die sind entsprechend gekennzeichnet. Auch wenn sich nur die Minor Version unterscheidet, erachte ich das als anderen Compiler. Ist das denn bei g++ anders?

Gruss
cwriter

 

[sheel]

Schlechter Code: Kann schon sein, aber das ändert ja nichts daran, dass es gültig ist.
auto: Auch das ist in C gültig.
...
Beides und ifdef: Eben, Sachen wie ifdef und aufpassen dass man xyz nicht verwendet etc.
Man "kann" C-Code schon so schreiben, dass er auch gültiges C++ ist. Nur gehts eben auch anders.
Und es ist auch nicht alles schlecht, zB. VLAs... (auch wenn schlecht natürlich subjektiv ist)

Versionskompatibilität bei G++ auf Linux:
Seit Version 3.4 (April 2004) funktionieren dass kompilierte Binaries von älteren G++-Versionen
auch mit neueren G++´s (umgekehrt nicht unbedingt). Heißt nicht, dass es nicht irgendwann wieder
einen Umbruch geben kann, aber offensichtlich strengen sie sich an, dass das nicht passiert.