Der Name "C++"

[icwiener]

lucky_tux schrieb:

Nein. Ich habe den C-Compiler gcc aufgerufen.

$ man gcc
C++ source files conventionally use one of the suffixes .C, .cc, .cpp, .CPP, .c++, .cp, or .cxx; [...] GCC recognizes files with these names and compiles them as C++ programs even if you call the compiler the same way as for compiling C programs (usually with the name gcc).

MfG

[Erhard Henkes]

Aus Compiler-Fragen halte ich mich raus, das ändert sich ständig. Windows hat übrigens recht wenig mit C++ zu schaffen, es basiert im Wesentlichen auf C und WinAPI. Neuere C++-GUI-Frameworks versuchen es verstärkt sich im Sinne der OOP an C++ anzulehnen.

Lassen wir doch noch mal den Erfinder der ersten C++-Generation zu Wort kommen:

C++ is a general purpose programming language with a bias towards systems programming that

* is a better C
* supports data abstraction
* supports object-oriented programming
* supports generic programming.

http://www.research.att.com/~bs/C++.html (May 10, 2006)

Daher sollte man auch die Entwicklung von C erwähnenen, auf dessen Fundamente C++ immer noch stabil ruht.

http://cm.bell-labs.com/cm/cs/who/dmr/
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
http://cm.bell-labs.com/cm/cs/who/dmr/bigbio1st.html

Interessanter ist eigentlich die Frage nach der Weiterentwicklung von C++, um Schwächen zu entfernen und Stärken zu betonen.

http://de.wikipedia.org/wiki/C++

Stärken

* Die Erzeugung hocheffizienten Codes ist möglich.
* Sowohl maschinennahe als auch hochabstrakte Programmierung ist möglich.
* Sehr hohe Ausdrucksstärke und Flexibilität – Beispiel: die anpassbare Freispeicherverwaltung, in die sich etwa nahtlos eine automatische Speicherbereinigung (englisch garbage collector) integrieren lässt.
* Für große Projekte geeignet.
* Weite Verbreitung.
* Die Sprache ist nicht im Besitz einer Organisation (im Unterschied zu beispielsweise Java). Standardisierung durch die ISO
* Weitreichende Möglichkeiten für die Metaprogrammierung
* Kompatibilität mit C – Vorteil: Es steht eine breite Codebasis zur Verfügung.
* Jede C++-Entwicklungsumgebung für Windows verfügt heute bereits über eine Bibliothek vorgefertigter C++-Klassen (Framework), mit dem sich der Programmieraufwand erheblich reduzieren lässt.

Schwächen

* Kompatibilität mit C – Nachteil: historischer Ballast muss mitgeschleppt werden, zum Beispiel der von C übernommene Präprozessor, oder die teilweise schwer verständliche C-Syntax. Die Kompatibilität zu C hat u. a. zur Folge, dass einige Details der Sprache Compiler-spezifisch sind, die es aber nicht sein müssten. So ist beispielsweise die Auswertungsreihenfolge von Teilausdrücken je nach Compiler und Plattform unterschiedlich. Dies erschwert die Portierung von C++-Programmen zwischen Rechnertypen, Betriebssystemen und unterschiedlichen Compilern.
* Die aktuellen Compiler (Stand: 2005) sind rückständig bezüglich der Umsetzung der ISO-Norm.
* Die aktuellen Compiler produzieren nicht immer optimalen Code, sowohl in Bezug auf Geschwindigkeit als auch auf Code-Größe.
* Zum Erlernen sind verhältnismäßig lange Einarbeitungszeiten erforderlich.
* Die aktuelle C++-Standardbibliothek deckt einige neue Erfordernisse noch nicht ausreichend ab, zum Beispiel Threads, TCP/IP, Dateisystem-Verzeichnisse. Deshalb besteht in diesen Bereichen, bei Verwendung herstellerspezifischer Bibliotheken, eine eingeschränkte Portabilität über Betriebssystemgrenzen hinweg (Entwicklung zahlreicher externer Bibliotheken).
* Aufgrund des breiten Leistungspektrums und der vielfältigen Gestaltungsmöglichkeiten ist die Verwendung von Programmierrichtlinien (aus Gründen der Wartbarkeit und Fehleridentifizierung) mehr als in anderen Sprachen anzuraten.

Verwandtschaft mit C

