Diskussion:C++/Archiv/1

message: Mir erscheint die Darstellung der Vor- und Nachteile von C++ ein bisschen einseitig, man spürt die Handschrift eines Autors (oder einer Autorin?) die C++ nicht so sehr mag oder vielleicht auch nicht ganz verstanden hat. (But as always: "your mileage may vary")
----
Die Unterteilung in Stärken und Schwächen gefällt mir nicht. Hier sollte eher eine Auflistung der Sprachmerkmale erfolgen.
Dass die aktuellen Compiler nicht optimalen Code erzeugen oder nicht ISO konform sind ist doch keine Schwäche der Sprache. Sollte rausgenommen werden.
: Naja, es ist keine Eigenschaft der Sprache, aber das Fehlen von guten Compilern schränkt die praktische Verwendbarkeit einer Sprache doch schon ein, oder? --RokerHRO 21:20, 16. Nov 2004 (CET)
thread_title:  Stärken und Schwächen 

message: Wenn ich "C++" oder "Programmiersprache C++" ins Suchfeld eingebe gelange ich nicht zu diesem Artikel. Kann man das ändern? -- 84.57.39.129 01:30, 9. Okt 2004 (CEST)
replies: text: Leider nein - der Artikelname ist unser Sorgenkind, weil die Software ein "+" im Artikelnamen nicht erlaubt. -Uli 01:31, 9. Okt 2004 (CEST)
thread_title:  Unauffindbar unter "C++" 

