Diskussion:C++

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „C++“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Teil 1	Teil 2	Teil 3

Automatische Archivierung

Auf dieser Seite werden Abschnitte halbmonatlich automatisch archiviert, deren jüngster Beitrag mehr als 80 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 6 Abschnitte.

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Für Änderungen am „Hallo Welt“-Beispielprogramm bitte diese Diskussion beachten!

Neuerungen von C++11, 14 und 17 erweitern und/oder auslagern?

Die Neuerungen, die C++11 brachte, sind ja recht ausführlich im Artikel beschrieben. Für C++14 und C++17 ist das leider nicht der Fall, was ich sehr schade finde und gerne ergänzen würde.

Was meint ihr: Soll das mit in den Artikel oder wäre es sinnvoll, das in einen separaten Artikel auszulagern, wie es z.B. bei C auch gemacht worden ist? --RokerHRO (Diskussion) 12:13, 19. Jul. 2017 (CEST)

Sollte mein ich deine Entscheidung sein, kann doch niemand besser beurteilen als der Autor, zumal's ein bisschen vom Umfang abhängt. Aber wenn's nach mir geht, auslagern. Dürfte auch eher wenige interessieren, die (so) einen Übersichtsartikel aufsuchen. Das mit der (Entstehungs)geschichte würd ich aber hier belassen, vielleicht könnte man das dann auch mal nach oben verschieben. Verstehe jdf. nicht, wieso das da ganz unten hängt, eher unüblich. -ZT (Diskussion) 19:53, 23. Jul. 2017 (CEST)