C++ ist eine Erweiterung der Programmiersprache C gemäß dem Stand von 1990 (ISO/IEC 9899:1990, auch kurz C90 genannt). C++ enthält C nach dem Stand C90 fast vollständig. Einige wenige C-Programme lassen sich nicht ohne weiteres als C++ kompilieren beziehungsweise haben als C++-Programme eine etwas andere Bedeutung. Dabei handelt es sich aber um Sonderfälle, die in der Praxis keine große Rolle spielen.

Die Kompatibilität mit C war eines der Hauptdesignziele bei der Entwicklung der Programmiersprache C++. Grund dafür war die große Verbreitung von C. C-Compiler sind auch heute noch für praktisch jeden Prozessor verfügbar. Deswegen gilt die Kompatibilität mit C immer noch als eine der wichtigsten Eigenschaften von C++.

Im Laufe der Entwicklung der beiden Sprachen gab es auch Rückwirkungen von C++ auf C. Beispielsweise wurden in C const sowie die Funktionsprototypen von C++ übernommen.

Die letzten Änderungen an C fanden 1999 statt (ISO/IEC 9899:1999). Gemäß dem Ratifizierungsjahr 1999 spricht man, wenn man sich auf diesen C-Stand bezieht, deshalb auch von C99. Ein Beispiel für darin eingeführte Spracherweiterungen sind die so genannten VLAs (engl. variable length array).

Aufgrund dieser Weiterentwicklung von C gibt es theoretisch mehr Inkompatibilitäten zwischen C und C++. Mittlerweile unterstützen viele Compiler diesen neuen Stand C99 in der Sprachdefinition und nicht ganz so viele auch in der Bibliothek, so dass die Bedeutung dieser Unterschiede zwischen C und C++ zunimmt. Bei der in Arbeit befindlichen C++-Version wird u. a. daran gearbeitet, die neuen C99-Merkmale mit einzuarbeiten. Einige C++-Compiler unterstützen C99-Neuerungen schon jetzt (z. B. der gcc).

Man kann historisch gesehen nicht einfach von C oder C++ reden, man sollte den genauen Stand, auf den man sich bezieht, nennen. Mal gibt es Inkompatibilitäten mal nicht, je nachdem wer wen befruchtet und welchen Compiler und welche Version man einsetzt.

Auf jeden Fall beruht C++ auf C. Dies war klares Designziel. Das sollte man im Nachhinein nicht "verbiegen".

Wie man hier im Forum sieht, gibt es auch nur einen Rahmen sowohl für C als auch für C++.

[Artchi]

Bjarne Stroustrup hatte damals vor 20 Jahren (bitte die 20 beachten!) erfunden. Und tatsächlich hatte er vor 20 Jahren C in sein C++ drin gehabt, aber nur um die C-Leute für C++ zu begeistern (alten Code auf C++ langsam migrieren). Das ist aber heute nicht mehr nötig, heute kann man sich gleich für C++ entscheiden, wenn man ein Projekt anfängt. Aber sowohl C als auch C++ waren vor 20 Jahren nicht das, was sie heute sind. C++ kannte damals nichmal Templates, Templates sind erst durch die ISO-Normierung entstanden. Genauso ist es mit C, es gibt Sachen, die gab es vor 20 Jahren nicht und die neuen müssen nicht im C++ drin sein. Also inkompatibel!

Brjarne Stroustrup schreibt zwar gerne was er damals vor 20 mal gemacht hat, aber es hat mit dem heutigen nichts mehr viel gemeinsam. Z.B. hat Bjarne absolut keinen Einfluss mehr auf C++, um es hart auszudrücken: er hat nichts mehr zu melden. Dem ist er sich auch bewusst, schliesslich hatte er und AT&T damals seine Rechte abgetreten. Bjarne wünscht sich auch eine GUI-Lib im C++ Standard. Und? Das ISO-C++ Komitee sagt nein!

C++ hat sowohl technisch und organisatorisch nicht mehr viel mit dem gemeinsam, was mal Bjarne vor 20 jahren auf die Beine gestellt hat. Heute bestimmen Firmen wie Microsoft, HP, Dinkumware und andere ISO-C++-Memebers was in C++ abgeht. Im Bereich C sieht es denke ich mal ähnlich aus (ich selbst verfolge C nicht weiter). Aber ich weiß das viele Automotive-Firmen in C ihren Einfluss haben weil diese technisch andere Interessen als die C++-Firmen verfolgen.