message: Hi, meiner persönlichen Meinung nach, sollte man den gcc.gnu.org link verwenden, der directory.fsf.org link ist extrem veraltet und wird offensichtl. nicht gepflegt! --Helm 17:29, 7. Feb 2005 (CET)
replies: text: Vorallem handelt es sich dabei nur um ein Eintrag in einem Directory und nicht um den offiziellen Link. GCC ist eben nicht mehr nur ein C Compiler sondern enthält verschiedene Front- und Backends. Selbst wenn man nur C++ meint, ist der Link auf gcc.gnu.org richtig. Etwas anderes deutet nur auf ein Missverständnis der GCC hin. (GCC == GNU Compiler Collection). Im Zweifelsfall bitte C++-Code mittels gcc -lstdc++ foo.cpp kompilieren. Es gibt halt keinen direkten Link für das C++ Frontend in der GCC.--Kingruedi 21:17, 7. Feb 2005 (CET)
replies: text: Wenn directory.fsf.org veraltet ist und nicht mehr gepflegt wird, dann bitte gcc.gnu.org! Lostintranslation 18:56, 8. Feb 2005 (CET)
thread_title:  [http://directory.fsf.org/gpp.html g++ (directory.fsf.org)] vs. [http://gcc.gnu.org g++ (gcc.gnu.org)] 

message: Welche geplanten Spracherweiterungen wären wohl Erwähnenswert? Poldi 19:25, 6. Mär 2005 (CET)
thread_title:  Geplante Erweiterungen der Programmiersprache C++ 

message: *Florian Wollenschein: C++ Programmierung für Anfänger, BoD, ISBN 3-8334-2216-5, für Anfänger sehr gut geeignet, aber nichts für Profis
Dieser Literaturhinweis kam gerade von Benutzer:195.93.60.105. Revert, da ich die Begründung auf der Diskussionsseite vermisse. An den anonymen Poster: Bitte schreib eine kurze Begründung, wieso dieses Buch in die Liste aufgenommen werden sollte. --Christoph 20:11, 26. Apr 2005 (CEST)
thread_title: Literatur (Wollenschein)

message: Was der kürzliche Vandalismus zeigt: Fehlende Bibliotheken sind keine Schwächen der Programmiersprache. Nur weil SUN das für Java einen Brei gekocht hat heißt das noch lange nicht, das Bibliotheken zur Programiersprache gehören (müssen). Schließlich gehört eine IDE ja auch nicht zur Programmiersprache, auch wenn sie hilfreich ist. Evtl. wäre es sinnvoll die fehlenden Bibliotheken an anderer Stelle zu erwähnen bzw. zu sagen, daß diese nicht als Bundel heruntergeladen werden können, sondern an vielen verschiedenen Stellen gefunden werden. (Ist bei Java übrigens auch nicht anders, wer Persistenz will braucht eine eigene Bibliothek, etc. pp.)
Aus diesem Grund habe ich die Bibliotheken-"Problematik" mal auskommentiert. ---Helm 17:03, 5. Aug 2005 (CEST)
thread_title:  Schwächen/Fehlende Bibliotheken 

message: === Was der Artikel braucht ... ===
* eine Generalüberholung
::nein braucht der nicht, der ist sehr gut und informativ!!!!
:::das heißt ja nicht, dass man ihn nicht noch verbessern kann
=== Was der Artikel nicht braucht ... ===
* eine Änderung am Hallo-Welt-Programm
* weitere Buchempfehlungen
::ich finde, die beiden Bücher von Bruce Eckel dürfen nicht fehlen, er erhielt den Software Development Jolt Award: best book published für Thinking in C++ und die beiden Bücher sind kostenlos auf seiner Homepage, siehe Artkel über Bruce Eckel
=== Templates vs. generische Datentypen ===
Im Unterkapitel "Vergleich mit anderen Sprachen" steht das die Integration der generischen Datentypen von Java und C# in eine etwas andere Richtung als bei C++ geht was für mein Dafürhalten doch etwas schwammig formuliert ist. Genaugenommen handelt es sich bei Templates um etwas völlig anderes!
Templates werden beim kompilieren erzeugt und sind deshalb eine Art Textersetzung, Generics hingegen werden erst zur Laufzeit auf best. Datentypen spezialisiert.
: Vom Programierer aus gesehen dienen alle Konstrukte dem selben Zweck. Die Technik, die dahintersteckt ist verschieden. dibe 20:39, 4. Dez 2005 (CET)
replies: text:  Nein, Templates und Generics (wie die in C# und C++/CLI) dienen, bedingt durch die unterschiedlichen Konzepte, auch unterschiedlichen Zwecken. Die beiden Konzepte ergänzen sich. Es gibt zwar auch Überschneidungen, aber keines kann das andere vollständig ersetzen. In C++/CLI hat man aus diesem Grund beides!! --Knorxx 20:59, 4. Dez 2005 (CET)
replies: text:  Naja, man hat eher beides, weil C++/CLI C++ mit .NET verbinden soll und das eine nunmal templates, dass andere generics mit bringt. --Kingruedi 21:49, 4. Dez 2005 (CET)

text: Verbreitetster Compiler unter Windows; setzt ab der Version 7.1 die Sprache C++ nahezu vollständig um. Die Nachfolgeversion Visual C++ 2005 Express ist z.Zt. (2005) kostenlos erhältlich.
Die Abkürzung z.Zt. ist noch die alte Rechtschreibung,die Neue sieht zz. oder zzt. vor --Fornax-Galaxies 18:19, 20. Nov 2005 (CET)

text: Stimmt. Leider. Das ist IMHO ein Bug in der Neuen Rechtschreibung. Denn sonst wird doch alles mögliche neuerdings auseinander und groß geschrieben, und "zur Zeit" heißt doch "zu der Zeit". Das wollen die mit mal "zurzeit" schreiben. Ist ja echt zum Kotzen. :-( --RokerHRO 20:13, 20. Nov 2005 (CET)
replies: text: Wenn etwas falsch geschrieben ist, dann korrigiere es doch bitte! --DocSnyder 19:03, 4. Dez 2005 (CET)
thread_title:  weiteres Vorgehen 

message: Im Unterkapitel "Vergleich mit anderen Sprachen" steht das die Integration der generischen Datentypen von Java und C# in eine etwas andere Richtung als bei C++ geht was für mein Dafürhalten doch etwas schwammig formuliert ist. Genaugenommen handelt es sich bei Templates um etwas völlig anderes!
Templates werden beim kompilieren erzeugt und sind deshalb eine Art Textersetzung, Generics hingegen werden erst zur Laufzeit auf best. Datentypen spezialisiert.
: Vom Programierer aus gesehen dienen alle Konstrukte dem selben Zweck. Die Technik, die dahintersteckt ist verschieden. dibe 20:39, 4. Dez 2005 (CET)
replies: text:  Nein, Templates und Generics (wie die in C# und C++/CLI) dienen, bedingt durch die unterschiedlichen Konzepte, auch unterschiedlichen Zwecken. Die beiden Konzepte ergänzen sich. Es gibt zwar auch Überschneidungen, aber keines kann das andere vollständig ersetzen. In C++/CLI hat man aus diesem Grund beides!! --Knorxx 20:59, 4. Dez 2005 (CET)
replies: text:  Naja, man hat eher beides, weil C++/CLI C++ mit .NET verbinden soll und das eine nunmal templates, dass andere generics mit bringt. --Kingruedi 21:49, 4. Dez 2005 (CET)
thread_title:  Templates vs. generische Datentypen 

message: Bei den Compilern steht
:Verbreitetster Compiler unter Windows; setzt ab der Version 7.1 die Sprache C++ nahezu vollständig um. Die Nachfolgeversion Visual C++ 2005 Express ist z.Zt. (2005) kostenlos erhältlich.
Die Abkürzung z.Zt. ist noch die alte Rechtschreibung,die Neue sieht zz. oder zzt. vor --Fornax-Galaxies 18:19, 20. Nov 2005 (CET)
replies: text: Stimmt. Leider. Das ist IMHO ein Bug in der Neuen Rechtschreibung. Denn sonst wird doch alles mögliche neuerdings auseinander und groß geschrieben, und "zur Zeit" heißt doch "zu der Zeit". Das wollen die mit mal "zurzeit" schreiben. Ist ja echt zum Kotzen. :-( --RokerHRO 20:13, 20. Nov 2005 (CET)
replies: text: Wenn etwas falsch geschrieben ist, dann korrigiere es doch bitte! --DocSnyder 19:03, 4. Dez 2005 (CET)
thread_title:  Rechtschreibung 

message: "Dies führte auch zur Entwicklung zahlreicher externer Bibliotheken (z.B. Boost), die ein teilweise unausgereiftes und uneinheitliches Bild von C++ vermitteln." -- Das liest sich, als ob Boost generell unausgegoren und/oder "überflüssig" wäre. Dabei ist sicher gemeint, daß für viele - eigentlich standardmäßige - Aufgaben, jeweils ein Haufen "externer" Bibliotheken für C++ existieren. - M. Moll 6.12.05
:Wie wär's damit, den Verweis auf Boost einfach aus dem Satz zu streichen? Gibt ja keinen Grund, ausgerechnet diese externe Bibliothek zu erwähnen.
::Das wäre eine Möglichkeit. Allerdings finde ich auch die Attributierung als "unausgereift" und "uneinheitlich" überzogen. --Poldi 17:49, 14. Jun 2006 (CEST)
thread_title:  Unglückliche Formulierung 

message: Im Artikel stand "Die Zersplitterung von C++ kann man auch an der Versionsgeschichte des Artikels erkennen, bei dem regelmäßig Änderungen am Hello World-Programm vorgenommen werden, die auf veralteten C++-Normen basieren".
Ein Text, der sich auf das Verfassen des Artikels bezieht, ist ein Metatext und gehört nicht in den Artikel. --Poldi 18:01, 25. Dez 2005 (CET)
thread_title:  Metatexte im Artikel 

message: Das angegebene Papier "Why we can't afford export" ist schon lange überholt. Wenn das Papier Grundlage für die Behauptung im Artikel war, "export" werde in Zukunft entfernt, dann ist die Information schlicht und ergreifend falsch.Es handelte sich übrigens nur um einen Vorschlag zur Entfernung des Sprachmittels "export". Ein Vorschlag ist aber noch kein Beschluss. Bitte genauer recherchieren!  --Poldi 17:51, 25. Dez 2005 (CET)
replies: text: Der Text sagte ja auch und vermutlich in C++0x nicht mehr enthalten sein wird. Beachte das vermutlich. Fakt ist einfach, dass aktuelle Compiler (bis auf den EDG basierten Comeau), nur noch in dem Punkt export nicht Standard kompatibel sind. Der Text erklärt ja auch wunderbar warum. Ich weiß nichts von aktuellerer Entwicklung zu diesem Thema. Bitte klär mich auf, wenn es aktuellere Entwicklung zu diesem Thema gibt. --Kingruedi 19:20, 25. Dez 2005 (CET)
thread_title:  Mehr Sorgfalt bei der Recherche 

message: Sollte bei den Merkmalen nicht auch die Metaprogrammierung aufgeführt werden? Es ist schließlich auch ein Merkmal von C++, einerseits Template-Metaprogrammierung und andererseits makrobasierte Metaprogrammierung die man evtl sogar C als Merkmal hinzufügen könnte--Evilissimo 12:50, 13. Jan 2006 (CET)
replies: text: Ja, würde bei beiden Artikeln grundsätzlich passen. Ob man es beim Präprozessor als Metaprogrammierung bezeichnen sollte, halte ich zumindest bei C für fraglich, aber ein interessantes Sprachmerkmal, da Alleinstellungsmerkmal, ist der Präprozessor allemal. --Poldi 11:09, 14. Jan 2006 (CET)
thread_title:  Metaprogrammierung? 

message: Ich kenn mich jetzt noch nicht so mit programmieren und c++ aus aber ich hab gelesen (oder gehört?), dass MinGW auch ein guter Compiler sein soll und Dev-C++ soll auch praktisch sein?
Wenn das stimmt, dann sollten die doch auch in der Compiler-Liste stehen, oder?
Außerdem wär's vielleicht ganz gut, noch dazuzuschreiben, welche(r) Compiler gratis und welche(r) kostenpflichtig ist/sind .?
--Thomaswm 15:46, 30. Jan 2006 (CET)
replies: text: MinGW ist nur eine minimalistische GNU-Umgebung für Windows. Daher der Name. Als Compiler wird GCC benutzt. Für dich als Einsteiger wäre aber eine - kostenpflichtige - integrierte Entwicklungsumgebung vielleicht besser geeignet. --RokerHRO 16:47, 30. Jan 2006 (CET)

text: Für dich als Einsteiger ist gerade eine überfrachtete und teure IDE nicht das richtige. Es gibt fantastische freie Alternativen. (Open Source und Freie Software) :-) Dev-C++ ist kein Compiler sondern eine IDE, die du dir mal ruhig anschauen solltest. Sie ist für Einsteiger genau das richtige. Der C++-Compiler der MinGW-Umgebung funktioniert super mit Dev-C++ zusammen und sollte in jedem Fall mal ausprobiert werden. --Thornard, Diskussion, 15:38, 4. Feb 2006 (CET)

text: Ich schließe mich der Meinung von Thornard an. Gerade beim Einstieg sollte man wissen bzw. lernen, was unter der Haube passiert. Es lässt sich oft nicht pauschal sagen, ob ein bestimmter Compiler kostenpflichtig oder gratis ist. Das hängt von den Lizenzbestimmungen ab. Einige Compiler sind grundsätzlich gratis, einige Compiler sind in bestimmten Versionen und für bestimmte Einsatzgebiete gratis ansonsten kostenpflichtig, einige Compiler immer kostenpflichtig. Die Lizenzbestimmungen ändern sich zudem nicht selten mit der Veröffentlichung einer neuen Version eines Compilers. Ich glaube, hier aufzulisten, welcher Compiler welchen Lizenzbestimmungen unterliegt, würde den Rahmen eines solchen Artikels, der ja eigentlich die Programmiersprache behandelt, sprengen. Vielleicht macht sich ja mal jemand auf, eine separate Seite über C++-Compiler und -IDEs zu erstellen.--ChristianHujer 18:54, 3. Mär 2006 (CET)
thread_title:  Compiler: [[Dev-C++]] oder [[MinGW]] noch in die Liste? 

message: Naja, die Syntax zw. Java und C++ ist in vielen Stellen leider nur auf die Syntax beschränkt. Die Semantik ist oft eine andere, und Stilfragen lasse ich mal lieber ganz außen vor.
Viele Schlüsselworte gleichen sich, wie sich ihre Bedeutung ähnelt: class, new, throw(s),  { und } für Blockgrenzen, int, float u.A. als Datentypen, die vielen Zuweisungsoperatoren (+=, /= usw.), die Syntax für for- und while-Schleifen und if-Verzweigungen, Funktionsaufrufe, Typumwandlungen und vieles mehr.
Probleme treten immer dann auf, wenn es trotz gleicher öd. ähnlicher Schreibweise subtile oder bedeutende Bedeutungsunterschiede gibt. Das merkt man insbesondere dann, wenn Umsteiger die neue Sprache so nutzen wollen, wie die ihnen vertraute. Dann wird in C++ unnötig oft "new" benutzt; angenommen, ein int sei immer 32 Bit groß; Ausdrücke verwendet, die in C/C++ unbestimmt sind und vieles mehr.
Angesichts dessen würde ich schon sagen, dass die Syntax beider Sprachen recht ähnlich ist. Man kann sich ja auch einfach mal die formale Grammatik beider Sprachen anschauen und wird da große Ähnlichkeiten feststellen.
--RokerHRO 11:50, 12. Mär 2006 (CET)
thread_title:  Ähnliche Syntax 

message: Generische Sprachmittel
Ein wesentlicher Unterschied zwischen diesen Sprachen und C++ besteht darin, dass C++ über generische Sprachmittel (Templates) verfügt.  Es gibt mittlerweile in Java und C# generische Typen. Die Spracherweiterung bei Java erreicht jedoch bei weitem nicht die Leistungsfähigkeit von C++-Templates. Bei C# handelt es sich um eine Erweiterung für Generik zur Laufzeit, die die auf Kompilationszeit zugeschnittenen C++-Templates zwar sinnvoll ergänzen, aber nicht ersetzen können.
OOP vs. generische Programmierung
Gerade die generische Programmierung macht C++ zu einem mächtigen Programmierwerkzeug. Während die objektorientierte Programmierung in Java und C# nach wie vor den zentralen Abstraktionsmechanismus darstellt, ist diese Art der Programmierung in C++ rückläufig. So werden tiefe Klassenhierarchien vermieden, und zu Gunsten der Effizienz und der Minimierung des Ressourcenverbrauchs verzichtet man in vielen Fällen auf Polymorphie, den Kernmechanismus der objektorientierten Programmierung. Auch in Punkto Wiederverwertbarkeit einmal kodierter Algorithmen übertreffen generische Techniken nach Meinung vieler Fachleute die objektorientierte Programmierung.
* C++ bietet mit Templates eine Form der generischen und Metaprogrammierung. Java unterstützt seit Version 5.0 (2004 veröffentlicht) mit den Generics eine Form der generischen Programmierung, die jedoch über dynamische Bindung von Methoden funktioniert. C# setzt seit Version 2.0 auf eine Laufzeitform der generischen Programmierung, die sowohl dynamische Bindung einsetzt, als auch Code-Erzeugung. Eine Metaprogrammierung ist mit den Generics von C# und Java jedoch nicht möglich.
* Während Java- und C#-Code stark auf Vererbung beruht, wird diese in modernem C++-Code häufig durch generischen Code ersetzt. Dadurch entstehen flachere Klassenhierachien, was die Laufzeitkosten verringert. Auch die Metaprogrammierung und die Generierung von Code durch Templates wird in C++ immer häufiger eingesetzt, was den Programmieraufwand erheblich verkürzen kann.  (von Benutzer:Kingruedi)
:Würdest Du mir bitte erklären, wie Metaprogrammierung mittels Templates den Programmieraufwand verkürzt? Außerdem kann ich nicht bestätigen, dass generischer Code Vererbung ersetzt. Kannst Du dafür bitte ein Beispiel bringen? --ChristianHujer 18:42, 26. Mär 2006 (CEST)
replies: text:  Ich hätte da boost::spirit anzubieten, welche komplett via Template-Metaprogrammierung spezifische LL-Parser für Reguläre Ausdrücke bereitstellt. Genauer: Man schreibt - in einer gewöhnungsbedürftigen, da an C++ angepassten Syntax - einen Regulären Ausdruck direkt im C++ Quellcode und der Compiler generiert daraus dann einen passenden Parser. Das verkürzt den Entwicklungsaufwand, verlängert den Compilerlauf zwar, aber null Laufzeitoverhead für das "Compilieren" des Regulären Ausdrucks, wie es bei anderen RE-Bibliotheken oft nötig ist. --RokerHRO 12:01, 29. Mär 2006 (CEST)
replies: text:  Ich glaube, ich muss mal boost::spirit und antlr gegeneinander antreten lassen. Mal sehen, was dabei herauskommt, insbesondere in Bezug auf den Entwicklungsaufwand, aber auch bezüglich der Laufzeit vor allem bei sehr großen Grammatiken. --ChristianHujer 01:36, 30. Mär 2006 (CEST)
replies: text: antlr benutzt externe Programme zum Erzeugen von C/C++-Code. Man muss also immer aus seinem C++-Quellcode raus, in einer separaten Datei den antlr-Kram schreiben, diesen übersetzen und ggf. nachbearbeiten. :-/ Bei boost::spirit hat man alles in seiner C++-Datei, man braucht nur 2 #includes, un der Rest macht der Compiler. Es werden auch keine gesonderten Bibliotheken zum Binary gelinkt. Ich find das schon sehr angenehm, so zu arbeiten. Aber ein Performance-Vergleich wäre natürlich nicht schlecht, um zu sehen, ob denn externe Parsergeneratoren da wenigstens besser sind. :-) --RokerHRO 09:23, 30. Mär 2006 (CEST)
thread_title: Variante-Alt

message: Ich weiß immer noch nicht, was mit "klassischerweise" gemeint war, aber es reicht nicht, die Formulierung einfach durch "in der Regel", "normalerweise" zu ersetzen, denn abgesehen davon, dass so eine Aussage einfach zu verwaschen wäre, um sie überhaupt so stehen zu lassen, trifft es einfach nicht zu. Der erste C++-Compiler überhaupt hat keinen Maschinencode sondern Zwischencode erzeugt, und es hat lange gedauert, bis ein maschinencodegenerierendes Exemplar die Weltbühne betreten hat. Auch der Vorzeigecompiler von Comeau erstellt übrigens Zwischencode. Zudem hängt es doch von der Ausführungsumgebung ab, ob Code von einem echten Prozessor oder einem Prozessoremulator ausgeführt wird. Anders gesagt: Es gibt gar keine strenge Trennung zwischen Zwischencode und Maschinencode, so dass die ganze Unterscheidung hinfällig ist. Es ist einfach ein Implementierungsdetail, das vom individuellen Compiler abhängt. Wir wollen aber hier keinen Compilervergleich, sondern einen Vergleich der Sprachen anstrengen. Deswegen bin ich dafür, diesen Punkt ganz wegzulassen. --Poldi 18:50, 26. Mär 2006 (CEST)
thread_title: '''Zum Thema: Byte-Code, Zwischencode, Maschinencode:'''

message: Annotations werden doch zum Teil mittels #pragmas in C++ nachgebildet. Das sollte man vll anmerken --Kingruedi 14:50, 27. Mär 2006 (CEST)
replies: text: Auch wenn was dran ist - nicht alles in den Artikel reinpacken, nur "weil es stimmt". --Poldi 22:37, 27. Mär 2006 (CEST)

text: Aber wirklich nur zum Teil. Annotations können wahlweise beim Compilieren, beim Laden der Klasse oder garnicht aus der Klasse entfernt werden. Zudem können Annotations an einen bestimmten Typ gebunden werden. Es ist möglich, eigene Annotation-Typen zu deklarieren, und zu Java gehört seit 5.0 das Tool apt zur Auswertung von Annotations z.B. zwecks Code-Generierung oder Extraktion von Metadaten in neue Dateien.--ChristianHujer 01:19, 28. Mär 2006 (CEST)
thread_title:  Annotations 

message: Hier eine Äußerung von B. Stroustrup zu diesem Thema. Darin äußert er sich zur übermäßigen Verwendung von Vererbung bedingt durch das Fehlen von Templates (das war also bevor Templates eingeführt wurden):  (darin übrigens auch eine Anmerkung zum Thema Mehrfachvererbung) --Poldi 19:19, 2. Apr 2006 (CEST)
thread_title:  Zum Punkt "Verwendung objektorientierter Techniken in C++", sowie deren Ersatz durch Generik 

message: Wie Ihr sicher schon bemerkt habt, habe ich statt eines Textes mal eine Tabelle eingefügt. Bei einer Tabelle gibt es weniger Möglichkeiten, sich über Formulierungen zu streiten. Andererseits bietet sie nicht die schönen sprachlichen Möglichkeiten der Formulierung von Zusammenhängen. Von mir aus kann die Tabelle auch wieder rausfliegen, aber bitte bitte nicht mehr den alten Text, dann schon lieber garkeinen. --ChristianHujer 01:26, 28. Mär 2006 (CEST)
replies: text: Ich habe die Tabelle wieder herausgenommen. Ebenso andere Punkte, die momentan noch diskutiert werden. Bitte erst das Diskussionsergebnis abwarten. Das ist so üblich. --Poldi 23:44, 28. Mär 2006 (CEST)
thread_title:  Diskussion bis Einigung 

message: Einen guten und angemessenen Vergleich der Programmiersprachen halte ich für ein schwieriges und komplexes Thema, das im Rahmen des Artikels C++ entweder inhaltlich zu kurz kommt, oder das eigentliche Thema, nämlich C++, weit überschreitet. Ich möchte deshalb den Abschnitt umbenennen in "Bezug zu anderen Sprachen" und dadurch einen etwas anderen Schwerpunkt setzen, bei dem der Überblickscharakter, den ein Enzyklopädie-Artikel ja haben soll, wieder stärker in den Vordergrund gerückt wird. --Poldi 00:05, 29. Mär 2006 (CEST)
replies: text: Guter Plan. Ich finde es sowieso merkwürdig, mit welch "religiösem Eifer" hier einige für oder gegen C++ wettern. Der Artikel soll über C++ möglichst neutral informieren und nicht versuchen, den Leser auf die Seite des Schreibers (der C++ entweder liebt oder hasst) zu ziehen. :-/ --RokerHRO 07:44, 29. Mär 2006 (CEST)
replies: text: @RokerHRO: Könntest du bitte deine Behauptung des religiösen Eifers der Beteiligten hier belegen? Danke. --Revvar %&§ 11:29, 29. Mär 2006 (CEST)
replies: text:  Wenn ich mir die Versionsgeschichte des Artikels so anschaue, so sind da einige Änderungen incl. Reverts und Revert-Reverts drin, insbesondere bei dem Abschnitt über den Vergleich mit anderen Programmiersprachen, aber auch an anderen Stellen. :-/ --RokerHRO 11:40, 29. Mär 2006 (CEST)

text: @poldi: Könntest du bitte den Unterschied zwischen den aktuellen und den von dir gewünschten Schwerpunkt genauer ausführen. Ich erkenne im Moment nicht worauf du hinaus willst. --Revvar %&§ 11:29, 29. Mär 2006 (CEST)
replies: text: Ich würde bei "Bezug zu anderen Sprachen" schwerpunktmäßig auf die historische Entwicklung eingehen, also auf die Entstehung der Sprachen, und wo an welcher Stelle abgeschaut wurde, was ja auch zum Teil schon im bisherigen Text erwähnt wurde (C -> C++; Simula -> C++; Smalltalk -> Java). Die Gefahr, dass wir uns dann mit dem Thema verheben, sehe ich als geringer an. Das soll einen Vergleich der Sprachen nicht völlig ersetzen, aber eben weniger im Sinne eines Leistungsvergleichs. --Poldi 20:49, 29. Mär 2006 (CEST)
thread_title:  Titel des zu bearbeitenden Abschnitts 

message: Entschulidgt zuersteinmal dass ich meinen Kommentar einfach hier so runterknalle, aber ich hatte jetzt nicht allzuviel bedürftniss mir die quotes herauszusuchen.  
Zu virtuellen Methoden und ihrer geschwindigkeit (ich sah einige kommentare, dass diese ja zu langsam seien, oder von der menge der klassen abhängig sind): Die meistverbreitetsten implementationen haben im objekt einen sogenannten vptr, der auf eine tabelle mit funktionen zeigt, die aufgerufen werden. Der overhead zum aufruf einer virtuellen funktion ist somit 2-3 assembleranweisungen (bei optimierung) und somit in den meisten fällen vernachlässigbar klein. 
Zu templates: Ja, ihre gesamte definition muss zur zeit der instantiierung des templates bekannt sein, was dazu führt dass es dauernd mitcompiliert werden muss. Das jedoch ist kein Problem der Sprache, sondern eine eigenschaft die wissentlich während des designs hinzugefügt wurde. Keiner hat templates eingebaut und sich dann gewundert, huch, das dauert ja so lange und alles wird grösser weil sehr viel geinlined wird (übrigens auch das kann man steuern, und der linker sortiert dann doppelte definitionen aus). Vielmehr kann man templates als schablonen sehen, die als ersatz (natürlich ist dies nur einer von vielen gründen) für boiler-plate code z.b. aus macros dienen können. Der z.T. grosse Vorteil von templates ist halt, dass durch das inlinen der overhead an funktionsaufrufen minimiert wird, was bei kleinen funktionen schon grössere zweistellige beträge im geschwindigkeitszuwachs bringt. Generics hingegen versuchen das ganze andersherum aufzuziehen. Wer zeit und lust hat kann sich ja mal deren implementationen anschauen und wird sehen dass dort viele funktions (wenn auch grossteils nur tail-calls) aufrufe passieren. Beide haben also unterschiedliche optimierungsziele, und andere teile bleiben dabei auf der strecke. Man kann genausowenig sagen, dass das problem von c++ integern ist, dass sie eine feste grösse haben, wohingegen aus anderen sprachen die integer variable grössen haben.
Zu sachen wie "void main()" oder "return;/dropout aus main": Mir kommt es so vor als wenn hier einige Programmiersprach-Munchkins am werk sind, die lücken in den sprachstandards suchen um diese lücken (mit welchem zwecke auch immer) verwenden zu können. Zum vollständigen verständniss einer sprache ist dies zwar durchaus lobenswert, jedoch denke ich nicht dass dies bei der diskussion um einen wikipedia artikel angeführt werden sollte. (Genausowenig wie das re-setten von referenzen durch placement new in klassen). Wen solche sachen interessieren sollte sich vielleicht die defect lists durchesehen: http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html  und http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html und wer dann noch interesse hat die proposals für C++0x bei denen genau begründet wird warum neue features eingeführt werden und welche alten unzulänglichkeiten es gibt. Es gibt halt keine Perfekte Programmiersprache, und wem C++ nicht gefällt soll etwas anderes benutzen, und nicht haltlos darüber herziehen. Denn die wirklich sachlichen diskussionen über fehler der sprache finden woanders statt. Achja, und eine bitte hätte ich noch, an diejenigen die immer alles mit absicht falsch verstehen: diesmal vielleicht nicht, ok? Plasmahh 12:57, 15. Mai 2006 (CEST)
thread_title:  weiterer Senf 

message: Compiler, die C99 unterstützen:
* gcc
* Comeau
* Intel
* ... 
Welche weiteren gibt es?
--Kadeck 20:29, 13. Mai 2006 (CEST)
replies: text: Es geht mir nicht um die Liste selbst. Durch die Auflistung von C99-Compilern hier in der Diskussion möchte ich die im Artikel gemachte Aussage Mittlerweile unterstützen viele Compiler diesen neuen Stand C99 besser untermauern. --Kadeck 18:51, 16. Mai 2006 (CEST)
thread_title:  C99 

message: Ich habe bisher den Artikel über Templates ignoriert, weil das TCB-Problem C++-spezifisch ist und auch nicht durch intelligente Programmierung vermieden werden kann. Nur durch "Unterlassung von Templates" seitens des Programmierers oder durch extrem spezialisierte Compiler seitens des Compilerherstellers.
Und ich dachte das gehört nicht in einen Template-Artikel. Jetzt habe ich den mal überflogen un denke, er hat den falschen Titel. Templates sind ein in mehreren Sprachen (C++, Ada) verfügbares Programmierhilfsmittel. Genau darüber steht da nichts drin. Er enthält lediglich C++-Templates und sollte auch so heißen. Dann müsste es einen weiteren Artikel Ada-Templates geben und einen übergeordneten Templates (allgemein)
--Brf+
:Die Tatsache, dass Compiler die Codeaufblähung unterbinden können, zeigt doch, dass es kein Problem der Sprachdefinition ist. --Poldi 15:47, 5. Jun 2006 (CEST)
replies: text: Doch, ganz einfach weil ein mit den Compilerstandardtechniken geschriebener Compiler (flex, bison, ld...) das eben nicht unterbinden kann. Ein C++-Compiler der das tut ist immer eine absolute Sonderentwicklung. Und hat damit ganz eigene Probleme, z.B. ganz banal, dass er nicht so gut getestet wurde wie ein Compiler, bei dem einzelne Module auch für andere Sprachen einsetzbar sind und damit auch in ganz anderem Kontext verwendet werden. Und jede Verwendung von Software ist auch ein Test dieser Software. Deshalb ist Gnu ja auch so fehlerarm.--Brf 09:51, 6. Jun 2006 (CEST)
replies: text: Die C++-Sprachdefinition schreibt aber nicht vor, dass man einen Linker verwenden muss, der für andere Programmiersprachen entwickelt wurde. Das Eliminieren von Mehrfachinstanzierungen ist auch eigentlich nicht kompliziert. Ein Template X, das in zwei cpp-Dateien mit dem gleichen Typ T instanziert wird (Beispiel: X<int> x;), sollte der Linker für das resultierende Programm zusammenfassen können. Ich kann mir nicht vorstellen, dass der g++ dazu nicht in der Lage sein soll. Bist du dir ganz sicher, dass das mit g++ nicht funktioniert? --Poldi 20:53, 6. Jun 2006 (CEST)
replies: text: PS: Ich habe mir sagen lassen, man müsse beim g++ einen Schalter -frepo setzen, um ihn zum Eliminieren der überzähligen Instanzierungen zu veranlassen. Vielleicht ist das ja schon des Rätsels Lösung. Zum Testen würde ich empfehlen, statt umfangreicher Bibliotheken kleine, selbstgeschriebene Klassentemplates zu verwenden, um andere Effekte, die evtl. die Größe des erzeugten Programmes beeinflussen, möglichst ausschließen zu können. --Poldi 22:39, 9. Jun 2006 (CEST)
thread_title:  Template 

message: Das stand einmal im Artikel, wurde aber entfernt. Zu dem Thema äußert sich Stanley B. Lippman, ein Mitarbeiter von B. Stroustrup, in seinem Einführungswerk zu C++ im Kapitel 15.1: "The key idea behind OOP is polymorphism." Ich denke das ist inhaltlich fast deckungsgleich, deshalb bin ich dafür, das wieder in den Artikel aufzunehmen. Eventuell könnte man die Formulierung Kernkonzept durch Schlüsselkonzept ersetzen. --Poldi 20:59, 11. Jun 2006 (CEST)
replies: text: Hier ein paar OO-Grundkonzepte: Objekt, Klasse, Attribut, Operation, Botschaft, Vererbung und Polymorphismus. (Helmut Balzert, Lehrbuch der Software-Technik, Band 1, 1995) - Polymorphismus ist eines der wichtigen, aber nicht das Kernkonzept der OO. Ich vermute mal, dass das ein Denkansatz war, von Polymorphie auf die anderen Konzepte zu schließen. Kapselung nach außen durch Objekte und die Erzeugung der vielen Erscheinungsformen wird dann durch Vererbung erledigt. Aber dieser Denkansatz macht die anderen Konzepte zu Hilfsmittel. Das ist aber falsch, weil jedes dieser Konzepte eine eigene Daseinsberechtigung innerhalb der OO besitzt (Alan Kay: „Zwar entstand OOP aus vielen Gründen... Der wichtigere Grund war der Bedarf für ein besseres Modulsystem ..., das auch das Verbergen von Einzelheiten beinhaltete.“ {Ryan Stansifer, Theorie und Entwicklung von Programmiersprachen, Prentice Hall, 1995}- daher sicher auch der Name: OO). --Revvar (D RT) 09:06, 12. Jun 2006 (CEST)
replies: text: Was meinst du mit dem Satz „Ich vermute mal, dass das ein Denkansatz war, von Polymorphie auf die anderen Konzepte zu schließen.“? --Poldi 18:57, 12. Jun 2006 (CEST)
replies: text: Hallo Poldi, das bezieht sich auf die Aussage von Lippman "The key idea behind OOP is polymorphism." - die ich mir nur so erklären kann, dass er die anderen Konzepte lediglich als Hilfsmittel zur Umsetzung des Polymorphismus sieht. Gruß --Revvar (D RT) 08:19, 13. Jun 2006 (CEST)

text: Es geht nicht darum, was wichtig ist, sondern was die objektorientierte Programmierung ausmacht, und es ist die Polymorphie (genauer gesagt Laufzeitpolymorphie), die dieses Programmierparadigma von anderen abhebt, das Schlüsselkonzept eben. Das, was in dem Zitat von Alan Kay beschrieben ist, nennt sich übrigens Datenabstraktion und wurde viele Jahre vor der objektorientierten Programmierung erfunden. Zu diesem Thema empfehle ich insbesondere die Lektüre von Stroustrups Die C++-Programmiersprache (wie ich es schon weiter oben in dieser Diskussion angegeben habe). --Poldi 17:41, 14. Jun 2006 (CEST)
replies: text: Das ist doch Haarspalterei. Du betrachtest dies, wie Stroustrups Mitarbeiter vermutlich auch, zu sehr aus der Perspektive des Programmierers - der Implementation der Konzepte. Gehe mal gedanklich ein paar Ebenen höher und du wirst sehen, das die OO sich durch den gesamten Entwicklungsprozeß ziehen kann (OOA, OOD, OOP...), von der Analyse an, mit einer teilweise direkten Abbildung zum modellierten System. Sich in Sachen Verständnis der OO ständig auf Stroustrup zu beziehen ist nicht wirklich eine gute Idee, wie man z.B. an den friends sehen kann. Die objektorientierte Programmierung wird durch alle oben aufgeführten Grundkonzepte geprägt, da sie teilweise voneinander abhängen bzw. bedingen. Das Zitat sollte nur klarmachen, wie der Erfinder von Smalltalk die Sache damals angegangen ist. Ich habe nicht behauptet alle verwendeten Konzepte wären von ihm neu erfunden worden. Wenn es überhaupt das Schlüsselkonzept oder Grundkonzept, oder was auch immer, gibt, dann ist es die Modellierung als und mit Objekten. Ein Zitat von Bob Barton verdeutlicht dies ebenfalls: „Zum ersten Mal stellte ich mir das Ganze als den ganzen Computer vor und fragte mich, warum jemand diesen in schwächere Teile aufteilen wollte, die als Datenstrukturen und Prozeduren bezeichnet wurden. Warum sollte man ihn nicht in kleine Computer aufteilen, wie dies beim Time-Sharing begann?“ ([Kay, Alan C., The early history of Smalltalk., SIGPLAN Notices, Jahrgang 28, Nummer 3, März 1993, S. 69-96] zit. in [Ryan Stansifer,Theorie und Entwicklung von Programmiersprachen, Prentice Hall, 1995]). Lies einfach mal andere Literatur dazu, kostenlos und online sind auch viele Vorlesungsskripte zum Thema. Gruß --Revvar (D RT) 13:01, 15. Jun 2006 (CEST)
replies: text: ... wie man z.B. an den friends sehen kann. Was genau kann man daran sehen? Gruß --Poldi 15:01, 15. Jun 2006 (CEST)
replies: text: Ist das nicht offensichtlich? Schon mal drüber nachgedacht, warum andere OO-Sprachen etwas Ähnliches nicht anbieten? Siehe auch meine Empfehlung im letzten Satz davor. Gruß --Revvar (D RT) 07:17, 16. Jun 2006 (CEST)
replies: text: Tja, du musst mir schon auf die Sprünge helfen. Was kann man an friends sehen? --Poldi 11:50, 16. Jun 2006 (CEST)
replies: text: Mach ich doch gerne: mit friends wird die aufgebaute Sichtbarkeitsbeschränkung (private & protected) durchbrochen und führt es im Prinzip ad absurdum. Dadurch erzeugt man genau die Abhängigkeiten von den Interna, die eigentlich, aus guten Grund, vermieden werden sollten. Mir ist persönlich kein Einsatz bekannt, der sich nicht auch ohne friends hätte elegant lösen lassen. Schlimmer noch, werden solche Features von den "Künstlern" unter den Programmierern gern verwendet, erfordern also in der Praxis noch mehr Diziplin und Regeln, beim Umgang mit der Sprache. Ich selbst hatte schon das Vergnügen, mich durch ein paar MLOC C++-Code, verfeinert mit friends und Mehrfachvererbung, durchzuarbeiten, die schlicht ein Produkt fehlender OO-Methoden und -Verständnis waren. Sofern es beim Entwurf der Sprache schon vorhanden war, sehe ich darin ein damaliges fehlendes Verständis der OO bei Stroustrup. Gruß --Revvar (D RT) 21:32, 26. Jun 2006 (CEST)
thread_title:  Polymorphie ist das Kernkonzept der OOP 

message: * Anders als behauptet ändern Zugriffsmodifikatoren wie friends, public, protected ... in C++ nicht die Sichtbarkeit.
* Anders als behauptet bieten die Sprachen Java, C# und Object-Pascal sehr wohl Mechanismen an, die Ähnlichkeit mit friends in C++ haben.
--Poldi 21:12, 12. Jul 2006 (CEST)
replies: text: zur Sichtbarkeitsbeschränkung:  Abschnitt Zugriffskontrolle; allgemeine Verwendung dieses Begriffes zur Beschreibung der Wirkung dieser Schlüsselwörter: "Die Schlüsselwörter public, protected, private, internal, protected internal, die im Wesentlichen ihren Pendants in Java und C++ entsprechen, legen die Sichtbarkeit von Typdefinitionen fest" aus . Zum zweiten Punkt: Ähnlichkeit ist wohl relativ. Das es Umgehungsmöglichkeiten zu friends gibt, habe ich selbst oben ausgeführt. Deine Wikipedia:Quellen ? --Revvar (D RT) 12:02, 13. Jul 2006 (CEST)
replies: text: Da der Artikel davon nicht betroffen ist, möchte ich dieses Thema nicht weiter ausdiskutieren. Dann hätten wir also folgenden Stand: Die Seite auf der Uni Münster behauptet, die Zugriffsmodifikatoren ändern die Sichtbarkeit, und ich behaupte das Gegenteil. Das kann man doch einfach mal so stehen lassen. Gruß --Poldi 15:09, 16. Jul 2006 (CEST)
replies: text: Wozu das dann? - du verschwendest meine Zeit. Meinungsäußerungen, ohne Artikelbezug, haben hier keinen Platz. Aber darauf scheint es bei dir ja rauszulaufen, wie man an der ganzen unseligen Friends-Diskussion sehen kann. Diskutieren der Diskussion willen, und wenn du Quellen bringen sollst, hast du keine Lust mehr. Ich werde dies hier, ab deiner Anfrage an mich, deshalb alles in meinen Benutzerraum verschieben. --Revvar (D RT) 18:32, 16. Jul 2006 (CEST)
replies: text: Nein, dort gehört es nicht hin. Aber du kannst dir ja eine Kopie machen. --Poldi 21:13, 16. Jul 2006 (CEST)
thread_title:  Ergänzende Hinweise zum Thema "Friends" 

message: (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:
* Prozedurale Programmierung
* Modulare Programmierung
* Strukturierte Programmierung
* Programmierung mit selbstdefinierten Datentypen (abstrakte Datentypen)
* Objektorientierte Programmierung (siehe auch Polymorphie (Vielgestaltigkeit))
* Generische Programmierung mittels Templates.
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++ [] 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 [], [] und []
* 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 [], Benchmarkergebnisse  für GCC u.a. bei [], 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)
replies: text: (Anm.: Habe zum Zwecke der besseren Darstellung auf dieser Seite die Überschriftenebenen geändert) --Dtk 21:53, 8. Aug 2006 (CEST)
thread_title:  Merkmale der Sprache 

message: 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:
* Prozedurale Programmierung
* Modulare Programmierung
* Strukturierte Programmierung
* Programmierung mit selbstdefinierten Datentypen (abstrakte Datentypen)
* Objektorientierte Programmierung (siehe auch Polymorphie (Vielgestaltigkeit))
* Generische Programmierung mittels Templates.
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++ [] 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 [], [] und []
* 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 [], Benchmarkergebnisse  für GCC u.a. bei [], 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)
replies: text: (Anm.: Habe zum Zwecke der besseren Darstellung auf dieser Seite die Überschriftenebenen geändert) --Dtk 21:53, 8. Aug 2006 (CEST)
thread_title: Vorschlag

message: =====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:
* Prozedurale Programmierung
* Modulare Programmierung
* Strukturierte Programmierung
* Programmierung mit selbstdefinierten Datentypen (abstrakte Datentypen)
* Objektorientierte Programmierung (siehe auch Polymorphie (Vielgestaltigkeit))
* Generische Programmierung mittels Templates.
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++ [] 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 [], [] und []
* 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 [], Benchmarkergebnisse  für GCC u.a. bei [], 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)
replies: text: (Anm.: Habe zum Zwecke der besseren Darstellung auf dieser Seite die Überschriftenebenen geändert) --Dtk 21:53, 8. Aug 2006 (CEST)
thread_title:  Merkmale 

message: --Brf 17:04, 8. Aug 2006 (CEST)
replies: text: (Anm.: Habe zum Zwecke der besseren Darstellung auf dieser Seite die Überschriftenebenen geändert) --Dtk 21:53, 8. Aug 2006 (CEST)
thread_title: Vorschlag Ende 

message: Worin unterscheidet sich dieser Compiler vom Borland C++? Muss man wirklich beide erwähnen?
: Borland C++ Compiler sollte eher bald raus aus der Liste! Denn Borland Entwicklertools wird es zukünftig nicht mehr geben, da sie ausgegliedert wurden. Ich habe Turbo C++ eingefügt, weil darin der zukünftige Compiler enthalten ist. Soll heißen, die Tools heißen zukünftig "Turbo Sowieso" von einer anderen Firma. Amin K 13:02, 11. Dez. 2006 (CET)
replies: text:  Mit "zukünftigen" Dingen sollten wir in der Wikipedia immer vorsichtig sein. Wenn es soweit ist, können wir ja immer noch reagieren. --Poldi 17:53, 12. Dez. 2006 (CET)

text: Ohne eine vernünftige Definition von Relevanz, finde ich das vorgehen eher fragwürdig. Ob die Tabelle nun 2 Zeilen mehr oder weniger hat, ist für den Artikel völlig irrelevant. Aber ob man Implementierungen streicht, weil sie einem irgend wie "erscheinen", ist nicht richtig. Also entweder vernünftige Kriterien aufstellen oder alle aufnehmen. --Kingruedi 17:34, 26. Dez. 2006 (CET)
replies: text: Ich würde sagen, eher einige weglassen, als zu viele Aufnehmen. Es sollten nur solche Compiler aufgenommen werden, die für die Entwicklung der Sprache C++ von besonderer Bedeutung sind oder waren, und das sind im Großen und Ganzen diejenigen, die ich übrig gelassen habe. Den Watcom könnte man vielleicht auch weglassen. Es gibt Richtwerte für die Aufnahme von Weblinks, und da habe ich eine Anzahl von etwa 5 im Hinterkopf. Daran würde ich mich auch hier in etwa orientieren. --Poldi 13:56, 27. Dez. 2006 (CET)
replies: text:  Also ich versteh das nicht. Warum wird der Borland Conmpiler drin gelassen, obwohl er nicht mehr weiter verkauft wird? Ich habe doch schon weiter oben gesagt, das Borland keine Compiler und IDEs mehr entwickelt und verkauft. Deshalb hatte ich den Turbo C++ aufgenommen, weil das der offizielle Nachfolger ist. Denn Borland hat seine Developer Tools nach Codegear ausgegliedert (neue eigenständige Firma). Wenn dann müsste der Borland C++ raus, und der neue Turbo C++ muß drin bleiben. Amin K 12:23, 28. Dez. 2006 (CET)
replies: text: Warum wird der Borland Conmpiler drin gelassen, obwohl er nicht mehr weiter verkauft wird? - Weil die Compiler-Liste kein Einkaufsführer sein soll, sondern, wie gesagt, Compiler aufführen soll, die für die Entwicklung der Sprache C++ von besonderer Bedeutung sind oder waren. (s.o.) --Poldi 17:22, 28. Dez. 2006 (CET)

text: Ich sehe jetzt keinen Grund dafür, die Liste irgend wie zu filtern. Ansonsten fehlt ja noch der CFront-Compiler. Die IBM-Compiler sind dann für die Entwicklung auch wichtig, weil sie die einzigen Compiler sind, die Header nicht als Datei-Konzept benutzen etc. --Kingruedi 18:45, 28. Dez. 2006 (CET)
replies: text: Wir müssen es nicht übers Knie brechen. Aber "Filtern" gehört zu den wichtigsten Aufgaben eines Wikipedia-Autors. Der cfront-Compiler ist im Artikel erwähnt. Die Nichtverwendung der Header als Datei-Konzept ist ja eigentlich nur ein Detail. Ich sehe nicht, inwiefern das für die Entwicklung der Programmiersprache von besonderer Bedeutung sein soll. Das Hauptproblem ist meiner Meinung nach auch hier die Listenform. --Poldi 12:44, 31. Dez. 2006 (CET)

text: Irgendwie fehlt Glockenspiel C++, der noch erhaeltlich ist und historisch auch von besonderem Interesse. Meines Wissens war es einer der ersten kommerziellen C++ Compiler und als C-Preprocessor implementiert. --195.14.196.122 15:03, 10. Jun. 2007 (CEST)
thread_title:  Turbo C++, Sun Studio, IBM XL C/C++ 

message: Die (bisherigen) Syntaxregeln von C++ fassen >> als ein Token auf. Es ist nicht vorgesehen, dass diese beiden Zeichen optional oder falls es einen Syntaxerror geben sollte als zwei Token interpretiert werden sollen. Zumindest habe ich im Standard nichts dazu gefunden. Wenn ein Compiler das tut, okay, dann ist er benutzerfreundlich und fehlertolerant. Denn eigentlich ist obiges Beispiel schlicht fehlerhaft und ein Compiler hat den Code zurückzuweisen. In C++0x soll das evtl. geändert werden, schaunmermal. Noch gilt jedenfalls C++89 mit den kleinen Änderungen von 2003 (ISO-IEC 14882:2003). --RokerHRO 19:20, 16. Dez. 2006 (CET)
replies: text: Ein Compiler hat den Code nicht unbedingt zurückzuweisen. Ein Compiler darf die Sprache erweitern, ohne den Rahmen der Konformität zu verlassen, wenn vorhandene Programme dadurch nicht a) ungültig werden, oder b) deren Bedeutung dadurch verändert wird. Für den beschriebenen Fall mit den spitzen Klammern bei Templates ist das zwar kompliziert, aber möglich. --Poldi 18:55, 17. Dez. 2006 (CET)
replies: text: Hm, okay. Ein Compiler hat ein korrektes Programm korrekt zu übersetzen. Bei fehlerhaften Programmen kann er ... alles mögliche machen. Er kann einen Fehler ausgeben, er kann auch versuchen zu raten, was der Programmierer gemeint hat und in seinem Sinne das Programm dann parsen. Stimmt. Mein Fehler. :-/ --RokerHRO 21:34, 17. Dez. 2006 (CET)
replies: text: Der Zweck dieser Regelung ist wohl ein anderer. Vermutlich soll dadurch die Möglichkeit für Spracherweiterungen offen gehalten werden. Nicht zuletzt lebt C++ davon, dass Erweiterungen, bevor sie in die offizielle Sprache einfließen, möglichst ausgiebig in der Praxis getestet wurden. --Poldi 19:49, 20. Dez. 2006 (CET)

