SUCHE

NAVIGATION Impressum Kategorien (alph.) Zufälliger Artikel
LINKTIPPS
Wikipedia GNU FDL Artikel anzeigen Artikel bearbeiten
 
C++

Toplinks zu diesem Thema:
Sprache, Arbeit, Englisch, Online, Sprachen, Vergleich, Java, Rahmen, Rolle, Schreiben


Der Artikel C++ gehört zur Kategorie: Programmiersprache C++

C++ ist eine der verbreitetsten und industriell bedeutendsten Programmiersprachen. Sie ist als Mehrzwecksprache konzipiert und unterstützt insbesondere effiziente und maschinennahe Programmierung, Datenabstraktion sowie objektorientierte und generische Programmierung.

C++ basiert auf der Programmiersprache C wie in ISO/IEC 9899:1990 beschrieben. Zusätzlich zu den in C vorhandenen Möglichkeiten bietet C++ weitere Datentypen, Klassen mit Vererbung und virtuellen Funktionen, Ausnahmebehandlung, Templates (Schablonen), Namensräume, Inline-Funktionen, Überladen von Operatoren und Funktionsnamen, Referenzen, Operatoren zur Freispeicherverwaltung und mit der C++-Standardbibliothek eine erweiterte Bibliothek.

Entstehungsgeschichte

C++ wurde von Bjarne Stroustrup ab 1979 bei AT&T entwickelt. Die Idee für eine neue Programmiersprache entwickelte er aus den Erfahrungen mit der Programmiersprache Simula im Rahmen seiner Promotion. Stroustrup erschien Simula zwar geeignet für den Einsatz in großen Software-Projekten, die Struktur der Sprache erschwerte aber die für viele praktische Anwendungen erforderliche Erzeugung hocheffizienter Programme. Effiziente Programme ließen sich zwar mit der Sprache BCPL schreiben, für große Projekte war BCPL aber wiederum ungeeignet.

Als Stroustrup in den Bell-Laboratorien zu arbeiten begann, sah er sich mit dem Problem konfrontiert, den UNIX-Betriebssystemkern im Hinblick auf verteilte Programmierung analysieren zu müssen. Mit den Erfahrungen aus seiner Promotion machte er sich daran, die Programmiersprache C um ein Klassenkonzept zu erweitern, für das die Sprache Simula-67 das primäre Vorbild war.

Die Wahl fiel auf die Programmiersprache C, weil C eine Mehrzwecksprache war, schnellen Code produzierte und einfach auf andere Plattformen zu portieren war. Als dem Betriebssystem UNIX beiliegende Sprache hatte C außerdem eine nicht unerhebliche Verbreitung. Zunächst fügte er der Sprache Klassen (mit Datenkapselung) hinzu, dann abgeleitete Klassen, ein strengeres Typsystem, Inline-Funktionen und Standard-Argumente.

Während Stroustrup „C mit Klassen“ („C with Classes“) entwickelte (woraus später C++ wurde), schrieb er auch cfront, einen Compiler, der aus C mit Klassen zunächst C-Code als Zwischenresultat erzeugte. Die erste kommerzielle Version von cfront erschien im Oktober 1985.