Kramt also nicht irgendwelche Infotexte raus, die vor 15 oder gar 20 Jahren jemand geschrieben hat und heute immer wieder gebracht werden und somit ein C++-Greenhorn fölschlicherweise als heute gültig ansieht.

[normal]

Erhard Henkes schrieb:

Aus Compiler-Fragen halte ich mich raus, das ändert sich ständig. Windows hat übrigens recht wenig mit C++ zu schaffen, es basiert im Wesentlichen auf C und WinAPI. Neuere C++-GUI-Frameworks versuchen es verstärkt sich im Sinne der OOP an C++ anzulehnen.

Lassen wir doch noch mal den Erfinder der ersten C++-Generation zu Wort kommen:

C++ is a general purpose programming language with a bias towards systems programming that

* is a better C
* supports data abstraction
* supports object-oriented programming
* supports generic programming.

http://www.research.att.com/~bs/C++.html (May 10, 2006)

Daher sollte man auch die Entwicklung von C erwähnenen, auf dessen Fundamente C++ immer noch stabil ruht.

http://cm.bell-labs.com/cm/cs/who/dmr/
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
http://cm.bell-labs.com/cm/cs/who/dmr/bigbio1st.html

Interessanter ist eigentlich die Frage nach der Weiterentwicklung von C++, um Schwächen zu entfernen und Stärken zu betonen.

http://de.wikipedia.org/wiki/C++

Stärken

* Die Erzeugung hocheffizienten Codes ist möglich.
* Sowohl maschinennahe als auch hochabstrakte Programmierung ist möglich.
* Sehr hohe Ausdrucksstärke und Flexibilität – Beispiel: die anpassbare Freispeicherverwaltung, in die sich etwa nahtlos eine automatische Speicherbereinigung (englisch garbage collector) integrieren lässt.
* Für große Projekte geeignet.
* Weite Verbreitung.
* Die Sprache ist nicht im Besitz einer Organisation (im Unterschied zu beispielsweise Java). Standardisierung durch die ISO
* Weitreichende Möglichkeiten für die Metaprogrammierung
* Kompatibilität mit C – Vorteil: Es steht eine breite Codebasis zur Verfügung.
* Jede C++-Entwicklungsumgebung für Windows verfügt heute bereits über eine Bibliothek vorgefertigter C++-Klassen (Framework), mit dem sich der Programmieraufwand erheblich reduzieren lässt.

Schwächen

* Kompatibilität mit C – Nachteil: historischer Ballast muss mitgeschleppt werden, zum Beispiel der von C übernommene Präprozessor, oder die teilweise schwer verständliche C-Syntax. Die Kompatibilität zu C hat u. a. zur Folge, dass einige Details der Sprache Compiler-spezifisch sind, die es aber nicht sein müssten. So ist beispielsweise die Auswertungsreihenfolge von Teilausdrücken je nach Compiler und Plattform unterschiedlich. Dies erschwert die Portierung von C++-Programmen zwischen Rechnertypen, Betriebssystemen und unterschiedlichen Compilern.
* Die aktuellen Compiler (Stand: 2005) sind rückständig bezüglich der Umsetzung der ISO-Norm.
* Die aktuellen Compiler produzieren nicht immer optimalen Code, sowohl in Bezug auf Geschwindigkeit als auch auf Code-Größe.
* Zum Erlernen sind verhältnismäßig lange Einarbeitungszeiten erforderlich.
* Die aktuelle C++-Standardbibliothek deckt einige neue Erfordernisse noch nicht ausreichend ab, zum Beispiel Threads, TCP/IP, Dateisystem-Verzeichnisse. Deshalb besteht in diesen Bereichen, bei Verwendung herstellerspezifischer Bibliotheken, eine eingeschränkte Portabilität über Betriebssystemgrenzen hinweg (Entwicklung zahlreicher externer Bibliotheken).
* Aufgrund des breiten Leistungspektrums und der vielfältigen Gestaltungsmöglichkeiten ist die Verwendung von Programmierrichtlinien (aus Gründen der Wartbarkeit und Fehleridentifizierung) mehr als in anderen Sprachen anzuraten.

Verwandtschaft mit C

C++ ist eine Erweiterung der Programmiersprache C gemäß dem Stand von 1990 (ISO/IEC 9899:1990, auch kurz C90 genannt). C++ enthält C nach dem Stand C90 fast vollständig. Einige wenige C-Programme lassen sich nicht ohne weiteres als C++ kompilieren beziehungsweise haben als C++-Programme eine etwas andere Bedeutung. Dabei handelt es sich aber um Sonderfälle, die in der Praxis keine große Rolle spielen.