text:  >> als Template-Beender und nicht als Shift-Operator aufzufassen ist keine Spracherweiterung sondern eine Sprachveränderung.--87.165.75.203 14:19, 2. Jul. 2007 (CEST)
replies: text: Jain. Wenn es nur dort gemacht wird, wo sich sonst ein Syntaxfehler ergäbe, der Quellcode also vorher gar kein gültiges C++-Programm war, ist es eine Spracherweiterung. So wie ein (fiktiver) operator^^ auch eine Spracherweiterung wäre. --RokerHRO 15:04, 2. Jul. 2007 (CEST)
replies: text:  Es würde die Max-Munch Regel außer Kraft setzen und die ist Teil der Sprache (bzw. des Standards). --87.165.75.203 15:52, 2. Jul. 2007 (CEST)
replies: text:  Nein, die Max-Munch-Regel gilt ja nur für (normgerechte) C++-Programme. Wer aber   std::set<std::pair<int,int>> s; schreibt, hat kein gültiges C++-Programm. Einem Compiler ist es nun freigestellt was er mit nicht der C++-Norm  entsprechendem Quelltext macht. Er kann z.B. einfach mit exit(1) die Übersetzung kommentarlos abzubrechen, eine mehr oder weniger sinnvolle Fehlermeldung auszugeben oder ... versuchen, den Quelltext als nicht-normgerechtes C++-Programm zu parsen und so vielleicht doch noch etwas aus dem Quelltext herauszuholen, was der menschliche Schreiber damit gedacht haben könnte. --RokerHRO 16:07, 2. Jul. 2007 (CEST)
thread_title:  >> vs. > > 