1982 wurde C mit Klassen in C++ umbenannt. Erweiterungen darin waren: virtuelle Funktionen, Überladen von Funktionsnamen und Operatoren, Referenzen, Konstanten, änderbare Freispeicherverwaltung und eine verbesserte Typüberprüfung. Die Möglichkeit von Kommentaren, die an das Zeilenende gebunden sind, wurde wieder aus BCPL übernommen (//).

1985 erschien die erste Version von C++, die eine wichtige Referenzversion darstellte, da die Sprache damals noch nicht standardisiert war. 1989 erschien die Version 2.0 von C++. Neu darin waren Mehrfachvererbung, abstrakte Klassen, statische Elementfunktionen, konstante Elementfunktionen und die Erweiterung des Schutzmodells um protected. 1990 erschien das Buch The Annotated C++ Reference Manual, das als Grundlage für den darauffolgenden Standardisierungsprozess diente.

Relativ spät wurden der Sprache Templates, Ausnahmen, Namensräume, neuartige Typumwandlungen und boolesche Typen hinzugefügt.

Im Zuge der Weiterentwicklung der Sprache C++ entstand auch eine gegenüber C erweiterte Standardbibliothek. Erste Ergänzung war die Stream-I/O-Bibliothek, die Ersatz für traditionelle C-Funktionen wie zum Beispiel printf und scanf bietet. Eine der wesentlichen Erweiterungen der Standardbibliothek kam später durch die Integration großer Teile der bei HP entwickelten Standard Template Library (STL) hinzu.

Nach jahrelanger Arbeit wurde schließlich 1998 von der ISO die endgültige Fassung der Sprache C++ (ISO/IEC 14882:1998) genormt.

2003 wurde die erste überarbeitete Version von ISO/IEC 14882:1998 verabschiedet (ISO/IEC 14882:2003). Diese Revision ist lediglich eine Nachbesserung der Norm ISO/IEC 14882:1998 und sollte nicht mit der in Arbeit befindlichen Version verwechselt werden. Die nächste Version der Sprache C++ erscheint voraussichtlich noch in dieser Dekade. (s. in der Entwicklung befindliche Version)

Merkmale

C++ unterstützt die folgenden Programmiertechniken:

C++ ist somit eine so genannte „Multiparadigmen-Sprache“, die dem Programmierer sehr viele Freiheiten lässt.

Siehe auch: Programmierparadigma, Entwurfsmuster, RAII, Metaprogrammierung

Vor- und Nachteile

Vorteile

  • 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 Firma (im Unterschied zu beispielsweise Java - Eigentum der Firma SUN oder Visual Basic - Eigentum der Firma Microsoft). Standardisierung durch die ISO
  • Weitreichende Möglichkeiten für die Metaprogrammierung
  • Kompatibilität mit C – Vorteil: Es steht eine breite Codebasis zur Verfügung.
  • Die aktuellen Frameworks für C++ sind recht weit entwickelt und einige wie zum Beispiel Qt sind plattformübergreifend.

Nachteile

  • Historischer Ballast muss aufgrund der Kompatibilität mit C 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.

Hallo-Welt-Programm in C++

Der folgende Quelltext stellt ein einfaches C++-Programm dar, das die Meldung „Hallo Welt!“ auf dem Standardausgabemedium ausgibt: 

 #include  


 int main() 
 {
   std::cout << "Hallo Welt!" << std::endl; 


 }

Erläuterungen

Bei main handelt es sich um eine Funktion, genauer gesagt ist es die Hauptfunktion des gesamten Programms. Die Funktion main ist in jedem C++-Programm vorhanden und wird nach dem Start des Programms aufgerufen.

Die C++-ISO-Norm schreibt vor, dass das Ergebnis von main vom Typ int sein muss. Ein Programm, bei dem das Ergebnis von main nicht vom Typ int ist, ist kein gültiges Programm im Sinne der C++-ISO-Norm (ISO-14882).

Die Funktion main ist die einzige Funktion, die – obwohl sie einen Wert zurückgibt – nicht die Anweisung „return“ benötigt. Ohne die explizite Anweisung return gibt main den Wert 0 zurück.

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

Vergleich mit anderen Sprachen

C++ war nicht der einzige Ansatz, die Programmiersprache C um Eigenschaften zu erweitern, die das objektorientierte Programmieren vereinfachen. In den 1980er Jahren entstand die Programmiersprache Objective-C, die sich aber im Gegensatz zu C++ an Smalltalk und nicht an Simula orientierte. Die Syntax von Objective-C unterscheidet sich unter anderem wegen der Smalltalk-Wurzeln stark von C++. Objective-C ist weniger weit verbreitet als C++. Bekannteste Einsatzgebiete von Objective-C sind in OpenStep und Mac OS X.

Die Programmiersprachen Java und C# haben eine ähnliche, ebenfalls an C angelehnte Syntax wie C++, sind auch objektorientiert und unterstützen Typparameter, weshalb ein Vergleich mit ihnen besonders naheliegend ist.

Siehe auch: Simula, Smalltalk, Vergleich objektorientierter Programmiersprachen

In der Entwicklung befindliche Version

Im Jahr 2003 erschien eine Ergänzung des Standard (ISO/IEC 14882:2003), deren Inhalt zum C++98 gehört. C++0x (manchmal auch C++200x) ist eine inoffizielle Abkürzung für die in der Entwicklung befindliche Version der Programmiersprache C++. Zwar scheint der Name anzudeuten, dass dieser Standard bis spätestens 2009 fertig gestellt wird, es handelt sich aber lediglich um eine grobe Einschätzung des möglichen Erscheinungstermins.

Der Name „C++“

Der Name ist eine Wortschöpfung von Rick Mascitti und wurde zum ersten Mal im Dezember 1983 benutzt. Während ihrer Entstehung wurde die Sprache zuerst „C with Classes“ genannt. Der endgültige Name kommt vom Inkrement-Operator „++“, der den Wert einer Integer-Variablen um eins erhöht.

Zersplitterung der Sprachbenutzung, Implementierung und Spezifizierung

Im Gegensatz zu vielen anderen neueren Programmiersprachen ist C++ nur eine Spezifikation (sogar ein ISO-Standard), ohne eine Referenz-Implementierung. Das hat den Vorteil, dass man bei der Benutzung von C++ nicht an einen Hersteller gebunden wird und eine große Anzahl an Implementierungen existiert. Ein enormer Nachteil ist aber die langsame Umsetzung der Spezifikationen in den Implementierungen. Zwar entwickelt sich C++ in langsamen Schritten weiter, seit 1997 erfolgten nur noch Fehlerkorrekturen, aber dennoch dauerte es lange bis der C++-Standard weitestgehend unterstützt wurde. Heutige Inkompatibilitäten beziehen sich in der Regel nur auf das Sprachmittel „export“.

Ein weiterer Grund für die Zersplitterung der Sprache ist die lange Benutzung. C++ wurde in der Phase, in der die Sprache die größte Entwicklung erlebte, bereits sehr intensiv eingesetzt. Dies sorgte dafür, dass viele Entwickler nicht oder nur unzureichend mit neueren Eigenschaften der Sprache vertraut sind oder diese auf Grund von alten Compilern nicht einsetzen konnten. Daher sind viele Projekte, die in C++ entwickelt wurden, nicht auf dem aktuellen Stand der C++ Programmierung und sogar inkompatibel zu den aktuellen C++-Normen.

Auch der Stand vieler Lehrbücher und Lehrveranstaltungen ist veraltet. Da sich einige Compiler, wie der GCC, der C++-Sprachdefinition immer mehr annähern, stimmen Lehrinhalte oft nicht mit der Realität existierender Compiler überein.

C++-Compiler

{Tausendfach verwendet}>

border="2" cellspacing="0" cellpadding="4" rules="all" class="hintergrundfarbe1 rahmenfarbe1" style="margin:1em 1em 1em 0; border-style:solid; border-width:1px; border-collapse:collapse; empty-cells:show; "

Dies ist die vorrangig zu verwendende Formatvorlage für generell alle Tabellen. Ein Verwendungsbeispiel findet sich auf der Diskussionsseite.

Für zusätzliche CSS-Parameter kann ein Vorlagenparameter angegeben werden, Beispiel: 

 
 ...

Für links- und rechtsseitig Ausgerichtete Tabellen siehe Vorlage:Prettytable-L und Vorlage:Prettytable-R.

Siehe auch: Hilfe:Tabellen, Abschnitt Tabellen in Wie gute Artikel aussehen.

Prettytable

en:Template:Prettytable

> Highlight1
Compiler Kommentar Mit spezieller IDE Plattform
g++ Bestandteil der GCC; setzt ab Version 3.4 die Sprache C++ nahezu vollständig um; Freie Software Nein Unix, Linux, Mac OS X, Windows (dort auch als MinGW), AmigaOS
Intel C++ Compiler Setzt C++ nahezu vollständig um; erzeugt hocheffizienten Code für Intel-Prozessoren; proprietär Nein Windows, Linux, MacOS X
Microsoft Visual C++ Verbreitetster Compiler unter Windows; setzt ab der Version 7.1 die Sprache C++ nahezu vollständig um; proprietär; kostenlose Version mit Einschränkungen Ja Windows
Borland C++ Builder proprietär (eine ältere Version ist kostenlos ohne IDE verfügbar) Ja Windows, Linux (Kylix)
Open Watcom Auch Unterstützung älterer Plattformen, bisher noch ohne vollständige C++-Standardbibliothek; Open Source Ja DOS, Windows, OS/2, Netware (Linux-Unterstützung in Arbeit)
Comeau's C++ Compiler Gilt als der Compiler, der C++ vollständig umsetzt; unterstützt zum Beispiel auch export von Templates; proprietär (kann über das Internet ausprobiert werden) Nein Windows, Linux, Solaris/SPARC

Für Kommandozeilen-Compiler, die keine spezielle integrierte Entwicklungsumgebung mitbringen, existiert eine große Zahl von unabhängigen Werkzeugen, die die Entwicklung sehr erleichtern. Eine Liste derer findet man im selbigen Artikel.

Siehe auch: Compiler, Visuelle Programmierumgebung

Siehe auch

Literatur

  • Bjarne Stroustrup: Die C++-Programmiersprache, Addison-Wesley, ISBN 3-8273-1660-X, das Standardwerk zu C++, Grundkenntnisse in C von Vorteil.
  • Andrew Koenig, Barbara E. Moo: Intensivkurs C++, Pearson Studium, ISBN 3-8273-7029-9, Anfängerbuch, ein gewisses Grundverständnis der Programmierung ist von Vorteil.
  • Scott Meyers: Effektiv C++ Programmieren – 55 Möglichkeiten, Ihre Programme und Entwürfe zu verbessern, Addison-Wesley, ISBN 3-8273-2297-9, zur Vertiefung bereits vorhandener C++-Kenntnisse.
  • Scott Meyers: Mehr Effektiv C++ programmieren – 35 neue Wege zur Verbesserung ihrer Programme und Entwürfe, Addison-Wesley, ISBN 3-8273-1275-2, Vertiefung vorhandener C++-Kenntnisse.
  • Herb Sutter: Exceptional C++, ISBN 3-8273-1711-8, Vertiefung vorhandener C++-Kenntnisse.
  • Andrei Alexandrescu: Modernes C++ Design – Generische Programmierung und Entwurfsmuster angewendet, ISBN 3-8266-1347-3, ein Standardwerk zur C++-Metaprogrammierung, setzt ein tiefes Verständnis von C++ voraus.
  • Bruce Eckel: Thinking in C++, Volume 1: Introduction to Standard C++, Prentice Hall, 2000, ISBN 0139798099, auch als kostenloses online-Buch verfügbar
  • Bruce Eckel: Thinking in C++, Vol. 2: Practical Programming, Prentice Hall, 2003, ISBN 0130353132, auch als kostenloses online-Buch verfügbar, sehr gute Beispiele als Quelltext

Weblinks

simple:C++ zh-yue:C++

Diskussion der Autoren über den Artikel: C++

Archiv1 | Archiv vom 21.10.2005 - 07.08.2006

weiteres Vorgehen

(Ich habe diese "Arbeitsliste" nochmals hervorgekrammt. Hier kann man ja schon mal Vorschläge sammeln.)

Was der Artikel braucht ...

  • eine Generalüberholung
  • Quellenangaben für alle wertenden Behauptungen --> siehe erster Satz . --Revvar (Revvar Revvar/RT) 08:17, 16. Aug 2006 (CEST)

Was der Artikel nicht braucht ...

  • eine Änderung am Hallo-Welt-Programm
  • weitere Buchempfehlungen

--Poldi 19:40, 14. Aug 2006 (CEST)

Merkmale der Sprache

(kopiert von der Qualitätssicherungsseite:)

Vorschlag

Ich mach mal einen Vorschlag, wie der inkriminierte Teil aussehen könnte:
Merkmale
Ausgangspunkt
C++ wurde mit C als Grundlage entwickelt, um die folgenden Eigenschaften von C auch in C++ zu erhalten:
  • C ist vielseitig, prägnant und maschinennah
  • C ist geeignet für fast alle Programmierprobleme
  • C existiert auf allen Platformen
  • C ist geeignet für Unix-Programmierung
(zitiert nach Stroustrup, C++ Programming Language, 3. edition)
Ziele
C++ folgt den nachstehenden Paradigmen der Programmierung:

Siehe auch: Programmierparadigma, Entwurfsmuster, RAII, Metaprogrammierung

Eigenschaften
Viele der Eigenschaften von C++ erklären sich mit dem Ausgangspunkt und den erklärten Zielen.
  • C++ gestattet maschinennahe und abstrakte Programmierung.
  • C++ wird für große Programmierprojekte empfohlen (Design Patterns demonstriert die Beispiele in C++)
  • C++ kann auf fast allen Platformen kompiliert werden und ist somit fast überall verfügbar.
  • C++ wurde bei AT&T entwickelt, ist aber trotzdem kein proprietäres Produkt.
  • Für C++ existiert eine Norm (ISO/IEC 9899:1990 ), die weiterentwickelt wird.
  • C++-Compiler können C übersetzen und anbinden. C-Code kann weiterverwendet werden.
  • Auch für C++ existieren gute freeware und kommerzielle Libraries zu verschiedenen Problemen.
  • Wegen der geforderten Kompatibilität zu C enthält C++ historischen Ballast, der in neuentwickelten Sprachen heute nicht mehr existiert (Präprozessor, Zeiger). Stroustrup empfiehlt ausdrücklich diese Sprachteile nur sehr vorsichtig zu verwenden.
  • Die aktuellen Compiler (Stand: 2006) implementieren oft nicht den kompletten Standard. Vor allem in der Library existieren oft Lücken. (Beispiel: Gnu-C++ [[LINK]] dort unter TODO)
  • C++ kennt keinen garbage collector, keine Threads, keine GUI-Programmierung und keine Netzprogrammierung. Für diese Probleme müssen externe Libraries benutzt werden.
Kontroversen
Manche Eigenheiten von C++ werden sehr kontrovers diskutiert. Siehe [[LINK]], [[LINK]] und [[LINK]]
  • Der historische Ballast zwingt zu veralteten Programmiertechniken (Headerfiles, Zeiger, Makros)
  • So wird die Komplexität der Sprache als zu hoch bewertet. Insbesondere die Operatorfunktionen sind eine Ursache vieler Probleme ind großen C++-Programen
  • Viele C++-Compiler benötigen deutlich mehr Übersetzungszeit als bei vergleichbaren C-Programmen und erzeugen deutlich größere ausführbare Programme. (Benchmarklinks unter [[LINK]], Benchmarkergebnisse für GCC u.a. bei [[LINK]], siehe summarized results)
  • Für effiziente Compiler reichen die Standardtechniken des Compilerbaus nicht mehr aus.
  • C++ ist schwerer zu erlernen und benötigt viel Prgrammiererfahrung, um gute Programme zu produzieren.
Vorschlag Ende
--Brf 17:04, 8. Aug 2006 (CEST)
(Anm.: Habe zum Zwecke der besseren Darstellung auf dieser Seite die Überschriftenebenen geändert) --Dtk 21:53, 8. Aug 2006 (CEST)
@Brf, ich finde deinen Vorschlag gut. Ich bin beeindruckt. Vor allem gefällt mir die strukturelle Verbesserung, die du damit einbringst. Ein paar Anmerkungen:
  • Auch die Effizienz der resultierenden Programme (hocheffizienter Code, s.o.) ist ein erklärtes Designziel von C++.
  • ISO/IEC 9899:1990 beschreibt nicht C++, sondern C (wohl ein Versehen; C++ wird unter ISO/IEC 14882:1998 geführt).
  • Ausdrucksstärke (s.o.) ist an das englische Wort expressiveness angelehnt. Dazu findet Google in Kombination mit "C++" 156.000 Stellen.
  • Weitreichende Möglichkeiten für die Metaprogrammierung. Für sich genommen ist das schwer zu verstehen, dennoch ein wichtiger Aspekt. Die Metaprogrammierung schlägt die Brücke zwischen hoher Abstraktion und Maschinnennähe (bzw. Effizienz).
  • Die aktuellen Compiler (Stand: 2005) sind rückständig bezüglich der Umsetzung der ISO-Norm. Etwas ungeschickt und auch überzogen formuliert, dennoch ist was dran. Ich halte es für erwähnenswert. (Auf der C++-Diskussionsseite hat es eine längere Diskussion zu diesem Thema gegeben, siehe Archiv). Dass die aktuellen Compiler nicht immer optimalen Code produzieren, sowohl in Bezug auf Geschwindigkeit als auch auf Code-Größe, liegt in einigen Fällen auch daran, dass die Hersteller immer noch mit der Erfüllung der ISO-Norm beschäftigt sind, anstatt sich schon auf die Optimierungen ihrer Produkte konzentrieren zu können.

--Poldi 23:10, 8. Aug 2006 (CEST)

Belege

Ich habe einen Vormittag lang im Web nach Belegen gesucht. Das ist wegen der Kommerzialisierung mittlerweile sehr viel schwieriger als vor ein paar Jahren. Die ersten Links und viel zu viele sind kommerzielle Seiten oder Werbung für etwas (auch neue Sprachen)

Nicht fündig geworden bin ich über die Verbreitung von C++.

Nach Überfliegen und Ausmisten sind die folgenden Seiten (noch unsortiert) übriggeblieben:

Die Linksammlung soll hier zunächst einmal zum Stöbern dienen.

Kommentare dazu

dokumentiert eine Studie, bei der 1 Problem von vielen Programmierern in 80 Programmen und 7 Sprachen (C, C++, Java, Perl, Python, Rexx, and Tcl) gelöst wurde. Verglichen wurden Laufzeiten, Speicherbedarf, Entwicklungszeiten, Programmlänge.

Die Studie hat ihre Schwächen. Aber sie dokumentiert viele Aussagen über C++ im Artikel, die bisher unbelegt waren. C++ und Java weisen deutlich höhere Laufzeiten aus als C, sowohl im Median als auch beim confidence interval. C++ ist gleich wie C in der Initialisierung, wo nur Daten gelesen werden. (Hier wird nur die Library benutzt) Beim eigentlichen Programm ist C++ langsamer als C. Die Probleme der Sprache zeigen sich im riesigen Qualitätsunterschied bei mehreren Programmierern. Sie zeigen sich auch in der Arbeitszeit.

Gerade die riesigen conficence intervals zeigen die probleme, die Programmierer mit C++ haben.

Auch nicht unerwartet: Bei der Verläßlichkeit (reliability) geht eher C in die Knie.

Tabellarische Sprachvergleiche sind in

Ein sehr ausführlicher und (wie ich meine fairer) Sprachvergleich findet sich in

Vor allem in der Library existieren oft Lücken. (Beispiel: Gnu-C++ 1 dort unter TODO)
Das stimmt nicht und wird auch nicht durch die Quelle belegt. Bei der ToDo-Liste geht es ja nicht um Standard-Kompatibilitätsprobleme. Es geht ja eher um Probleme mit Sprachfeatures, wobei sich das ja mittlerweile zum größten Teil auf export bezieht.
Der historische Ballast zwingt zu veralteten Programmiertechniken (Headerfiles, Zeiger, Makros)
Das kann man ja so nicht sagen. Zeiger und Makros sind ja nicht zwingend.
Insbesondere die Operatorfunktionen sind eine Ursache vieler Probleme ind großen C++-Programen
Bitte Beweise für die Aussage vorlegen. Das halte ich für Blödsinn
Für effiziente Compiler reichen die Standardtechniken des Compilerbaus nicht mehr aus.
Das trifft doch im Grunde auf alle modernen Sprachen zu.
--Kingruedi 15:56, 9. Aug 2006 (CEST)

Ein Link als Beleg, dass die konventionellen Compilertechniken für C++ nicht mehr ausreichen ist

http://gcc.gnu.org/onlinedo...

Der obige TODO-Link bei Gnu enthält wirklich nicht viel. Besser ist

http://gcc.gnu.org/onlinedo...

Dieser Link wurde aber seit 2003 nicht mehr aktualisiert. Siehe ev. auch

http://gcc.gnu.org/bugs.htm...

--Brf 10:28, 10. Aug 2006 (CEST)

Der erste Link ist kein Beleg für folgenden Satz: Für effiziente Compiler reichen die Standardtechniken des Compilerbaus nicht mehr aus. In dem Artikel geht es eben darum, dass der normale UNIX-Linker zu dumm für Templates ist. Aber der UNIX-Linker ist nicht die ultimative Standard-Technik, sondern ein Relikt aus den 70ern. Keine moderne Programmiersprache greift noch auf derartige Konzepte zurück.
Die anderen beiden Links sagen ja auch nichts anderes, als das was fehlt in export, sonst ist alles mehr oder weniger in Ordnung. --Kingruedi 11:53, 10. Aug 2006 (CEST)

Nur mal so in den Raum gestellt: Braucht der Artikel überhaupt einen derartigen Absatz? Andere Programmiersprachen-Artikel kommen ja auch wunderbar ohne so eine Liste aus. Außerdem glaube ich kaum, dass man so etwas neutral formulieren kann. Was der eine als Vorteil sieht, ist für den anderen ein Nachteil. Man sollte so etwas lieber versuchen in ganzen Sätzen zu formulieren, so dass man auch die Folgen und den Zusammenhang der einzelnen Punkte beschreiben kann. --Kingruedi 22:54, 13. Aug 2006 (CEST)
Es gab dazu bereits eine ausführliche Diskussion auf der Qualtitässicherungs-Seite, siehe Link oben. Das von dir beschriebenen Problem lässt sich einfach dadurch lösen, das konsequent nur noch mit Quellen gearbeitet wird, und keine unbegelegten Einschätzungen mehr in den Artikel fließen. Gibt es in der Wissenschaft unterschiedliche publizierte Ansichten zu einem Punkt, so passt es unter "Kontroversen" ganz gut, denke ich. --Revvar (Revvar Revvar/RT) 09:39, 14. Aug 2006 (CEST)
Das man Quellen benutzt ändert ja nichts daran, dass eine Listenform vollkommen unausgereift ist um dieses Thema zu behandeln. Außerdem sind Quellen entweder auch unbelegbare Einschätzungen oder die Quellen werden zu stark interpretiert. Der aktuelle Vorschlag ist doch ein ideales Beispiel. So wird in einer Quelle gesagt, dass man Templates auch auf Linker-Ebene berücksichtigen muss und schon heißt es, dass aktuelle Compilertechniken nicht mehr für C++ ausreichen würden. Ich finde das Vorgehen sehr sehr fragwürdig und kaum hilfreich. Warum löschen wir die Liste nicht einfach raus und wenn jemand es für nötig hält, die Stärken und Schwächen von C++ aufzuführen, soll er einen zusammenhängenden Text schreiben (wobei dieser natürlich auch mit Quellen belegt sein sollte). --Kingruedi 14:47, 14. Aug 2006 (CEST)
Ich sehe das auch so. Lieber ein Loch als so eine halbwahre Sammlung. RichardigelRichardigel/Bewertung 15:06, 14. Aug 2006 (CEST)
Wenn es nach mir geht, wäre der Abschnitt seit langem raus. Dannach können wir die Punkte die klar belegt - natürlich nicht interpretiert - sind, einzeln wieder reinnehmen. Nur würde dies an der Diskussion hier nichts ändern. Wie ich Brf verstanden habe, ist die Liste oben nur ein Arbeitsvorschlag, bei dem er selbst zugibt das er für eine Reihe der Punkte noch keine Quellen hat. Auf der QS war ich ziemlich alleine für Löschen und dann Belegen, wenn sich hier eine Mehrheit findet - gerne. --Revvar (Revvar Revvar/RT) 18:45, 14. Aug 2006 (CEST)

Ich betrachte die verwendete Listenform als den Hauptmakel. Das gilt übrigens ebenso für die "Infobox" am Anfang des Artikels. Einen Grund, den Abschnitt zu löschen, sehe ich hingegen nicht. Das Hauptproblem des Artikels sind aber nicht die Sachen, die da stehen, sondern die, die noch nicht da stehen. --Poldi 19:40, 14. Aug 2006 (CEST)

Warum sollten wir dann eine neue Liste reinsetzen, wenn alle dies als schlecht ansehen? --Kingruedi 20:03, 14. Aug 2006 (CEST)
Ich weiß nicht, wie du darauf kommst, dass wir eine neue Liste da reinsetzen sollen. Natürlich nicht. Vielmehr die jetzige Listenform in Fließtext umwandeln. --Poldi 20:17, 14. Aug 2006 (CEST)
Nur wer setzt sich da dran? Sollten wir die aktuelle Liste nicht rausnehmen, auch wenn noch kein Ersatz vorhanden ist? (Genauso wie die Infobox) --Kingruedi 17:50, 15. Aug 2006 (CEST)
Wer hat denn bisher immer daran gearbeitet? :-) Ich glaube, außer von dir oder mir geht hier keine substanzielle Mitarbeit aus. ... Ich schau mal in den nächsten Tagen, was man daraus machen kann. Gebe dir noch bescheid. Schwere sachliche Fehler sind nicht drin, deswegen besteht kein akuter Handlungsbedarf. Bis bald. --Poldi 21:16, 15. Aug 2006 (CEST)
Was auch immer ihr vorhabt, Liste oder Fließtext - das ist das letzte Problem was es so lösen gilt. Es geht erstmal um Quellenbelege für all die aufgestellten Behauptungen - auch wenn ihr sie für trivial haltet. Das hat Brf als Einziger bisher in Angriff genommen, während alle anderen nur diskutiert haben. Leider ist er momentan aber im Urlaub. Also wenn ihr Zeit habt und was machen wollt, dann versucht die Punkte oben zu belegen, korrigieren oder als unbelegt zu markieren. --Revvar (Revvar Revvar/RT) 08:06, 16. Aug 2006 (CEST)