Die Kompatibilität mit C war eines der Hauptdesignziele bei der Entwicklung der Programmiersprache C++. Grund dafür war die große Verbreitung von C. C-Compiler sind auch heute noch für praktisch jeden Prozessor verfügbar. Deswegen gilt die Kompatibilität mit C immer noch als eine der wichtigsten Eigenschaften von C++.

Im Laufe der Entwicklung der beiden Sprachen gab es auch Rückwirkungen von C++ auf C. Beispielsweise wurden in C const sowie die Funktionsprototypen von C++ übernommen.

Die letzten Änderungen an C fanden 1999 statt (ISO/IEC 9899:1999). Gemäß dem Ratifizierungsjahr 1999 spricht man, wenn man sich auf diesen C-Stand bezieht, deshalb auch von C99. Ein Beispiel für darin eingeführte Spracherweiterungen sind die so genannten VLAs (engl. variable length array).

Aufgrund dieser Weiterentwicklung von C gibt es theoretisch mehr Inkompatibilitäten zwischen C und C++. Mittlerweile unterstützen viele Compiler diesen neuen Stand C99 in der Sprachdefinition und nicht ganz so viele auch in der Bibliothek, so dass die Bedeutung dieser Unterschiede zwischen C und C++ zunimmt. Bei der in Arbeit befindlichen C++-Version wird u. a. daran gearbeitet, die neuen C99-Merkmale mit einzuarbeiten. Einige C++-Compiler unterstützen C99-Neuerungen schon jetzt (z. B. der gcc).

Dazu sag ich nur: Ein doppeltes !

[Tobias W]

Mal eine Zwischenfrage: welche(r) Compiler kommt eigentlich dem c++ Standard am nähesten?
Ich dachte die neueren Compiler würden dies zu 99% tun? Aber wahrscheinlich irre ich mich.
Und welche Compiler sind beim Umsetzen des Standards so richtig schlecht?

Fragen die die Welt bewegen

[normal]

Tobias W schrieb:

Mal eine Zwischenfrage: welche(r) Compiler kommt eigentlich dem c++ Standard am nähesten?
Ich dachte die neueren Compiler würden dies zu 99% tun? Aber wahrscheinlich irre ich mich.
Und welche Compiler sind beim Umsetzen des Standards so richtig schlecht?

Fragen die die Welt bewegen

Also AFAIK ist gcc/g++ der compiler, der am Standardtreusten ist.
Die compiler von MS sind weniger Standardgetreu.
Man beachte bestimmte Sprachelemente, die nur bim VSC++ vorhanden sind.
Über den Borland compielr kann ich nix sagen, da ich ihn nie genutzt habe.

(Jaja, ich erinner mich noch daran, als ich mich durch die MSDN gewühlt hab udn da iese bemerkungen standen ala Nur auf VSC++ verfügbar)

[Artchi]

Herrlich wenn Unregs hier ungeniert ihre Unwissen posten dürfen.

TobiasW! Im Prinzip setzen alle neueren C++ Compiler den Standard sehr gut um. Die 99% sind auch gut gedacht, da dies auch MS z.B. sagt. Denn du kannst davon ausgehen das hauptsächlich nur das Schlüsselwort export bisher nicht nutzbar ist. Das C++ Komitee hat sogar mal in Betracht gezogen, das export aus dem nächsten Standard zu rauszunehmen. Wurde aber wieder verworfen, da dann jemand anderes wieder kommen könnte, um was anderes streichen zu wollen.

Folgende Compiler sind so ziemlich 99% ISO-C++ Standardkonform:

MS VC++: ab Version 7.1 (2003), v8.0 (2005) ist hier endgültig top.
GCC: soweit ich informiert bin, seit der 4.0 Version? Wissen die GCC Fans bestimmt besser bescheid.
Intel C++ Compiler: definitiv ab Version 9. Ob schon 8er Version weiß ich nicht.

Ansonst machen leider z.B. Borlands Compiler, Suns Compiler u.a. viel Ärger. Sun ist deshalb selbst mittlerweile auf den GCC umgestiegen.

[icwiener]

normal schrieb:

Also AFAIK ist gcc/g++ der compiler, der am Standardtreusten ist.
Die compiler von MS sind weniger Standardgetreu.
Man beachte bestimmte Sprachelemente, die nur bim VSC++ vorhanden sind.
Über den Borland compielr kann ich nix sagen, da ich ihn nie genutzt habe.