message: --Brf 17:04, 8. Aug 2006 (CEST)
replies: text: (Anm.: Habe zum Zwecke der besseren Darstellung auf dieser Seite die Überschriftenebenen geändert) --Dtk 21:53, 8. Aug 2006 (CEST)
thread_title:  Vorschlag Ende 

message: 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)
thread_title:  Überarbeitung 

message: Ich habe viele Links rausgeworfen. Hier meine Begründung gemäß Wikipedia:Weblinks:
* toter Link: Oft gestellte Fragen und Antworten, englisch
* keine Diskussionsforen: C++-Diskussionsgruppe, deutsch
* keine Unterbegriffe: Die C++-Bibliothek von Boost
* keine Unterbegriffe: Hans Boehms Garbage-Collector für C++, englisch
* Qualtiät - der Artikel ist bereits ausführlicher als dieser: C++ im Deutschen Software Entwickler Wiki
* zu schlechte Qualität, da veraltet und unvollständig: Gegenüberstellung der bekanntesten Compiler, englisch
* keine Foren: Größte Community-Seite in Deutschland zu C++
--Revvar (D RT) 10:00, 15. Aug 2006 (CEST)
thread_title:  Weblinks 

message: 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)
thread_title:  Einrichtung einer Meta-Seite 

message: iostream oder iostrem.h ? Ichrag, weil jemand ohne zufragen geändert hat.--A-4-E 17:14, 21. Mai 2007 (CEST)
replies: text: iostream. Wie alle Header der Standardlibrary ohne .h. --RokerHRO 19:02, 21. Mai 2007 (CEST)
thread_title:  iostream