Überarbeitung

Bevor ich mich an die Arbeit mache, möchte ich von euch erfahren, ob ihr irgendwelche konkreten inhaltlichen Bedenken bezüglich des Abschnitts, so wie er vorliegt, habt. Ggf. kann ich das dann bei der Überarbeitung berücksichtigen. --Poldi 13:32, 20. Aug 2006 (CEST)

Weblinks

Ich habe viele Links rausgeworfen. Hier meine Begründung gemäß Wikipedia:Weblinks:

--Revvar (Revvar Revvar/RT) 10:00, 15. Aug 2006 (CEST)

Habe reparierten FAQ-Link wieder eingefügt. Die Diskussionsgruppe ist auch ok, da gute Qualität. (Die Wikipedia-Regeln sind nur generelle Vorgaben.) --Poldi 21:23, 15. Aug 2006 (CEST)

Einrichtung einer Meta-Seite

Wir brauchen einen Platz, um redaktionelle Informationen zu diesem Artikel zu kumulieren, die aber, auf Grund des redaktionellen Charakters dieser Informationen, nicht in den Artikel gehören. Dort sollen beispielsweise Quellen und andere Materialien gesammelt werden. Dazu habe ich hier eine Seite eingerichtet. --Poldi 13:32, 20. Aug 2006 (CEST)