Puh, viele Änderungen, viel Meinung, keinerlei Belege… :-(

Nun wurde der Artikel reichhaltig editiert, es kam eine Menge Text hinzu, viel Meinung, aber leider wenig Inhalt, und keine Belege. :-(

Die neuen Aussagen sollten also dringend mit Belegen versehen werden, ansonsten würde ich sie in Kürze als "unbelegte persönliche Meinung" wieder rauswerfen, da sie den Artikel in der jetzigen Form nicht verbessern:

1. Warum es in C und C++ so viele Konstrukte mit "undefined behavior" gibt, ist nicht belegt. Entweder jemand findet eine Quelle, wo die Sprachschöpfer sich zu den Gründen äußern, oder es bleibt Spekulation und sowas brauchen wir in der WP nicht.
2. Welche Vor- oder Nachteile ein Compiler aus diesen "Freiheiten" schöpfen kann (oder eben nicht), ist nicht belegt. Da würden z.B. Aussagen von Compilerbauern helfen. Ich erinnere mich vage, dass die GCC-Entwickler mal etwas darüber geschrieben hatten.
3. Als "Referenz" ein anderes Wiki angeben, ist nach WP:Belege im Allgemeinen nicht zulässig, die damit "abgesicherten" Aussagen gelten also weiterhin als unbelegt.
4. Der Abschnitt "Pointer" ist unbelegt und damit ebenfalls nur eine Privatmeinung.
5. Der behauptete Aufwand für die Pflege von Header- und Source-Dateien ist dank moderner IDEs eher unbedeutend (meiner Meinung nach). Wer also meint, der Aufwand sei immernoch erheblich oder gar störend für die Verbreitung der Sprache usw. sollte dafür Belege finden und angeben.
6. Codebeispiele sollten korrekten und stilistisch sauberen Code zeigen. (Wie schon in der Schule: Man soll Falsches nicht wiederholen).
7. Wenn – etwa im Abschnitt "Kritik" – veranschaulicht werden soll, dass "richtiger" und "falscher" Code einander sehr sehr ähnlich sind, sollte der als "richtig" angegebene Code auch wirklich richtig und stilistisch sauber sein.

Generell sollte Kritik nicht von "außen" kommen (also von Leuten, die C++ kaum beherrschen und sich auch nicht als Teil der "C++ Community" sehen), sondern besser von "innen" (also von Leuten, die C++ kennen, intensiv benutzen und vielleicht sogar mitgestaltet haben) da diese Kritik dann fundierter, gehaltvoller und vor allem sachlicher ist. Sowohl private Blogs als auch Webseiten, die mit reißerischen Titel versuchen, Klicks zu generieren, halte ich darum für ungeeignet, als als Quellen für "Kritik" ausgewählt zu werden. --RokerHRO (Diskussion) 10:08, 8. Aug. 2017 (CEST)

+1 Zustimmung: Viele Behauptungen, die ohne Belege revertiert werden müssen. Grüße, --Schotterebene (Diskussion) 11:24, 8. Aug. 2017 (CEST)

Insgesamt auch viel Zustimmung von mir. Aber zu Punkt 1 und teilweise auch Punkt 2 von Ihnen: Jein. Hier kommen wir meiner Meinung zu nah an die "Quellennachweisgranularität" heran. Der Punkt "undefined behavior" wird von mehreren angegeben Quellen erstmal prinzipiell hier abgedeckt. Meyers und besonders Sutter behandeln ihn je nach Auflage auch im Detail und fast jeder hier genannte Punkt findet sich bei diesen (verteilt). Da der Artikel bereits ein Thema behandelt, welches tiefer im Hauptgenre der Informatik/Programmiersprachen verankert ist, sind die hier getroffenen Aussagen zu diesem Verhalten natürlich auch mit Hinblick dieses Kontextes zu sehen, womit meiner Meinung nach bereits ein allgemeiner Verweis auf eine allgemeine Quelle zum Compilerbau und zur Theorie und Praxis der Programmiersprachen und entsprechender Codeoptimierungen genügen sollte (müsste also noch nachgetragen werden). Auch sind einige Unterpunkte dazu hier im Artikel so trivial und im Rahmen eines Informatik-bezogenen Artikels offensichtlich banal, dass ich der Meinung bin, dass zu dedizierte Nachweispflicht hier nicht per se notwendig ist. Denn diese Punkte leiten sich ja (mehrheitlich) nicht von irgendwelchen speziellen Absprachen der C++ Gremien zum Standard ab, sondern ergeben sich oft direkt aus der Definition der allgemeinsten Sprachkonstrukte (im Zusammenspiel mit Speicher/Prozessor-Modellen). Ist nur als Anmerkung gedacht, vielleicht sehe ich das auch nur zu locker, wenn man jeden Tag damit arbeitet. --Petrucciation (Diskussion) 21:33, 28. Okt. 2017 (CEST)

> 1. Warum es in C und C++ so viele Konstrukte mit "undefined behavior" gibt, ist nicht belegt. Entweder jemand findet eine Quelle, wo die Sprachschöpfer sich zu den Gründen äußern, oder es bleibt Spekulation und sowas brauchen wir in der WP nicht.

Undefined ist was undefined ist!?

> 2. Welche Vor- oder Nachteile ein Compiler aus diesen "Freiheiten" schöpfen kann (oder eben nicht), ist nicht belegt. Da würden z.B. Aussagen von Compilerbauern helfen. Ich erinnere mich vage, dass die GCC-Entwickler mal etwas darüber geschrieben hatten.

Das ist sehr wohl definiert. Da braucht es keine Auskunft von einem Compilerschreiberling.

> 4. Der Abschnitt "Pointer" ist unbelegt und damit ebenfalls nur eine Privatmeinung.

Ich weiß nicht auf welche Artikelversion Du Dich damals bezogen hast, aber vor allem ist der Abschnitt "Kritik" Schrott.

> 6. Codebeispiele sollten korrekten und stilistisch sauberen Code zeigen. (Wie schon in der Schule: Man soll Falsches nicht wiederholen).

ZZt ist nur gültiger Code (well formed) im Artikel. Wobei

template <typename ObjectCreatorType>

auto createObject (const ObjectCreatorType& creator) -> decltype( creator.makeObject() )

{

return creator.makeObject();

}

total sinnfrei ist.

auto foo() { return 42; }

würde dasselbe zeigen.

Es wäre nett wenn sich an solch einem Artikel nur Leute beteiligen würden die wenigstens ein bisschen Ahnung haben was sie reden.

@Petrucciation > Denn diese Punkte leiten sich ja (mehrheitlich) nicht von irgendwelchen speziellen Absprachen der C++ Gremien zum Standard ab, sondern ergeben sich oft direkt aus der Definition der allgemeinsten Sprachkonstrukte (im Zusammenspiel mit Speicher/Prozessor-Modellen).

Du bist auch ein "Speicher/Prozessor-Modell". Der Standard definiert ganz unmissverständlich eine Maschine. [intro.abstract]:

*[...] Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.*

213.147.165.6 12:30, 8. Aug. 2019 (CEST)

@Namenlos:

"Der Standard definiert ganz unmissverständlich eine Maschine." Was hat das mit meinen Ausführungen zu tun? Sicher, dass Sie verstanden haben, worauf ich hinaus wollte? Im Übrigen gibt es erst mit C++11 ein standardisiertes Memory Model. Soviel zum Thema versionsunabhängig allgemeine Statements...

"total sinnfrei ist.

auto foo() { return 42; }

würde dasselbe zeigen."

Nö würde es nicht in der selben Qualität(!), auch wenn das decltype in dem Fall hier redundant ist. Es ist schon ein Unterschied, ob der Compiler über SFINAE auch noch auto erlaubt oder nicht. Hier fehlt halt nur noch ein mächtiges Beispiel, wo genau das zum Tragen kommt. Ergänze ich gern mal, wenn Zeit ist. Ihr Beispiel wiederum ist im Zweifelsfalle sogar problematisch im Sinne der Anschauung, da Literale in der Regel keine guten Beispiele für klar definierte Datentypen sind (denen man ihren Typ eindeutig sofort ansieht) und im weiterführenden Falle von Overloads/Überschreibungen und Spezialisierungen man ironischerweise trotz der Einfachheit des Datentyps schnell die Orientierung verlieren kann...

"Es wäre nett wenn sich an solch einem Artikel nur Leute beteiligen würden die wenigstens ein bisschen Ahnung haben was sie reden." Ja wie wäre es, wenn Sie sich selbst dran halten würden? Kommt zu Ihren Punkten auch nur ein valider Beleg? Und was soll Ihre tautologische Aussage zum Thema undefined behavior? Aber vielleicht habe ich Sie auch nur falsch verstanden...--Petrucciation (Diskussion) 21:25, 7. Nov. 2019 (CET)

Eigenschaften = Nachteile?

Ich finde es unglücklich, dass sich der Abschnitt "Eigenschaften" hauptsächlich mit Nachteilen von C++ beschäftigt. Und das zudem in einer äußerst einsteigerunverständlichen Weise. --46.189.36.164 17:10, 21. Aug. 2018 (CEST)

Abschnitt "Umsetzung"

Microsofts C++ Compiler sollte nicht "Visual C++" genannt werden. Microsoft selbst bezeichnet das Paket schlicht als "Microsoft C++ toolset". -- Swordfishx86 (Diskussion) 11:30, 5. Mär. 2020 (CET)

Programmbeispiel

> return 0;

Entweder EXIT_SUCCESS oder weglassen!

> Bei return 0 wird dem aufrufenden Programm über das Betriebssystem mitgeteilt, dass die Ausführung des Programms erfolgreich war.

Ähm. Nein.

Swordfishx86 (Diskussion) 00:44, 28. Dez. 2020 (CET)

Oh doch! Wenn man keine Ahnung hat, sollte man sich entweder schlau machen oder den Ball flachhalten. Sonst macht man sich nur zum Brot. Also bringen wir mal etwas Fachkunde in die Runde:

1. Lesen wir, was return in der main()-Funktion bedeutet:

„Execution of the return (or the implicit return upon reaching the end of main) is equivalent to first leaving the function normally (which destroys the objects with automatic storage duration) and then calling std::exit with the same argument as the argument of the return. (std::exit then destroys static objects and terminates the program)“ (https://en.cppreference.com/w/cpp/language/main_function)

2. Es wird also auf exit() verwiesen. Und dort lesen wir:

„control is returned to the host environment. If exit_code is 0 or EXIT_SUCCESS, an implementation-defined status indicating successful termination is returned. If exit_code is EXIT_FAILURE, an implementation-defined status indicating unsuccessful termination is returned. In other cases implementation-defined status value is returned.“ (https://en.cppreference.com/w/cpp/utility/program/exit)

Herzlichst, --RokerHRO (Diskussion) 15:16, 29. Dez. 2020 (CET)

Abschnitt Kritik

Hallo Leute, ich finde den Abschnitt inklusive der Zitate nicht wirklich Sinnvoll!

1. Die meisten der Zitate sind Uralt

2. Die Kritik ist nicht ausgewogen und wird in keinem Kontext dargestellt

3. Die Punkte Garbage Collection ist spätestens mit den smart pointern obsolet

4. Java hat z.B. keinen eigenen Kritikbereich

Grüße--pmqtt (nicht signierter Beitrag von 2003:DC:771A:36EF:DD2A:14C7:6146:E8D4 (Diskussion) 15:42, 9. Jun. 2021 (CEST))

Warum ist das nicht sinnvoll? Kritik ist immer sinnvoll, auch um Entscheidungen treffen zu können. Wenn die Kritik dazu noch belegt ist und mit Zitaten vielleicht leichter verständlich wird umso besser.

Zu deinen Punkten:

1. uralt ist relativ und in der WP irrelevant. Diese Zitate wurden getätigt und wenn sie noch passen um den jeweiligen Punkt zu untermauern, dann passen sie ewig. Wenn du bessere Zitate zu den Kritikpunkten findest, dann gerne...
2. bitte einfach verbessern - aus meiner Sicht stimmen auch ein paar Dinge nicht (z.B. Performance war vielleicht in den 90ern im Vergleich zu anderen schnellen Sprachen besser)
3. Smart pointer sind nicht mit garbage collection vergleichbar oder machen sie obsolet. Siehe z.B. zyklische Abhängigkeiten, Defragmentierung, short pointer
4. Stimmt nicht - siehe Java-Technologie#Kritik - und auch wenn, dann wäre das kein Grund den Abschnitt hier zu löschen, eher ein Grund den Abschnitt dort hinzuzufügen.

--Sebastian.Dietrich  ✉  17:42, 9. Jun. 2021 (CEST)

Ich finde den Abschnitt völlig angebracht. Man könnte ihn noch detailierter ausführen. --Trustable (Diskussion) 18:00, 9. Jun. 2021 (CEST)

RE: Vielleicht hätte ich meine Äußerung etwas präzisieren sollen Ich finde den Abschnitt Kritik so nicht Sinnvoll

1. die meisten Zitate beziehen sich auf ein Historisches C++ welches heute so nicht mehr genutzt wird
2. kann ich versuchen
3. -
4. Bei der Beschreibung von Java,C#,PHP,Goland (Programmiersprachen) und vielleicht noch andere ( habe ich nicht geprüft) gibt es kein extra Kritik Abschnitt. Ich finde es auch ehrlicherweise schwierig. Eine objektive Kritisierung eine Sprache und ihrer Merkmale ist kaum möglich. Für die einen ist die garbage collection der Heils Bringer für die anderen eine Möglichkeit die Performance eines Programms zu schädigen. Für die einen sind smart pointer der Heils Bringer für die anderen nur ein Pflaster, um eine inhärente Schwäche einer Sprache zu, verdecken. Mir geht es nicht Grundsätzlich eine Kritik an der Sprache nicht zuzulassen, sondern darum, dass es unglaublich Schwierig ist über Programmiersprachen zu diskutieren und man vielleicht bei einer nüchternen Betrachtung und Beschreibung der Sprache bleibt.

--pmqtt (nicht signierter Beitrag von 2003:DC:771A:36E9:A9A6:FBCE:84C2:7B19 (Diskussion) 14:58, 12. Jun. 2021 (CEST))

Danke für die Präsisierung. Zu den Punkten:

• welcher von den 4 Punkten bezieht sich auf C++, das heute nicht mehr so genutzt wird. Ich sehe bei den 4 Punkten (komplex, low-level, schnell, heftige Auswirkungen von Fehlern) nichts, das heute nicht 1:1, wenn nicht sogar stärker (komplex) ist als früher.
• bei der Kritik gehts nicht, was du, ich oder sonst ein Autor in der WP gut, schlecht oder sonstwie finden. Wenn ich z.B. finde, dass C++ zu "lila" ist, dann kann ichs nicht reinschreiben. Wenn ich aber wo einen Beleg finde, wo "C++ ist zu lila" geäußert wird, dann kann ichs reinschreiben. Auch wenn A sagt, C++ ist zu lila und B sagt, C++ ist zu wenig lila und C sagt, C++ ist genau richtig lila - dann sollte in Kritik alles enthalten sein.

--Sebastian.Dietrich  ✉  07:56, 13. Jun. 2021 (CEST)

Erster Punkt mit Quelle von 1992, täusch ich mich oder war das sogar noch vor der STL?! Naja. Uralt ist sicher relativ, alles ist relativ, aber Kritik in so'nem Artikel müsste schon zumindest auch korrepondieren mit dem, was der Artikel selbst beschreibt. Und dieser versucht wenigstens mit der Entwicklung dieser Sprache einigermaßen Schritt zu halten, was schwer genug ist. Ob ein Ziel wie C++, das sich bald alle vier Jahre selbst versucht, neu zu erfinden (ich übertreibe, leicht) auch im Hinblick auf die verbleibende Manpower hier nicht doch einfach zu schnell sein könnte, um das auch absehbar in sinnvollem Zustand zu erhalten, kann man anders beurteilen. Perl hat auch Kritik, nur ist die Sprache auch seit vielen Jahren praktisch eingemottet, da ändert sich also nicht mehr viel. Hier hingegen werden Kinderkrankheiten der nackten Sprachebene gestriffen, die im praktischen Einsatz einfach keine Relevanz mehr haben. Eher könnte man bald das Gegenteil belasten, insofern es schon in Anbetracht der Reife und schieren Verfügbarkeit von (Lern)ressourcen gerade beim Einstieg klare Vorteile gibt etwa ggü. neueren Playern wie Rust. Eine Quelle von vor 30 Jahren aber kann hier bestenfalls einen Abschnitt Geschichte bereichern. -ZT (Diskussion) 14:06, 18. Jun. 2021 (CEST)