(Jaja, ich erinner mich noch daran, als ich mich durch die MSDN gewühlt hab udn da iese bemerkungen standen ala Nur auf VSC++ verfügbar)

Der gcc kompiliert voreingestellt gnu++98, also mit den GNU-Erweiterungen.

MfG

[normal]

icwiener schrieb:

normal schrieb:

Also AFAIK ist gcc/g++ der compiler, der am Standardtreusten ist.
Die compiler von MS sind weniger Standardgetreu.
Man beachte bestimmte Sprachelemente, die nur bim VSC++ vorhanden sind.
Über den Borland compielr kann ich nix sagen, da ich ihn nie genutzt habe.

(Jaja, ich erinner mich noch daran, als ich mich durch die MSDN gewühlt hab udn da iese bemerkungen standen ala Nur auf VSC++ verfügbar)

Der gcc kompiliert voreingestellt gnu++98, also mit den GNU-Erweiterungen.

MfG

Hoppla.

Naja, einer muss hier ja im Thread Unwissen vertreiben!

That's me!

[Artchi]

Standardkonform heißt sicherlich nicht, das es keine Erweiterungen geben darf. Wichtig ist nur, das _mindestens_ der Standard unterstützt wird. Wenn MSVC noch Erweiterungen anbietet, kann sie jeder auf eigene Entscheidung benutzen.

[normal]

Artchi schrieb:

Standardkonform heißt sicherlich nicht, das es keine Erweiterungen geben darf. Wichtig ist nur, das _mindestens_ der Standard unterstützt wird. Wenn MSVC noch Erweiterungen anbietet, kann sie jeder auf eigene Entscheidung benutzen.

Dann ist der code aber im Endeffekt doch NICHT standardkonform^^

[Artchi]

Was hat der Code mit dem Compiler zu tun??? Wenn ich Code schreiben will, der zwischen Compilern portierbar ist, kann ich das trotzdem mit dem MSVC oder GCC machen. Dann benutze ich halt nicht spezielle COmpiler-Erweiterungen! Die (wie du auch festgestellt hast) sogar dokumentiert sind, das sie nicht portabel sind. Wer diese dann immer noch benutzt und portabilität erwartet, hat selber schuld.

Der Compiler kann nichts dafür wenn jemand absichtlich Erweiterungen benutzt.

Du stellst es aber so hin, das der Compiler schuld ist..

[normal]

Artchi schrieb:

Was hat der Code mit dem Compiler zu tun??? Wenn ich Code schreiben will, der zwischen Compilern portierbar ist, kann ich das trotzdem mit dem MSVC oder GCC machen. Dann benutze ich halt nicht spezielle COmpiler-Erweiterungen! Die (wie du auch festgestellt hast) sogar dokumentiert sind, das sie nicht portabel sind. Wer diese dann immer noch benutzt und portabilität erwartet, hat selber schuld.

Der Compiler kann nichts dafür wenn jemand absichtlich Erweiterungen benutzt.

Du stellst es aber so hin, das der Compiler schuld ist..

Der compiler ist nicht schuld.
Bloß wenn der compiler zu viel erlaubt (nicht standardkonformes), dann schreiben unwissende Personen nicht standard konformen code, wenn sie die dokus nicht lesen.

Darum gehts doch.

Im Endeffekt haste aber auch recht.

In dem Sinne noch: Happy coding.

[LordJaxom]

Spracherweiterungen kann man aber abschalten, schlampige Implementierung nicht. Insofern kann man sich bei ersterem drauf einstellen, zweiteres zu verhindern (wenn man nicht grad den Sprachstandard aus dem Effeff beherrscht) kann nur die neuere (konformere) Compilerversion sicherstellen

[loooooooool]

Java = C++ + Handicaps + Buzzwords = C++ - praktische Dinge + Marketinggeblubber.

[Erhard Henkes]

1983 prägte Rick Mascitti den Begriff C++. "++" ist bekanntlich der Inkrementoperator von C. Der Begriff D wurde abgelehnt, da C im wesentlichen eine Teilmenge von C++ werden sollte und dies in der Bezeichnung ausgedrückt werden sollte.
http://en.wikipedia.org/wiki/Rick_Mascitti