Hello World

Da das HelloWorld-Programm scheinbar schon viel Aufsehen erregt hat, fasse ich mich kurz:

Ich lese auf vielen Seiten, dass es "int main(int argc, char * argv[])" heißen muss. Und außerdem entspricht es der Intuition, dass ich auch einen Wert zurückgeben muss, wenn ich es in der Deklaration der Funktion "versprochen" habe. Was für einen Zweck hat dieses nur mit warnings compilierbare HelloWorld eigentlich außer, entschuldigung, "rumklugzuscheißen"?

gcc 4.1.0 gibt auch mit -W -Wall keine Warnungen aus.--Gunther 18:46, 4. Sep 2006 (CEST)
Und was ist mit dem undefinierten Verhalten des Programmes? Oder macht der Compiler dann "nix" und nimmt dann als Rückgabewert den zufällig zuletzt in eax geschobenen Wert? Warum wurde nicht einfach ein stinknormales HelloWorld-Programm genommen, so wie man es in Büchern findet?
Ob du es gutfindest oder nicht, dass man bei main() die return-Anweisung weglassen kann, ist nicht Gegenstand dieses Artikels. Der Standard erlaubt es, aus welchen Gründen auch immer. Und wenn dein Compiler eine fehlende return-Anweisung anprangert, ist er kaputt und du solltest einen anderen Compiler nehmen. --RokerHRO 19:24, 4. Sep 2006 (CEST)
Was du denkst, ist nicht Sinn dieser Diskussionsseite. Wo steht das denn mit dem Standard? Ich finde im Internet nur vage Definitionen vonwegen "eigentlich gehört das so, aber es hat sich soundso eingebürgert". Und selbst wenn, ist es didaktisch äußerst fragwürdig (s.o. "Und was ist mit dem undefinierten Verhalten des Programmes?")
Nix undefiniert. Wenn da nichts steht, macht der Compiler automatisch das Äquivalent von "return 0", siehe z.B. hier.--Gunther 19:37, 4. Sep 2006 (CEST)

Lieber Anonymous: Es steht so im ISO-C++-Standard. ISO/IEC 14882, in Kapitel 3.6.1, Absatz 5. Den Standard kannst du in einer gut sortierten (Uni-)Bibliothek einsehen, oder für gutes Geld bei der ISO beziehen. --RokerHRO 22:50, 4. Sep 2006 (CEST)

Das Programm ist nach dem Standard schlicht und ergreifend korrekt. Da gibt es nichts zu diskutieren. Man kann sich zwar fragen, warum kein using namespace std verwendet wurde, so wie es üblich ist oder warum hier speziell mit endl gearbeitet wurde und nicht mit "\n", wo doch am Ende des Programms der Ausgabepuffer sowieso geleert wird. Aber all das sind Geschmacksfragen, die nicht die Korrektheit des Programms in Frage stellen.

Vorteile/Nachteile

Ich habe den Abschnitt mal entfernt. Ich denke, das eine Liste für diesen Zweck nicht geeignet ist. Man sollte eher auf Vorteile und Nachteile in einem Text eingehen. Das hatten wir ja bereits diskutiert und da waren auch alle einer Meinung. Aber seit dem hat sich nichts mehr getan. Also kommt der Abschnitt in der Form raus oder irgend jemand hat Zeit und Lust ihn umzuschreiben. --Kingruedi 15:41, 22. Okt. 2006 (CEST)