Das sind die Gründe, warum man den "Kontakt" zu C nicht abkoppelt:
# Es gibt Millionen von Codezeilen in C, die Nutzen aus C++ ziehen können, sofern ein vollständiges Umschreiben in C++ nicht notwendig ist.
# Es gibt hunderttausende von Programmzeilen in Bibliotheksfunktionen und Dienstprogrammen, die man von C++ aus verwenden kann, sofern C++ vollständig link-kompatibel zu C bleibt und syntaktisch sehr ähnlich zu C.
# Es gibt zehntausende von Programmierern, die C kennen, und daher nur die Erweiterungen von C++ gegenüber C neu lernen müssen.
# Da C und C++ über viele Jahre auf denselben Maschinen verwendet werden würden, sollten die Unterschiede entweder sehr groß oder sehr klein sein, um die Wahrscheinlichkeit von Fehlern und Verwechslungen gering zu halten.
http://www.gia.rwth-aachen.de/Lehre/Cpp/script/online/node5.html
Es geht hier also um handfeste wirtschaftliche Interessen, weniger um puristische Betrachtungen. Wer C++ aus diesem Grunde nicht sonderlich mag, kann als Alternative C# oder Java verwenden (Diskussionen über Vor- und Nachteile gibt es hier zuhauf).
http://www.haw-hamburg.de/rzbt/dankert/ccppjava.html/ (leider nicht mehr aktualisiert)

[Hobbyprogrammierer]

Hallo

Kann bitte mal einer von denjenigen Diskussionsteilnehmern, die die Meinung
vertreten, C++ sei eine eigenständige Sprache und keine Erweiterung von C,
mal was dazu sagen, ob man ein größeres C++ -Programm schreiben kann, und zwar
unter völligem Verzicht auf alle "C-Erblasten" ?

Kann man z.B. in C++ völlig auf Zeiger verzichten, wenn man will ?
Was ist mit den zahlreichen Bibliotheksfunktionen von C++, die char* als Argumente
haben wollen (und keine Objekte der Klasse String) ? Kann man die in C++ umgehen
und sich ganz auf string beschränken ?
Kann man in C++ in jedem Fall C-artige Arrays durch vector<...> o.ä. ersetzen?

Grüße

[normal]

Hobbyprogrammierer schrieb:

Hallo

Kann bitte mal einer von denjenigen Diskussionsteilnehmern, die die Meinung
vertreten, C++ sei eine eigenständige Sprache und keine Erweiterung von C,
mal was dazu sagen, ob man ein größeres C++ -Programm schreiben kann, und zwar
unter völligem Verzicht auf alle "C-Erblasten" ?

Kann man z.B. in C++ völlig auf Zeiger verzichten, wenn man will ?
Was ist mit den zahlreichen Bibliotheksfunktionen von C++, die char* als Argumente
haben wollen (und keine Objekte der Klasse String) ? Kann man die in C++ umgehen
und sich ganz auf string beschränken ?
Kann man in C++ in jedem Fall C-artige Arrays durch vector<...> o.ä. ersetzen?

Grüße

Soso. Wenn man ALLES aus C++ rausnimmt was in C bereits vorhanden war, dann muss man ALLES rausnehmen, was hier drinsteht:
http://www.galileocomputing.de/openbook/c_von_a_bis_z/

Im Endeffekt würde fast nix von der Sprach übrigbleiben.

Das ist so, als wenn du dir ein Spiel Kaufst. Danach kaufst du dir das AddOn un wirfst das Spiel weg. Dann haste im Endeffekt nur das AddOn welches ohen das eigentliche Spiel nicht lauffähig ist.

Verhält es sich bei C und C++.

Oder Schaffst du es ein komplexes programm zu schrieben OHNE zB die folgenden Sprachelemente zu benutzen:
if else switch while for do continue default case break ... etc

Dann wären da noch sämtliche Operatoren.

Achja, ohne C dürfte im C++ programm gar keine main fuktion sein!

Viel Spaß!

[Jester]

Also ist C++ ja nur eine Erweiterung von BASIC (*)! Da gab's Variablen und wenn man sich mal Variablen aus C++ rausnimmt, dann kann man mit dem Rest ja garnicht mehr viel machen.

(*) wer Freude dran hat bitte ne beliebige andere Programmiersprache einsetzen

[Gast]

Da es irgendwie in diesen Thread passt: Kann mir einer mal erklären, seit wann (in etwa) und v.a. warum sizeof('x') in C gleich sizeof(int), in C++ aber sizeof(char) ist?
Würde mich schon interessieren.