Einerseits ist die Listenform nicht ideal, da aber inhaltlich bislang keine Bedenken geäußert wurden, halte ich ein Entfernen für übertrieben. Bei der inhaltlich ohnehin schwachen Beteiligung an diesem Artikel wäre das eher kontraproduktiv. Eine Überarbeitung war ja auch für Ende des Jahres angekündigt. Ich schlage vor, so lange warten wir noch.
Inhaltlich sollte bei den Nachteilen und dort bei den C-Altlasten der Präprozessor rausgenommen werden. Es gibt zwar in manchen Bereichen einige Möglichkeiten, auf den Präprozessor zu verzichten, aber bei #include wird es schon eng. Insofern keine Altlast, sondern notwendig. Auch die Auswertungsreihenfolge von Teilausdrücken ist keine Altlast, hätte ja in C++ festgelegt werden können. --Nid
Gerade für #include gäbe es hervorragenden Ersatz. Ich rechne damit, dass eine der nächsten Revisionen von C++ über einen Ersatz für #include verfügen wird. Wenn du die Auswertungsreihenfolge änderst, änderst du leider u.U. auch die Bedeutung bestehender Programme. --Poldi 16:38, 1. Nov. 2006 (CET)
Da es bisher keine Verarbeitungsreihenfolge gibt, konnte sie auch niemand in einem Programm ausnutzen, sprich: Man musste darauf achten, dass die Reihenfolge keine Rolle spielt. Diese Programme laufen dann auch bei einem Compiler mit festgelegter Reihenfolge. Insofern wäre da keine Abwärtskompatibilität verloren gegangen, wenn C++ da "verbessert" worden wäre. Zu include: Natürlich gäbe es andere Möglichkeiten, die vielleicht auch irgendwann in die Sprache einfließen, aber bisher ist #include die einzige Möglichkeit und daher keine Altlast. Es gäbe ja auch für syntaktisch explizite Zeiger andere Möglichkeiten, die in die Sprache eingebaut werden könnten (siehe Java), demnach wären die auch eine Altlast von C. --Nid
Doch, es gibt eine Verarbeitungsreihenfolge. Sie ist nur eben abhängig vom Compiler, und die Compilerhersteller haben angedroht, sie wollen nicht mitziehen, wenn das Standardisierungskomitee an ihnen vorbei beschließen sollte, die Verarbeitungsreihenfolge vorzuschreiben. Dabei berufen sie sich darauf, dass ihnen bei der Entstehung von Inkompatibilitäten (und die entstehen tatsächlich, wenn man die Verarbeitungsreihenfolge ändert) die Kunden abspringen würden.
Zu include: Selbst wenn man heute einen Ersatz einführen würde, hätte man noch über jahrzehnte mit Quelltexten zu tun, die #include verwenden. Dass es diesen Ersatz noch nicht gibt, macht es nicht besser. Und #include ist ja nur ein Teil des Präprozessors. --Poldi 19:22, 18. Nov. 2006 (CET)

Übrigens wurde unter anderem dieser Abschnitt des Artikels beinahe unverändert in das Buch "C++ von A bis Z" von Jürgen Wolf übernommen (Kapitel "Grundlagen in C++"). Eine Quellenangabe konnte ich dort bislang nicht finden. Wie auch immer dieser Fall urheberrechtlich zu sehen ist, interessant ist, dass für das Buch ein so genannter "Fachgutachter" zu Rate gezogen wurde, wodurch ironischerweise unser Text bezogen auf seine Verlässlichkeit einen Rückhalt bekommt. --Poldi 17:22, 22. Okt. 2006 (CEST)

Bei dem Buch scheint es sich dann ja eher um eine Urheberrechtsverletzung zu handeln. Ich kenne das Buch nicht. Aber kontaktiere doch mal den Autor, das er sein Werk auch unter die GFDL stellen muss, wenn er von hier kopiert. In etwa wie http://www.gpl-violations.o...
Aber eine zirkuläre Quelle bringt natürlich nichts. Sonst kann ich in die Wikipedia ja auch jeden Blödsinn schreiben, warten bis einer der zahlreichen Wikipedia-Kopierer den Artikel auch in der Form Online hat und das als Quelle angeben. Aber gut, warten wir mal bis zum Ende des Jahres. --Kingruedi 18:27, 22. Okt. 2006 (CEST)

Ja, mit den zirkulären Quellen müssen wir aufpassen. Einzig die erwähnte Prüfung durch den "Fachgutachter" bringt uns hier weiter. Und damit ist dieser Artikel der erste geprüfte Artikel der Wikipedia, und das wurde erst durch eine (mutmaßliche!) Urheberrechtsverletzung an unserem Material ermöglicht. ;-)
Es ist übrigens nicht das erste Mal, dass andere Werke sich aus diesem Artikel bedienen. Vor etwa ein oder zwei Monaten standen Teile daraus in einer sehr renommierten deutschen Fachzeitschrift, ebenfalls ohne Quellenangabe. Immerhin scheint sich mittlerweile herumgesprochen zu haben, wo im Internet man sich mit brauchbaren Informationen eindecken kann. --Poldi 19:44, 22. Okt. 2006 (CEST)
Wenn niemand was dagegen hat, würde ich folgende Punkte entfernen:
  • 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.
Grund: Das hat eigentlich nichts mit der Programmiersprache zu tun, sondern mit ihrer derzeitigen Umsetzung in der Praxis --GiordanoBruno 18:49, 13. Nov. 2006 (CET)

Die Umsetzung der Sprache stellt den Bezug zur Nutzung und der eigentlichen sprachlichen Realität her. Was nutzt die ISO-Norm, wenn sich keiner dran hält? Dieser kleine Abschnitt erwähnt wenigstens, dass es eben nicht ganz so einfach in der Umsetzung ist. Deshalb würde ich diesen Abschnitt vorerst beibehalten.
--freak 1.5 11:41, 15. Nov. 2006 (CET)
Ich stimme dir zwar nicht zu, lasse den Artikel so wie er ist. --GiordanoBruno 13:13, 15. Nov. 2006 (CET)

Edit-War: Deutsches Wikibook zu C++

Wie wärs, wenn man schon erwähnt, dass es ein dt. Wikibook zu C++ gibt, aber es halt noch "in Arbeit" oder "verbesserungswürdig" ist. Das dürfte beide Seiten zufrieden stellen: Zum einen wird klar, dass das dt. Wikibook noch einiges aufzuholen hat zum englischen. Zum anderen wird aber auch gezeigt, dass es ein deutsches gibt, wo sich evtl. Mitmachen lohnt. Was haltet ihr davon? --RokerHRO 22:52, 29. Nov. 2006 (CET)

Ich wäre dafür, aber es gab bereits eine Diskussion dazu, mit entsprechenden Kontrastimmen: [LINK]. --Revvar (Revvar Revvar/RT) 09:51, 30. Nov. 2006 (CET)

Diese Definition bzw. Erklärung des Begriff C++ und dessen Bedeutung wurde zuletzt am 24.7.2007 aktualisiert (Glossar Lexikon Enzyklopädie).