Diskussion:C++/Archiv/3

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:C++/Archiv/3#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:C%2B%2B/Archiv/3#Thema_1

- 2009 -

Änderung Infobox: Dialekte-->Standardisierung

Hallo,

ich werde, wenn innerhalb von 5 Tagen keiner laut schreit, in der Infobox des Feld "Dialekte" in "Standardisierungen" ändern. Curtis Newton ↯ 11:06, 14. Jan. 2009 (CET)

Bedeutet das nicht, daß die Vorlage geändert werden muß, soll das dann in allen Artiekln Standardisierungen heißen? Letzteres halte ich für riskant. --Matthias Kupfer 15:48, 15. Jan. 2009 (CET)

Die Vorlage habe ich schon geändert. Und in anderen Artikel sollte es Standardisierungen heißen, wenn es diese halt sind und keine Dialekte. Curtis Newton ↯ 16:01, 15. Jan. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Curtis Newton ↯ 17:59, 23. Jan. 2009 (CET)

Änderung Infobox: Reihenfolge Wichtige Implementierungen

Hallo,

ich werde in 5 Tagen, wenn keiner laut schreit, die Reihenfolge in "Wichtige Implementierungen" ändern. In das hier:

C++/Archiv/3
Wichtige Implementierungen:	C++ Builder, GCC, MS Visual C++

Dann ist das alphabetisch. Curtis Newton ↯ 11:08, 14. Jan. 2009 (CET)

+1 --norro ^wdw 12:20, 14. Jan. 2009 (CET)

Ich habe da zwar nichts dagegen, aber was leigt dem zugrunde? --Matthias Kupfer 15:47, 15. Jan. 2009 (CET)

Das ist einfach eine "neutrale" Sortierungsart. Siehe auch hier. Curtis Newton ↯ 16:00, 15. Jan. 2009 (CET)

Was sucht der C++Builder da? Wird der heute überhaupt noch eingesetzt? Und was ist mit Intel C++ Compiler? Der soll superschnellen Code erzeugen und ist halt von Intel. Ich kenne aber keine Zahlen zu den Marktanteilen. --LeClochard 00:55, 17. Jan. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Curtis Newton ↯ 17:58, 23. Jan. 2009 (CET)

Tupel

Kann jemand den Link auf Tupel (Informatik) ändern? Danke. – Simon Diskussion/Galerie 09:07, 14. Jan. 2009 (CET)

erledigt. --Zollernalb 10:12, 14. Jan. 2009 (CET)

InfoBox: Beeinflusste

C#? PHP? etc. - Ich bitte euch! Dann belegt diesen angeblichen Einfluß auch im Artikel. --Succu 16:01, 15. Jan. 2009 (CET)

Für C# habe ich es mal gemacht : Edit. So in etwa? Curtis Newton ↯ 16:13, 15. Jan. 2009 (CET)

Danke für die Steilvorlage: „Being C++ developers, these people naturally wrote their first C# code in a style that very much resembled C++ […]“ - Das hat ja nun wahrlich nur mit den Quellcodeformatierungsangewohnheiten der Entwickler zu tun, aber nichts mit konzeptionellen Gemeinsamkeiten bzw. Einflüssen. --Succu 16:25, 15. Jan. 2009 (CET)

Welches Schweinerl hättens denn gern? ;-)

[1] [2] [3]

Curtis Newton ↯ 17:01, 15. Jan. 2009 (CET)

Schwein 1 führt im Gegensatz zu den anderen ein Zitat an, die auf die - oh Wunder - Inspiration durch C und C++ hinweist. Ich glaube ich muß dringend in der C-Infobox nachtragen dass C auf Clipper einen nachhaltigen Einfluss hatte. Ich bin gespannt auf deine „Schweinerei“ zu PHP... Den Sinn (in der Infobox) sehe ich allerdings immer noch nicht, da jede neue Programmiersprache zwangsläufig von ihren ähnlichen Vorläufern beeinflusst ist. Die aktuellen experimentellen Sprachen im .Net-Umfeld sind dafür ein gutes Beispiel. Gruß --Succu 17:27, 15. Jan. 2009 (CET)

Du hast sicher Recht, dass im Umfeld von C, C++, C# und Java die neueren von den älteren Sprachen beeinflusst werden. Aber wenn man mal andere Sprachen anschaut, dann sind die Beziehungen doch spannende. schau dir zum Beispiel mal [4] den Stammbaum der Programmiersprachen (alternativ auch [5]) an. Dass Fortran quasi unbeeinflusst bleibt und Smalltalk so viele beeinflusst hat, ist doch wichtig. Wobei die Relation "verwandt" sicher subjektiv ist... --LeClochard 01:04, 17. Jan. 2009 (CET)

Interessante Darstellung, die ich in dieser Form sogar nachvollziehen kann, da ich mit vielleicht der Hälfte der Sprachen schon mal mehr oder weniger engen Kontakt hatte. Gruß --Succu 07:49, 17. Jan. 2009 (CET)

Wenn man hier so mitliest könnte man meinen, die Zäh Plus Plus Infobox sei das wichtigste Problem dieser Welt. Kriegt Euch mal wieder ein, Freunde "unserer" Sprache. HaTe 09:29, 23. Jan. 2009 (CET)

Es ist doch alles in Ordnung, wir unterhalten uns doch drueber. Und in Bezug zum Artikel ist die Infobox auch derzeit das wichtigste Problem. Also ich sehe hier in letzter Zeit keine Unfreundlichkeiten. Curtis Newton ↯ 17:57, 23. Jan. 2009 (CET)

Einleitungskasten dieser Diskussionsseite

Wir sollten einen erweiterten Einleitungskasten auf diese Diskussionseite setzen, in dem wir

• auf das Hallo Welt hinweisen
• auf den Konsens zur Infobox hinweisen sobald die Abstimmung abgeschlossen ist

damit hier nicht jedesmal die selben Diskussionen mit Hinweis auf immer die selben Archivbeiträge kommen.

Vll. sollten wir Curtis' Vorschlag hier von den 5 Tagen warten vor einer Änderung ebenfalls gleich einarbeiten, falls es keine Einwände gibt

Meinungen? -- Steef ³⁸⁹ 14:24, 14. Jan. 2009 (CET)

Gute Idee. Dieser Artikel hier scheint seine eigene Dynamik zu haben, das dürfte eine eigene, angepasst Box rechtfertigen. Gruß, norro ^wdw 14:39, 14. Jan. 2009 (CET)

Ich bau dann mal die Box und Stelle sie ein --Steef ³⁸⁹ 00:24, 23. Jan. 2009 (CET)

So, hab mal nen Anfang gemacht. Man könnte natürlich auch die Kästen zusammenfassen und einen großen machen. Freiwillige vor.^^ --Steef ³⁸⁹ 14:37, 25. Jan. 2009 (CET)

Ich habs etwas komprimiert. --norro ^wdw 15:18, 25. Jan. 2009 (CET)

Wichtige Implementierungen

C++ Builder ist die unwichtigste Implementierung und sollte daher nicht an erster Stelle stehen, will daran jemand zweifeln? Desweiteren ist die Formatierung so unübersichtlich, wenn mitten im Namen der einzelnen Listenelemente gebrochen wird. Muss man hier wegen jedem Scheiß um Erlaubnis fragen? --91.47.220.67 14:26, 10. Feb. 2009 (CET)

Ja, da die Infobox in der Vergangenheit ein sehr sensibles Thema war. Sie war Ursache mehrerer Editkriege. Daher sollte jede Änderung an der Infobox vorher hier angekündigt werden (siehe auch oben auf dieser Seite). Die derzeitige Reihenfolge ist alphabetisch und nicht nach der Relevanz. Curtis Newton ↯ 15:01, 10. Feb. 2009 (CET)

Und die Formatierung?--91.47.220.67 15:21, 10. Feb. 2009 (CET)

Aussprache

Lautschrift für "C" und "C++" fehlt. (nicht signierter Beitrag von 85.176.240.46 (Diskussion | Beiträge) 22:12, 8. Mai 2009 (CEST))

imho irrelevant. die einzelnen zeichen werden einfach deutsch oder englisch buchstabiert. -- seth 18:32, 9. Mai 2009 (CEST)

Mich interessiert die Betonung von C++. Gibt es da wohl einen Standard? Spontan fallen mir vier Variationen ein: Betonung auf einen der drei Zeichen ("C" | "+" | "+") oder monotone Aussprache. Traute Meyer 20:22, 9. Mai 2009 (CEST)

Neuer Punkt bei Literatur

Ich habe neuen Punkt bei Literatur hinzugefügt weil: Learn C++ from the Ground Up ist klar und gut strukturiert geschrieben. Gerade für Anfänger empfiehlt es sich, da hier wirklich keinerlei Vorwissen verlangt wird. Trotzdem werden auch komplexe Dinge hier nachvollziebar erläutert. Dazu kommt zu fast jedem Abschnitt ein kompletter Quelltext, der den Inhalt nocheinmal deutlich werden lässt. Außerdem kann das Buch auch von erfahrenen Programmierern als Referenz genutzt werden. Moerschinesisch 16:05, 3. Jun. 2009 (CEST)

Finde ich nicht sinnvell. Erstens haben wir schon mehr als 5 Bücher, zweitens auch noch falsche Sprache. Curtis Newton ↯ 16:09, 3. Jun. 2009 (CEST)

abschnitt ueber umsetzung der programmierung

zu [6] (und den beiden edits davor):
der geloeschte abschnitt beschreibt zwar teilweise absolute eigenschaften, die ich c++ nicht absprechen will, jedoch setzt er es jeweils in ein unbestimmtes verhaeltnis, was letztlich in sinnlosen aussagen endet.
was soll z.b. "verhältnismäßig lange[...] Einarbeitungszeiten" bedeuten? im verhaeltnis zu was denn?
oder was soll "Außerdem wird die Verwendung von Programmierrichtlinien [...] mehr als in anderen Sprachen angeraten", bedeuten? dass in anderen sprachen nicht so sehr auf die einhaltung von standards gepocht wird? das waere kaese.
auch die restlichen aussagen waren/sind imho zu allgemein, als dass man nuetzliche informationen dort herausziehen koennte. die loeschung des abschnittes fand ich zwar irgendwie nicht so geil, aber die wiederherstellung eines teils davon noch weniger. ;-) -- seth 21:20, 20. Jun. 2009 (CEST)

Sehe ich sehr ähnlich --Bitsandbytes 21:41, 20. Jun. 2009 (CEST)

wenn keine antworten mehr kommen, nehme ich den abschnitt demnaechst wieder raus. rein sollte er dann erst wieder, wenn er ueberarbeitet wurde. -- seth 21:13, 29. Jun. 2009 (CEST)

Den Code vereinfachen

herverschoben aus dem archiv, da falsch platziert. -- seth 21:09, 29. Jun. 2009 (CEST)
Mal so ganz nebenbei: Einfacher wäre es so:

1. include <iostream>
2. include <ostream>

int main() {

   std::cout;
   std::endl;
   cout << "Hallo Welt!" << endl;

}

Das lohnt sich zwar nur, wenn es mehrere Male dazu kommt, dass cout und endl benutzt werden, aber ich denke, es wäre wichtig, das mal zu erwähnen (nicht signierter Beitrag von 93.204.255.95 (Diskussion | Beiträge) 14:23, 28. Jun. 2009 (CEST))

Was ist so schlimm daran immer ein std:: zu tippen? Ich gehöre zu den Programmierern die lieber immer std:: tippen als in komplexeren Projekten Fehler zu produzieren, weil der Namespace nicht klar zuzuordnen ist. Hier ist zumindest Vorsicht geboten. Dazu gibt es auch einige Veröffentlichungen die genau das aussagen. Ich finde die Idee, dass Hallo Welt! Beispiel dahingehend zu ändern daher schlecht. So wie es ist ist es gut. Und an dieser Stelle zu erwähnen, dass man den Code auch vereinfachen kann indem man bestimmte using-Deklarationen verwendet, ist m.E. Fehl am Platze, es geht um ein einfaches Beispiel um den Syntax der Sprache zu zeigen. --Morl99 17:37, 28. Jul. 2009 (CEST)

Also wenn ich in Java jeden Namespace immer Ausschreiben müsste hätte ich ja bei einigen Programmen allein 5 Seiten nur für eben diese. Ich würde sagen es macht schon Sinn ein kleines "using namespace std;" einzufügen. Wird so glaube ich auch in allen gängigen Lehrbüchern gemacht. Zumal Programmierer doch auch nach dem Prinzip der Faulheit handeln ;D

--Noxious - Unterwegs im Auftrag des Hirn. 20:34, 29. Jul. 2009 (CEST)

Es geht hier um ein Hello-World-Programm. Das sollte einfach gehalten sein, das heißt auch, dass es mit so wenig Sprachkonstrukten wie möglich auskommen sollte. Und eine using-Direktive ist halt ein weiteres Sprachkonstrukt, und zwar eines, das in einem Hello-World-Programm noch gar nicht benötigt wird. Zudem ist es recht aufwändig, einem Neuling sauber und exakt die Bedeutung und Auswirkungen dieser Direktive zu erklären, ohne erst gaaaanz weit ausholen zu müssen. Und, nein, ein "Schreibs halt immer hin, das mach ich auch so" ist keine Erklärung. --RokerHRO 07:31, 30. Jul. 2009 (CEST)

Ich schliesse mich meinen Vorredner hier vollumfänglich an --Bitsandbytes 07:34, 30. Jul. 2009 (CEST)

Ich schliesse mich meinen Vorredner hier vollumfänglich an --Curtis Newton ↯ 07:52, 30. Jul. 2009 (CEST)

Keine "Concepts" für C++0x

Quelle: http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441 (nicht signierter Beitrag von 84.162.228.196 (Diskussion | Beiträge) 18:23, 22. Jul 2009 (CEST))

Concepts

Zum einen ist der ConceptGCC nicht wie im artikel angegeben ein testbed für diverse verbesserungen an der sprache, sondern nur für eine: concepts. Und zweitens sind concepts seit einigen wochen raus, wer will lese das bitte in den frankfurt2009 meeting minutes nach. (nicht signierter Beitrag von 87.155.84.221 (Diskussion | Beiträge) 21:47, 16. Aug. 2009 (CEST))

C++ hat beeinflusst

• D

Wenn man die Specs und FAQ usw. von D von digitalmars.com so liest, schienen sie eindeutig ein "besseres C++" entwickeln zu wollen, jedenfalls vergleichen sie selbst ihr D ständig mit C++. Vielleicht findet man da eine belastbarere Quelle? --RokerHRO 21:47, 14. Sep. 2008 (CEST)

iostream

Dass <ostream> benötigt wird, steht ja derzeit nicht zur Diskussion. <iostream> ist für das Beispiel allerdings vollkommen unnötig, da nirgends etwas eingelesen werden muss. Der von mir angepasste Code gibt via Comeau keinerlei Fehler aus, nicht mal Warnungen, er scheint also vollkommen in Ordnung zu sein. Ist m.E. auch verständlicher so. (Zumindest kann ich mir nicht erklären, wofür man hier iostream braucht.)
-- Tuxman 23:34, 14. Sep. 2009 (CEST)

In <ostream> wird die Klasse std::ostream deklariert, aber nicht das Object std::cout. Dieses wird im Header <iostream> deklariert. Siehe §27.4 und §27.6 im ISO-C++-Standard. Das ist die Referenz, nicht das, was der Comeau-Compiler implementiert. --RokerHRO 09:00, 15. Sep. 2009 (CEST)

Darüber habe ich auch schon das Gegenteil gelesen:

cout is an object of class ostream that represents the standard output stream.
-- Tuxman 15:15, 15. Sep. 2009 (CEST)

Objekt der Klasse heißt nicht, dass es im selben Header deklariert sein muss. --Steef ³⁸⁹ 16:22, 15. Sep. 2009 (CEST)

Erstens muss ich Steef rechtgeben. Zweitens ist für mich das originale ISO-Dokument die Sprachnorm (oder "Standard", wenn man den englischen Begriff 1:1 übernimmt) und nicht irgendeine Website. --RokerHRO 22:25, 15. Sep. 2009 (CEST)

Wo ist dieses Dokument zu finden?
-- Tuxman 22:38, 15. Sep. 2009 (CEST)

Steht doch im Artikel: C++ ist im ISO-Dokument ISO/IEC 14882:1998 bzw. ISO/IEC 14882:1998 normativ beschrieben. Google danach! Der erste Weblink führt dich zu www.iso.org, wo du ihn für 380 CHF käuflich erwerben kannst. Wenn dir das zu teuer ist, suche eine gescheite (Uni-)Bibliothek in deiner Nähe auf, die haben ihn vielleicht auch auf Papier vorrätig. --RokerHRO 23:46, 15. Sep. 2009 (CEST)

Werde ich tun, bedanke mich herzlich. :-)
-- Tuxman 03:17, 16. Sep. 2009 (CEST)

Nachtrag: Auf der Website des C++-Standardisierungskomitees kann man den aktuellen Draft (=Entwurf) für den neuen C++-Standard (C++0x) kostenlos herunterladen. Der ist zwar - darum ist es ein Draft - z.T. noch mit Fehlern behaftet und taugt daher nicht als Referenz, aber er gibt einen Einblick in den Aufbau und den Schreibstil, in dem solche Sprachstandards gefasst sind. --RokerHRO 09:40, 16. Sep. 2009 (CEST)

(gcc-Implementierung vs. C++ Sprachnorm)

Also, G++ gibt bei mir bei der reinen Verwendung von ostream einen Fehler aus, mit iostream alleine funktioniert es jedoch hervorragend. Ich wäre dementsprechend dafür, nur iostream zu verwenden, da ostream hier keinen Mehrwert bringt und ich auch sonst bisher als Hallo-Weltprogramm von C++ nur die iostream Variante gesehen habe. Darüberhinaus sollen Hallo-Welt-Programme ja minimalistisch sein, was durch das überflüssige ostream IMHO hier nicht mehr gegeben ist. Gruß, Dr. AL. K. Lisch 18:22, 14. Nov. 2009 (CET)

Sag mal, hast Du die Diskussion drüber überhaupt gelesen? Curtis Newton ↯ 19:46, 14. Nov. 2009 (CET)

Doch, deswegen frage ich mich ja, warum immer noch beides genannt wird. Dr. AL. K. Lisch 20:42, 17. Nov. 2009 (CET)

Nein, hast du nicht. Ich schrieb bereits am 15.Sept., warum beide Header nötig sind, incl. Verweis auf die Stelle in der ISO-Norm. Damit war deine Frage beantwortet, bevor du sie gestellt hattest. --RokerHRO 08:38, 18. Nov. 2009 (CET)

Ich will es mal so sagen. In den einen Header wird gesagt, was es ist (die Klasse beschrieben), und im anderen wird es angelegt (Objekt inistanziert oder wie das heißt). Curtis Newton ↯ 08:47, 18. Nov. 2009 (CET)

Nicht ganz.

1) Im Header <ostream> wird die Klasse std::ostream definiert (als Instanziierung des Klassentemplates basic_ostream, aber das nur am Rande), korrekt.

2) Im Header <iostream> werden Objekte dieser Klasse (nämlich std::cout, std::cerr und std::clog) jedoch nur deklariert, nicht definiert! Dies ist möglich, ohne die Definition der Klasse std::ostream zu kennen, es reicht ihre Deklaration. Diese findet sich im Header <iosfwd>, welche von <ostream> auch inkludiert wird. --RokerHRO 09:11, 18. Nov. 2009 (CET)

Es reicht nicht aus eine forward declaration für ostream zu haben (ignorieren wir jetzt alle einfach mal dass ostream eigentlich ein typedef für basic_ostream<char> ist) um std::cout zu deklarieren. Zur deklaration einer variable muss der volle typ ebendieser bereits bekannt sein, da z.b. sizeof(std::cout) definiert sein muss, und das geht nur wenn der typ vollständig bekannt ist. Als ein Beispiel kann auch der folgende auszug aus dem standard dies weiter erläutern (14.6-8, nicht normativ):

      #include <iostream>
     using namespace std;
     template<class T> class Set {
               T* p;
               int cnt;
     public:
               Set();
               Set<T>(const Set<T>&);
               void printall()
               {
                           for (int i = 0; i<cnt; i++)
                                      cout << p[i] << ’\n’;
               }
               // ...
     };
in the example, i is the local variable i declared in printall, cnt is the member cnt declared in Set,
and cout is the standard output stream declared in iostream. However, not every declaration can be
found this way; the resolution of some names must be postponed until the actual template-arguments are
known. For example, even though the name operator<< is known within the definition of
printall() and a declaration of it can be found in <iostream>, the actual declaration of
operator<< needed to print p[i] cannot be known until it is known what type T is (14.6.2). ]

Es gibt noch diverse code beispiele im standard in denen deutlich wird dass für cout nur <iostream> notwendig ist. So sagt auch table 82 (Input/output library summary):

27.3 Standard iostream objects <iostream>

Oder in 27.3 direkt:

27.3 Standard iostream objects
Header <iostream> synopsis
    namespace std {
      extern istream    cin;
      extern ostream    cout;
      extern ostream    cerr;
      extern ostream    clog;
      extern  wistream   wcin;
      extern  wostream   wcout;
      extern  wostream   wcerr;
      extern  wostream   wclog;
    }

Was wiederum zeigt dass ostream an dieser stelle definiert sein muss, denn eine solche extern deklaration hat keinen unterschied in den requirements zur "definedness" eines typs zu einer non-extern.

kleiner nachtrag: <iostream> definiert basic_iostream welches im standard so gefordert wird:

27.6.1.5 Class template basic_iostream                               [lib.iostreamclass]
    namespace std {
       template <class charT, class traits = char_traits<charT> >
       class basic_iostream :
          public basic_istream<charT,traits>,
          public basic_ostream<charT,traits> {
       public:
          // constructor/destructor
          explicit basic_iostream(basic_streambuf<charT,traits>* sb);
          virtual ˜basic_iostream();
       };
    }

Und für die ableitung muss nun wirklich ein ostream vorhanden und bekannt sein. (nicht signierter Beitrag von 217.11.197.10 (Diskussion | Beiträge) 11:35, 27. Nov. 2009 (CET))

Also: std::basic_iostream wird im Header <istream> (siehe §27.6 "Header <istream> synopsis") deklariert und definiert (§27.6.1.5).

Dass es noch einen Header mit Namen <iostream> gibt, ist ein unglücklicher Zufall. Der Header <iostream> deklariert jedenfalls weder die Klasse std::iostream noch Objekte dieser Klasse . --RokerHRO 12:04, 27. Nov. 2009 (CET)

Einfacheres Beispiel

Lieber Anonymous, du hast wieder Unrecht, ein einfaches Beispiel:

 template<class T> class BasicOstream;  // hat nix mit std::basic_ostream zu tun, heißt nur ähnlich
 typedef BasicOstream<char> Ostream;
 
 extern Ostream os; // nur Deklaration, keine Definition!
 
 Ostream& operator<<(Ostream& f, int i);
 
 int moo(int i)
 {
     os << i;  // Deklaration reicht hier völlig aus.
     return i*42;
 }

Dieses Beispiel lässt sich als einzelne Translation unit (TU) problemlos compilieren. Wenn man nun moo() in einem kompletten Programm benutzen will, muss natürlich das Objekt os irgendwo in einer anderen TU definiert sein. In jener TU muss dann die komplette Definition von BasicOstream sichtbar sein. Nicht aber in der TU, die os nur als Referenz benutzt, wie in moo(). Und std::cout und Konsorten werden i.d.R. nur derart benutzt. Anders sieht es aus, wenn man etwa sizeof(std::cout) verwendet, aber das ist doch eher unüblich. --RokerHRO 11:40, 27. Nov. 2009 (CET)

2-3 Mannjahre für export

Das mag ja stimmen, bloß ein wirklich belastbares Argument ist das nicht. So gut wie niemand verwendet export und die Compiler-Entwickler haben bis auf Comeau alle davon Abstand genommen, dieses Feature zu implementieren. Sie haben keine Lust dazu und die Nutzer erwarten es auch nicht. Es ist also eher ein Scheinargument, export ist ein fragwürdiges Extrem (für Trivia) und nicht repräsentativ für den Entwicklungsaufwand. Belastbarer wären Gesamtentwicklungszeiten, Code-Umfang o.ä.
--Chricho 13:52, 14. Okt. 2009 (CEST)

Es ist IMHO eher andersrum, nämlich dass kein C++-Anwender export benutzen kann, weil es kein praxisrelevanter Compiler unterstützt. Mit export ließe sich Template-Code genauso einfach schreiben und sauber zw. Header und Implementierung trennen, wie Nicht-Template-Code. Ich denke schon, dass viele C++-Anwender sich dies wünschen würden. --RokerHRO 16:46, 14. Okt. 2009 (CEST)

export wird vermutlich eh deprecated im neuen C++ Standard [7] --Wikieditoroftoday (disk.) 13:51, 24. Okt. 2009 (CEST)

Laut http://www.intel.com/software/products/compilers/docs/clin/main_cls/bldaps_cls/cppug_ccl/bldaps_exp_temp_cl.htm unterstützt intel mittlerweile export. Auch digital mars implementiert mittlerweile meines wissens export template, allerdings kann ich just in diesem moment die doku dazu nicht finden. Btw. ja, export wird deprecated hat mir das committee geflüstert... (nicht signierter Beitrag von 217.11.197.10 (Diskussion | Beiträge) 11:35, 27. Nov. 2009 (CET))

Hallo-Welt Programm

Hallo,
da der Artikel halbgesperrt ist, traue ich mich nicht, irgendwas daran zu ändern. Ist das #include <ostream> nicht überflüssig? --Kamelchen 18:16, 13. Dez. 2009 (CET)

Kommt vermutlich auf den konkreten Compiler an. Das hier dürfte immer funktionieren (und dem Standard entsprechen), je nach Implementation der Bibliotheken könnte es anders auch gehen. --PaterMcFly Diskussion ^Beiträge 19:08, 13. Dez. 2009 (CET)

Es gibt keinen Compiler (so weit ich weiß), der das so nicht akzeptieren würde.

Was natürlich optimal wäre:

    #include <iostream>
    #ifndef _OSTREAM_
    #include <ostream>
    #endif

Aber das ist dann eben schon wieder ein Spezialfall...
-- Tuxman 19:13, 13. Dez. 2009 (CET)

Warum sollte das optimal sein? Was soll _OSTREAM_ überhaupt bedeuten? Includeguards? Keine Sorge, darum kümmert sich ostream schon selbst... --Wikieditoroftoday (disk.) 00:52, 17. Dez. 2009 (CET)

Kann es nicht, wenn es nicht eingebunden wird.
-- Tuxman 05:49, 17. Dez. 2009 (CET)

Was kann es nicht und was soll nun der Sinn von dem Konstrukt sein? --Wikieditoroftoday (disk.) 01:59, 19. Dez. 2009 (CET)

Nein, es ist nicht überflüssig, sondern wird vom Standard verlangt. Siehe auch hier und hier. Gruß --Steef ³⁸⁹ 20:01, 13. Dez. 2009 (CET)

- 2010 -

Historie

Hallo, ich habe bei der Suche nach dem Glockenspiel-Compiler eine recht gute Seite gefunden mit historischen Informationen, sie ist allerdings auf Englisch : http://www.softwarepreservation.com/projects/c_plus_plus/ und zudem noch eine "Fremd-Wiki". Kann man sowas hier auch sinnvoll verwenden? -- 87.79.100.243 23:40, 1. Feb. 2010 (CET)

Rückgabewert.

Main() ist im Beispiel vom Typ int. Folglich muss die Funktion doch einen Wert zurückliefern (?). Aber da steht kein "return (...);"

Ich würde lieber ein Hallo Welt Programm in C und C++ anzeigen. Damit können sprachliche Unterschiede deutlich gemacht werden. (nicht signierter Beitrag von Johannes Schneider (Diskussion | Beiträge) 22:51, 5. Feb. 2010 (CET))

1. Der C++-Standard erlaubt, warum auch immer, dass main(), als einzige Funktion mit int-Rückgabewert, ohne return-Anweisung verlassen werden kann. In dem Falle wird 0 zurückgegeben.

2. Es gibt meines Wissens schon eine Liste der Hello-World-Programme hier oder bei Wikibooks...

--RokerHRO 23:21, 5. Feb. 2010 (CET)

Wenn beides unterstützt wird, sehe ich keinen Anlass, es wegzulassen. Verwirrt nur. --Tux als IP (nicht signierter Beitrag von 93.204.137.174 (Diskussion | Beiträge) 04:03, 6. Feb. 2010 (CET))

Die Diskussion zum Thema return gab es bereits. Eine Liste vieler Hallo-Welt-Programme findest du unter Liste von Hallo-Welt-Programmen/Programmiersprachen. --Steef ³⁸⁹ 12:32, 6. Feb. 2010 (CET)

In der verlinkten Diskussion wurde dieses Thema ebenfalls nicht ausreichend diskutiert. Einer sagt so, der andere sagt so, keine Einigung. Ich schließe mich dort der Meinung der IP an.--93.204.129.89 17:28, 6. Feb. 2010 (CET)

Schließe mich ebenso an, ein return wird zwar nicht vom Standard verlangt, gehört dort aber als guter Stil trotzdem hin. -- Grumbel45 17:56, 6. Feb. 2010 (CET)

Guter Stil ist Ansichtssache. Führen wir doch eine Abstimmung durch, hat ja damals bei der Infobox auch funktioniert. --Steef ³⁸⁹ 21:02, 6. Feb. 2010 (CET)

Der "main" return-Wert ist evt. für den Aufruferprozess nuetzlich. Ich habe ein "return 0;" [8] hinzugefuegt. --Traute Meyer

Was genau hast du an "wenn main() ohne return-Anweisung verlassen wird, ist das identisch zu return 0;" nicht verstanden?

Wir können es auch gerne nochmal im ISO-C++-Standard nachlesen, Kapitel 3.6.1 Absatz 5: „If control reaches the end of main without encountering a return statement, the effect is that of executing return 0;“

Der Vaterprozess bekommt also in jedem Falle einen definierten Rückgabewert vom Kindprogramm. --RokerHRO 21:53, 6. Feb. 2010 (CET)

Wo steht in diesem Standard, dass der Rückgabewert also nicht explizit deklariert werden darf?
-- Tuxman 00:33, 21. Feb. 2010 (CET)

Nirgends, hat ja auch niemand behauptet. --Steef ³⁸⁹ 01:40, 21. Feb. 2010 (CET)

Ich hatte RokerHRO so verstanden. :)
-- Tuxman 04:30, 21. Feb. 2010 (CET)

Schwach typisiert?!!

C++ ist für viele der Inbegriff einer stark typisierten Sprache. Mag sein, dass es Sprachen gibt, die noch stärker typisiert sind, wie Ada. Aber es schwach typisierte Sprache spielen in einer ganz anderen Liga. In Sprachen wie Perl oder PHP kann man "1.3" + 1 rechnen, in C++ ergibt das einen Typfehler... Also für mich ist das Theoriefindung vom feinsten, dann lieber die Type-Disziplin ganz weglassen... --hasta luego 16:43, 27. Okt. 2010 (CEST)

Ich würds auch eher weglassen. C++ kennt implizite Casts, mit denen die Operanden "passend" gemacht werden usw. und das führt auch oft zu dubiosen, schwer zu findenden Bugs. Von einer Sprache mit "starker Typisierung" würde ich sowas nicht erwarten. Für einen Umsteiger aus einer Skriptsprache mag C++ da schon recht streng sein, das bezweifele ich gar nicht. :-) --RokerHRO 20:54, 27. Okt. 2010 (CEST)

Ich hab mal irgendwo nen Blogeintrag gelesen, wo der Typ meinte, dass wenn man eine Sprache bis ans Limit stark typisieren würde, sie unbenutzbar wird. Alleine schon int j(int i, int j) { return i + j; } ist ein impliziter Cast, wenn man so will. Denn i+j kann im Allgemeinen nur durch einen long abgefangen werden, damit es nicht zu einem Überlauf kommt für große Werte. Das kann man auch nicht auf den "+"-Operator schieben, den kann man für Basistypen schließlich nicht überladen. Noch schlimmer, mit maximal starker Typisierung wäre die Addition von zwei longs ein wirkliches Problem, also nicht durchführbar, es sei denn man hat arbitrary precision-Typen. Ich werde da bei Gelegenheit mal genauer recherchieren. :P --hasta luego 02:00, 30. Okt. 2010 (CEST)

Der Typ mit dem Blog hat unrecht und zwar aus zweierlei Gründen: Zum einen muss ein long keinen größeren Wertebereich haben als ein int (Auf den meisten 32-Bit-Plattformen sind beide Datentypen 32 Bit groß). Zum anderen definiert die ISO-C++-Norm klar, dass die Summe zweier int stets wieder ein int ist. Arithmetische Überläufe erzeugen dabei "undefined behavior". Bei unsigned ist definiert, dass eine Modulo-Arithmetik durchgeführt wird (modulo 2³²-1 bei 32-bit-unsigned), somit gibt es dort per Definition keine Überläufe. Mit strenger Typisierung hat das aber beides nichts zu tun. --RokerHRO 11:55, 30. Okt. 2010 (CEST)

short i = 0x0fff // = 32.767;

short j = 0x0001 // = 1;

short test = j + i // = 0x1000 = -32.768;

Wo bleibt hier der Cast? Bei ints oder longs verhält es sich genauso (also zumindest auf Systemnachen Programmiersprachen) Bei 0xffff + 0x0001 = 0x0000 fällt einfach der Übertrag weg (Der zwar abgespeichert werden könnte, aber man kann darauf niciht zugreifen). Das ist jedoch sehr technisch begründet und man sollte sich hierbei die Additionsgatter mal ansehen.--Karolherbst 13:58, 1. Nov. 2010 (CET)

In C++ kann man sehr hübsch zu einer bliebigen Klasse casten. Zuerst Cast auf einen void-Pointer, dann Cast zu dem was man haben möchte. Man kann auch den reinterpret_cast verwenden, damit umgeht man den Cast über void*. Das ist für mich schwach typisiert. Stark typisierte Sprachen würden einen Runtimefehler bekommen oder eine Exception schmeißen. In C++ kommt der Runtimefehler erst dann, wenn man auf Null-Pointer zugreift (bei Zugriffen auf Methoden oder Member). Auch kann ohne Probleme von static auf non-static gecastet werden. Sollte bei einer starken Typisierung auch nicht gehen. In diesem Sinne ist selbst Java stärker typisiert, das schmeißt immer diese ClassCastExceptions. (Oder AS oder wie die ganzen Mode Sprachen heißen.) --Karolherbst 13:48, 1. Nov. 2010 (CET)

Dieses Herumkonvertieren ist aber - in den allermeisten Fällen - undefiniertes Verhalten, d.h. nur weil etwas "syntaktisch richtig" aussieht, ist es noch lange kein C++-Programm. C++ ist nicht die am stärksten typisierte Sprache, aber sie ist stark typisiert. Allerdings stellt sie ihren Benutzern Möglichkeiten zur Verfügung, bestimmte Dinge zu umgehen. Aber es beeinflusst die Eigenschaft der Sprache, stark typisiert zu sein, doch nicht, wenn ein Benutzer bestimmte Dinge umgehen kann! Die Bereiche, in denen eine Typisierung wichtig ist, ist bei *impliziten* Konvertierungen, etwa bei Funktionsüberladungen oder der Auflösung von Template-Argumenten (etwa bei Spezialisierungen). Das Argument, dass etwa in Java eine Exception geworfen wird, würde man sonst auch als "schwach typisiert" einordnen können - denn man kann's ja machen, solange man sich um die Exception kümmert. Das Argument mit static und non-static verstehe ich nicht, denn (ich nehme an, es geht um statische Klassenvariablen) das ist eben kein eigener Typ, sondern eine ganz normale globale Variable, die man wahrscheinlich in den allermeisten Fällen in C++ besser in einen eigenen Namensraum anstatt in eine Klasse geben sollte. --178.112.106.171 16:12, 30. Jun. 2011 (CEST)

*Zustimm* Oft benutze ich für die Numerik vorinstallierte (vendor specific implementation) Fortran Bibliotheken, und freue mich dann sehr das ein boost::ublas::matrix Objekt sich wunderbar als double* (bzw. DOUBLE PRECISION) macht wenn man aufpasst das die Bibliothek column-major erwartet. Damit erschlägt man auch die (von meiner Community dauernd vorgebrachten) "nimm doch Fortran, das ist schneller" Sprüche. Ein POSIX-Standard dlsym()(en:Dynamic loading) gibt uns auch ein void* zurück, und wenn wir es ordentlich gemacht haben können wir damit ein Objekt zu einer passenden Basisklasse casten und ganz schicke austauschbare Module machen. Die Typisierung ist also wirklich schwach in dem Sinne, dass C++ Programmierer sich darauf verlassen können, das ein Pointer irgendwo in den Speicher zeigt und es in seiner Macht steht, die dahinter liegenden Bits zu interpretieren wie er es für richtig hält. Die Typisierung ist zumindest genauso schwach wie bei C und dort gibts z.B. wunderschönen Integer Hokuspokus auf Fließkommazahlen (en:Fast inverse square root geht natürlich mit C++ genauso). Diese Eigenschaft von C++ ist für mich ein echter Vorteil gegenüber Java und C# (also Interoperabilität mit _vorinstallierten_ {mal angenommen ich bin nicht root auf dem Supercomputer ;-) } Fortran-Libs). (nicht signierter Beitrag von Evxxvi (Diskussion | Beiträge) 01:39, 3. Jan. 2011 (CET))

- 2011 -

Kategorie Programmiersprache hinzufügen

In Quelltext der Seite steht "Kategorie:Programmiersprache bitte NICHT hinzufügen, Programmiersprache C++ ist die richtige (Unter-)Kategorie". Ich will gar nicht bestreiten, dass Programmiersprache C++ ist die richtige (Unter-)Kategorie ist, aber deswegen ist Kategorie Programmiersprache doch nicht automatisch falsch. Im Gegenteil, wenn man nicht zusätzlich Kategorie Programmiersprache aufnimmt, fehlt C++ - aus meiner Sicht fälschlich - auf der Seite Kategorie:Programmiersprache. Deshalb plädiere ich dafür die Kategorie Programmiersprache hinzuzufügen. Gibt es Einwände? Wenn ja, bitte begründen. -- MinorChanges 17:36, 18. Feb. 2011 (CET)

Bitte mache dich mit folgenden Richtlinien vertraut: Wikipedia:Kategorien --188.100.196.207 17:42, 18. Feb. 2011 (CET)

Habe ich jetzt getan. Ich halte es jedoch weiterhin für sinnvoll bzw. sogar erforderlich, dass die Hauptartikel zu den Programmiersprachen - konkret dieser Artikel über C++ - zusätzlich in die Kategorie Programmiersprache aufgenommen werden. Sonst fehlen ausgerechnet die Programmiersprachen auf der Seite Kategorie:Programmiersprache die so wichtig sind, dass sie ihre eigene Unterkategorie haben. -- MinorChanges 14:21, 19. Feb. 2011 (CET)

Funktionale Programmierung in C++?

Unter Paradigmen steht, dass man in C++ funktional Programmieren kann. Ist das ein Fehler oder kann mir das jemand erklären? -- Kockster 21:51, 18. Feb. 2011 (CET)

[9] hier kam's her. Spätestens mit der Einführung von Lambda-Ausdrücken in C++0x mitsamt Closures über lokale Variablen (wahlweise als Referenz oder Kopie) trifft das ja einigermaßen zu. Ohne GC sind aber Funktionen, die Funktionen zurückgeben (auch ein wichtiger Bestandteil von FP), nur ziemlich begrenzt einsetzbar. Ich würde also sagen, ein Bisschen FP geht, aber es ist lange nicht so vollständig, wie man zum Beispiel in C objektorientiert programmieren kann (wenn man voraussetzt, dass C++ wirklich objektorientiert ist). Und im C-Artikel steht auch nicht, C sei objektorientiert. --Daniel5Ko 23:26, 18. Feb. 2011 (CET)

Ich denke, solche Aussagen sind immer mit Vorsicht zu genießen, so lange es keine harten und allgemein akzeptierten Kriterien gibt, nach denen man (be)urteilen kann, ob eine Sprache dieses oder jenes Programmier-Paradigma "ermöglicht/unterstützt/erfordert". Somit sind solche Aussagen weich oder schwammig und lassen bestenfalls Abstufungen zu wie „Programmiersprache X unterstützt das Y-Paradigma besser als die Sprache Z, aus der sie hervorgegangen ist, da sie Features F₁ und F₂ im Sprachkern unterstützt, die in Z nur umständlich über Bibliotheksfunktionen nachgebildet werden können[…]“.

Welche Features sind denn deiner Meinung nach nötig, damit eine Sprache das funktionale Programmieren ermöglicht oder gar unterstützt? --RokerHRO 00:17, 19. Feb. 2011 (CET)

Dies ist 'ne bessere Antwort als meine, da ich zuerst verteidige, und am Ende doch dagegen argumentiere, was vielleicht ein wenig verwirrt. Aber so ist das nunmal mit solchen albernenen Begriffen wie "Programmierparadigma" :) --Daniel5Ko 00:46, 19. Feb. 2011 (CET)

Ich wusste bis eben gar nicht, dass es Lambda-Ausdrücke in C++ gibt. Für mich gehört zu einer funktionalen Programmiersprache dazu, dass Funktionen wie Objekte behandelt werden können. Das heißt, man sollte Funktionen als Funktionsargument und als Rückgabewert einsetzen können. Ganz wichtig ist meiner Meinung nach auch, dass Funktionen zur Laufzeit erzeugt werden können. Man kann sich zum Beispiel vorstellen, dass eine Funktion z zwei Funktionen f und g als Parameter nimmt und eine Funktion zurückgibt, die f und g hintereinander ausführt. Das heißt, wenn man h = z(f, g) ausführt, dann wären h(x) und g(f(x)) äquivalent. Ist so etwas in C++ möglich? -- Kockster 14:52, 19. Feb. 2011 (CET)

Auf jeden Fall. Wenn man nicht zu pedantisch ist. z könnte ein Objekt zurückgeben, dessen Klasse den ()-Operator geeignet überladen hat. z füllt die Daten des zurückgegebenen Objekts so aus, dass dieses Zugriff auf f und g hat. Aber wie gesagt, ohne GC wird's komisch und/oder ineffizient. --Daniel5Ko 17:46, 19. Feb. 2011 (CET)

Naja, man kann in C und in C++ Funktionen als (Funktions-)Zeiger an andere Funktionen übergeben und eine Funktion kann auch einen Funktionszeiger zurückgeben. Sowas ist in der Unix-C-API auch gang und gäbe. C++ abstrahiert das Konzept des Funktionszeigers noch ein Stück weiter und kennt sogenannte Funktoren (engl. 'functors'), welche eben „richtige” Objekte (mit Lebensdauer, internem Zustand usw.) sind.

Funktionen "zur Laufzeit definieren" ist weder in C noch in C++ möglich. Man kann sich sowas aber (in C nur mühsam, in C++ dank Operatorüberladung deutlich eleganter) selbst zusammenbauen (oder eine fertige Library dafür nehmen, z.B. Boost.Lambda), das sich aus Anwendersicht praktisch so verhält. Und je nach Implementierung ist es auch schneller als das, was die meisten „typischen funktionalen Programmiersprachen“ treiben.

Die Lambda-Expressions, die es mit C++0x geben wird, sind dafür eigentlich nur "syntactic sugar", allerdings so gut, dass damit das Arbeiten mit Lambda-Expressions schon deutlich komfortabler geworden ist. Bibliotheken wie Boost.Lambda zeigen aber, dass sowas im bisherigen C++ auch schon machbar war. --RokerHRO 20:08, 19. Feb. 2011 (CET)

Funktionale Programmierung heisst ohne Nebenwirkungen. Funktionsobjekte, Funktionszeiger, Lambdas, zur Laufzeit definierte Funktionen, das alles erfüllt diese Bedingung nicht. Der einzige Teil von C++, der funktional ist, ist die Templatemetaprogrammierung (TMP). Bevor wir dies als Rechtfertigung für einen so prominenten Eintrag sehen, sei erwähnt, dass C++ ausserdem noch prozedural und modular ist (steht weiter unten). Zudem habt ihr generativ vergessen. Also bitte: Wenn funktional, dann unten mit Hinweis auf TMP. -- 109.169.70.56 21:36, 30. Apr. 2011 (CEST)

Man kann natürlich auch in C++ nebenwirkungsfrei programmieren. Ohne HOFs und damit Lambdas (und GC) ist das relativ unpraktisch, und ohne von der Spezifikation geforderte TCO nicht uneingeschränkt durchhaltbar.

Zudem: Lisper hätten bestimmt etwas dagegen, Nebenwirkungsfreiheitserzwingung zu fordern, damit eine Sprache als funktional gelten darf.

Und was ist eigentlich mit D 2 und seinem pure-Modifier für Funktionen? Ist D nun funktional, weil es Nebenwirkungsfreiheitserzwingung ermöglicht? Oder doch nicht, weil man den Modifier weglassen kann, oder weil TCO nicht generell gemacht wird?

Alles nicht so einfach. Man hätte ungefähr folgende Optionen, um eine irgendwie geartete Einheitlichkeit herzustellen:

• funktional bei D und objektorientiert bei C rein,
• funktional bei C++ raus,
• funktional bei C++ und Lisp raus,
• viele weitere Kombinationen.
• Am sinnvollsten aus meiner Sicht, wie weiter oben schon bemerkt: Begriff Programmierparadigma streichen (vielleicht auch erstmal seine Erwähnung in Programmiersprachen-Info-Boxen)! Das ist alles unterdefinierter, unhaltbarer Quatsch, der niemandem wirklich hilft, außer gelegentlich, wie zum Beispiel OO-best-practices-Buch-Schreibern und -Beratern sowie einfallslosen Informatik-Lehrern, die nicht wissen, was sie ihren Schülern an sinnvollem Wissen vermitteln könnten. --Daniel5Ko 00:41, 4. Mai 2011 (CEST)

Hallo-Welt-Beispiel

Hallo! Im Hello-World-Beispiel fehlt ein `return 0`, da main() den Return-Typ int hat (ansonsten sollte der Compiler auch eine Warnung ausspucken). Ist jemand anderer Meinung?

#include <iostream>
#include <ostream>

int main() {
    std::cout << "Hello world!" << std::endl;
    return 0;
}

– Gorlingor (Diskussion) 12:56, 7. Jul. 2011 (CEST)

Ja der C++-Standard ist anderer Meinung, siehe hier. Gruß --Steef ³⁸⁹ 14:24, 7. Jul. 2011 (CEST)

Jo, hab ich dann auch gesehen. Aber ist es nicht verwirrend für die, die den C++-Standard nicht kennen, dass die main()-Funktion mit Returntyp int nichts zurückgibt (zumindest nicht offensichtlich)? – Gorlingor (Diskussion) 15:15, 7. Jul. 2011 (CEST)

Wer die Sprache (noch) nicht kennt, macht nix, dann kann man sie lernen. Oder man schaue in ein gescheites Lehrbuch. Wenn dieser Fakt in dem Lehrbuch nicht erwähnt wird, dann bringe man es zum Altpapier und kaufe ein gescheites. --20:53, 7. Jul. 2011 (CEST)

Das ist so auch nicht richtig. Selbstverständlich gibt main() etwas zurück. Wenn man nichts explizit angibt, allerdings automatisch 0. Tuxman 12:16, 8. Jul. 2011 (CEST)

Man beachte das "zumindest nicht offensichtlich". – Gorlingor (Diskussion) 15:57, 8. Jul. 2011 (CEST)

Pah, niemals! Tuxman 20:39, 8. Jul. 2011 (CEST)

Braucht man überhaupt den iostream Header? cout ist ja ne ostream Instanz, sollte daher in ostream definiert werden? [ist ja extern] -- Phiarc 23:57, 20. Okt. 2011 (CEST)

Ok, zumindest beim GCC ists in der iostream drin. Aber warum inkludiert man dann explizit ostream, zur Definition als extern muss ja für gewöhnlich die Definition der Klasse bekannt sein -- Phiarc 00:00, 21. Okt. 2011 (CEST)

Du verwechselst gerade Implementierung mit Standard. Es gibt meines Wissens keinen Compiler, in dem iostream ostream nicht einbindet, aber der Standard schreibt das nunmal nicht so vor.^{<ref group="Anmerkung">Oder wurde das inzwischen mit dem Neuen geändert?</ref>}. Und da std::endl in ostream definiert ist und es nicht sicher ist, dass dieser bereits eingebunden ist, muss ostream auch angegeben werden. Gruß --Steef ³⁸⁹ 00:23, 21. Okt. 2011 (CEST)

Also in diversen Drafts ist das schon recht lange drin. Siehe z.B. hier: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf Punkt 27.4 [iostream.objects]

Keine Ahnung, ob das nun wirklich zum neuen offiziellen Standard durchgeschlagen ist (€-Barriere), aber es scheint doch sehr wahrscheinlich. --Daniel5Ko 01:56, 21. Okt. 2011 (CEST)

Quellen zur Veröffentlichung von C++11

Mal ein paar Quellen zu C++11, um damit vielleicht den Artikel noch etwas zu ergänzen.

• Neue C++-Version als ISO/IEC-Standard veröffentlicht – Artikel bei Heise online, vom 11.10.2011
• Programmiersprache: ISO veröffentlicht C++11 – Artikel bei Golem.de, vom 11.10.2011

--92.226.63.250 10:33, 12. Okt. 2011 (CEST)

Puh, wollte ich gestern auch schon ergänzen, aber dann habe ich vergessen, warum ich nochmal den Artikel bearbeiten wollte ... Habs mal ergänzt. Dankeschön. – Gorlingor (Diskussion) 17:54, 12. Okt. 2011 (CEST)

Compiler (Umsetzung)

Es existieren weitere Compiler für C++ die recht Populär und Modern sind: Siehe Clang, ein Frontend für die LLVM. (nicht signierter Beitrag von 178.4.246.64 (Diskussion) 23:41, 26. Okt. 2011 (CEST))

- 2012 -

A-Intellektuelles Programmierer-Milieu, didaktisch absolut unfähig

Unter "Kraftwerk" steht bei wiki wohl, ein Aggregat, das Strom macht, aus Kohle, Atom, Potenzielle Energie des Wassers usw.; Bei "was tut C++?" versagen sie alle, diese verdummten, vereinsamten Einsiedler; Sie sind unfähig, sich vorzustellen, daß einer hier rein kommt u. fragt, was ist überhaupt die Funktion von C++? Was kann man damit machen? Die Dosierung einer Benzinpumpe, je nach Drehzahl u. je nach Datenfluss aus dem Auspuff (Konzentration von NOx, CO, CO2 etc.)?

• Oder einer Nähmaschine sagen, gewisse Muster zu nähen oder die Bevölkerungsexplosion nach zu ahmen, zeilenmässig bei Zugabe von Geburtenrate - Sterberate usw.; Dem Heizölbrenner sagen, wann er brennen u. wann er ausschalten soll- bei Zugabe z.B. der Zimmertemperatur u. der Aussentemperatur?
• Also was? Die blödesten wollen unbedingt Spiele programmieren; also- in was für einer Welt von Unfähigen lebe ich? 11.1.2012, Eco-Ing. (nicht signierter Beitrag von 93.104.43.249 (Diskussion) 15:56, 11. Jan. 2012 (CET))

Könntest du bitte noch einmal ohne Geschwurbel in ein bis zwei Sätzen sagen, was genau dich am Artikel stört und was du verbessert haben willst? --RokerHRO 10:09, 12. Jan. 2012 (CET)

C++AMP

Wohin gehört den nun die Erweiterung? Die Revertbegründung kann ich nicht ganz nachvollziehen. Die Bedeutung von C++AMP ist doch recht offensichtlich. Die Erweiterung soll zumindest für das gleiche gut sein, für was auch OpenCL gut ist, nämlich zum Rechnen auf CPU und GPUs, also heterogenes Computing. Was genau ist an dieser Bedeutung unklar? OpenMP ist in der Tat hier nicht erwähnt, hat aber wie man sieht einen eigenen Artikel. Soll für C++AMP nun auch ein eigener Artikel entstehen oder wie soll das ganze behandelt werden? Zumal die Grafikkartenhersteller mit C++AMP-Kompatibilität werben, so wie auch mit DirectX 11.1-Kompatibilität, obwohl auch letzteres erst mit Windows 8 debütieren wird, aber die Informationen zu DX11.1 und C++AMP müssen jetzt schon irgendwo vorhanden sein, damit man auch weiß, wovon die Graka-Hersteller da reden... --Juri S. 13:21, 5. Feb. 2012 (CET)

Naja, das ist doch eine arge Verzerrung des Artikels, wenn dort irgendwelche brandneue, bislang nicht benutzte, plattformspezifische Produkte beworben werden, nicht jedoch auf die gängigen Standards eingegangen wird. Für C++ mit seinen Verwendungen etc. hat dieses AMP eben bislang überhaupt keine Bedeutung. --Chricho ¹ 13:53, 5. Feb. 2012 (CET)

Kritik

Wie sieht es denn mit der krittischen Betrachtung der Sprache aus? Die Seite [10] biete einiges, dass hier durchaus erwähnt werden könne... --TT (Diskussion) 18:05, 11. Mär. 2012 (CET)

Und warum schreibst du es dann nicht hinein? Abgesehen davon ist die Wikipedia keine Sammlung von Pro- und Kontralisten. Tuxman (Diskussion) 12:19, 12. Mär. 2012 (CET)

C++ hat 'ne große Fangemeinde und ich wollte hier keinen Edit-War entfachen.

In manche Artikel passen Pro- und Kontralisten aber hinein... Ich werde dann mal die wichtigsten Kritikpunkte hineinschreiben. --TT (Diskussion) 14:11, 13. Mär. 2012 (CET)

Abschnitt "Kritik am Sprachdesign"

Ich habe den Abschnitt gelöscht, da es sich um unbelegte Behauptungen handelte, also Theoriefindung. --Sunks (Diskussion) 18:15, 22. Mai 2012 (CEST)

Deine Löschungen erscheinen mir zum Großteil sinnvoll. Einzelne Punkte so in den Vordergrund zu stellen, und das ohne Belege, ist in der Tat TF (auch mit dem Aufwand der Implementierung, da gibt es noch ganz andere Gründe). Und die Erläuterungen zum #include sind wahrlich entbehrlich. Aber wieso hast du Erscheinungsjahr und Implementierungen in der Infobox entfernt? --Chricho ¹ ² 18:32, 22. Mai 2012 (CEST)

Erscheinungsjahr und Implementierung: Aus ganz ähnlichen Gründen. Siehe meine Edit-Kommentare. Falls weiterer Diskussionsbedarf besteht, würde ich dich bitten, einen (oder mehrere) neue Abschnitte auf dieser Diskussionsseite dazu zu beginnen. --Sunks (Diskussion) 15:05, 23. Mai 2012 (CEST)

Ich denke, es passt so. --Chricho ¹ ² 17:43, 23. Mai 2012 (CEST)

vergleich zu anderen sprachen

gudn tach!
die aenderungen [11] habe ich zum grossen teil revertiert, weil sie unbelegt waren. allerdings habe ich die loeschung des abschnittes

Außerdem wird die Verwendung von Programmierrichtlinien aus Gründen der Wartbarkeit und Fehleridentifizierung mehr als in anderen Sprachen angeraten. Demgegenüber ist der Stand vieler Lehrbücher und Lehrveranstaltungen veraltet. Lehrinhalte stimmen oft nicht mit der Realität existierender Compiler überein.

nicht revertiert (der abschnitt ist also weiterhin geloescht), weil nicht belegt wurde, dass das in C++ wirklich grossartig anders ist, als in anderen sprachen. bei z.b. java, python und perl sind auch viele handbuecher veraltet. und zu sauberem code wird auch in allen sprachen immer und immer wieder geraten. -- seth 22:57, 25. Apr. 2012 (CEST)

Belegen kann ich dass auch nur mit meiner Erfahrung. Aber Fakt ist, dass Compiler "anderer Sprachen" wesentlich bessere Fehlermeldungen werfen (können). Insbesondere sobald man Templates verwendet sind die Ausgaben des C++ Compilers im Fehlerfall keine Hilfe mehr. C++ ist auch die einzige mir bekannte Sprache, für die es einen Parser für die Fehlermeldungen des Compilers gibt [12] ... --TT (Diskussion) 11:46, 26. Apr. 2012 (CEST)

gudn tach!

fehlermeldungen sind fuer anfaenger immer kryptisch, in so ziemlicher jeder sprache. je fortgeschrittener man ist, desto eher versteht man die meldungen. das trifft auch schon auf so eigentlich simple sprachen wie LaTeX zu (fuer die LaTeX-fehlermeldungen gibt's uebrigens auch parser). und in jeder sprache gibt's meldungen, die einen in die irre fuehren, in einigen sprachen z.b. falschgesetzte klammern.

templates, die man ja durchaus als eine eigene sprache (tmp) ansehen kann, sind tatsaechlich etwas, dass die ganze sache noch etwas komplizierter macht. c++template-fehlermeldungen sind standardmaessig schlecht lesbar, das ist richtig, und mittels stlfilt kann man sie etwas aufhuebschen. es ist jedoch quark, zu sagen, dass z.b. die gcc-template-fehlermeldungen einem keine hilfe waeren.

tmp ist uebrigens nicht nur in c++ vorhanden, sondern gibt es in aehnlicher form auch in einigen anderen sprachen.

aber so kommen wir vermutlich nicht weiter. was man braeuchte, waeren serioese sprach-vergleiche. -- seth 00:44, 28. Apr. 2012 (CEST)

Da gibt's was altes in meinem BNR. Wurde damals im ANR gelöscht, ich glaube wegen TF bzw. willkürlicher Auswahl der Kriterien, müsste aber nachschauen.

Allgemeine Aussagen zu Fehlermeldungen sind ausserdem schwierig, weil sich hier einzelne C++ Compiler stark unterscheiden. gcc und msvc sind da z.B. sehr stark unterschiedlich. Wenn man aber eine Weile mit dem Compiler gearbeitet hat, lernt man die Macken kennen und weiss dann mit der Zeit, was mit einer bestimmten Meldung wirklich gemeint ist. --PaterMcFly Diskussion ^Beiträge 08:49, 28. Apr. 2012 (CEST)

Stimme seth zu, für eine Aussage "C++ -Fehlermedungen sind schlechter als in anderen (vergleichbaren!) Sprachen" muss ein Beleg da sein, ich bin bisher ganz gut klargekommen mit den Meldungen (mal abgesehen von der "Linkerhölle") ... Und was "Programmierrichtlinien und deren Wichtigkeit" angeht, mag C++ noch etwas daran kranken, das (viel!) früher Byte-sparend programmiert wurde (als Sourcecodes noch auf 360k-Disketten passen mussten), und C++ da wohl immernoch etwas drunter leidet. Aber ohne Belege ~ TF. --arilou (Diskussion) 14:23, 5. Jul. 2012 (CEST)

Literatur

Das Buch C++ Programmierung für Anfänger beschreibt die Grundlagen Programmierung mit C++ leicht verständlich auf wenigen Seiten. Für Anfänger scheint es mir sehr geeignet zu sein. Bisher finden sich hier ja eigentlich keine Bücher für Anfänger. Das sollte man ändern.

Dann aber nicht aus einem BoD-Verlag. Siehe auch WP:LIT. Curtis Newton ↯ 19:06, 7. Mai 2012 (CEST)

Na, blos keine Lern-Bücher hier, davon gibt's Tausende, und jedes ist "irgendwie gut". --arilou (Diskussion) 14:25, 5. Jul. 2012 (CEST)

Infobox - Paradigmen

Ich halte die Liste unter Paradigmen in der Infobox nicht für sinnvoll, denn eine Programmiersprache kann ein so genanntes Programmierparadigma mit mehr oder weniger vielen Sprachmitteln unterstützen, aber ab welchem Grad der Unterstützung soll das betreffende Paradigma in die Liste aufgenommen werden? Wie soll man den Grad der Unterstützung messen? Die Entscheidung für oder gegen eine Aufnahme ist unweigerlich Ermessenssache, also POV. Ein Beispiel ist die funktionale Programmierung. Es gibt in C++ sicher Elemente, die sich der funktionalen Programmierung zuordnen lassen, andererseits gibt es aber nicht einmal "reine Funktionen". Im Artikeltext kann man auf diese Details eingehen. Das ist informativ und sinnvoll. Aber einfach nur einen Begriff ohne Kontext in eine Liste zu klatschen (oder wegzulassen) entspricht nicht dem Grundgedanken einer Enzyklopädie. Bestimmt gibt es Dinge, die sich sinnvoll in einer Tabelle darstellen lassen (beispielsweise die Normen), die Programmierparadigmen gehören aber nicht dazu. (Mit der Typisierung verhält es sich ähnlich.) Deswegen bin ich dafür, diese beiden Listen die Liste Paradigmen aus der Infobox zu entfernen. --Sunks (Diskussion) 20:59, 25. Mai 2012 (CEST)

Kann ich nicht unterschreiben, C++ ist nun einmal imperativ und objektorientiert, das kann man nicht leugnen. In anderen Artikeln zu Programmiersprachen sind die Paradigmen auch angegeben. Was setzt du bitte an der Typisierungsbox aus? —Gorlingor (Diskussion) 21:42, 25. Mai 2012 (CEST)

Ich habe meinen Standpunkt relativ ausführlich erläutert, und deshalb bitte ich dich, auf meine Argumente einzugehen. "ist nun einmal" und "das kann man nicht leugnen" sind keine Gegenargumente. Beachte bitte die Schwierigkeit, die in der Definition der so genannten Paradigmen liegt. Im Artikel imperative Programmierung kannst du nachlesen, dass imperative Programmierung manchmal mit prozeduraler Programmierung gleichgesetzt wird, manchmal aber auch nicht. Was ist es denn nun? Und selbst zur objektorientierten Programmierung kann man anmerken, dass sie im Unterschied zu Sprachen wie Smalltalk nur unvollkommen in C++ integriert ist. Das Problem wird dadurch verschärft, dass es unterschiedliche Definitionen zur Objektorientierung gibt. Siehe beispielsweise What is „Object-Oriented Programming“: "Object-oriented programming is programming using inheritance.", oder Einführung Objektorientierung: "Objektorientierung ist ein Ansatz aus der Softwareentwicklung, der die Zusammenfassung von Daten und den dazugehörigen Funktionen in Klassen von Realweltobjekten unterstützt.", oder Introduction: What is Object-Oriented Programming: "OOP, defined in the purest sense, is implemented by sending messages to objects."

Man kann die Frage "wird Paradigma x unterstützt oder nicht" eben nicht einfach mit ja oder nein beantworten. Das ist das Problem. Und in der Tabelle fehlt der Kontext.

"In anderen Artikeln sind die Paradigmen auch angegeben" ist übrigens kein Argument, denn in anderen Artikeln kann es ja genauso fragwürdig sein.

Da ich mich zur Typisierungsbox bisher noch nicht ausführlicher geäußert habe, und anscheinend Einwände bestehen, nehme ich die Liste zur Typisierung zunächst wieder in den Artikel. Die Diskussion dazu können wir ein anderes mal weiterführen. Hier soll es zunächst nur um die Paradigmen gehen. --Sunks (Diskussion) 16:56, 26. Mai 2012 (CEST)

C++ erfüllt beide deiner genannten Definitionen von Objektorientierung …

Aber ich verstehe schon, worauf du hinaus willst. Man kann es ruhig in den Fließtext schreiben, aber nicht einfach die Box entfernen. Im Fließtext steht übrigens immer noch, dass die objektorientierte Programmierung unterstützt wird. —Gorlingor (Diskussion) 17:02, 26. Mai 2012 (CEST)

Es erfüllt nicht unbedingt die dritte Definition (nachträglich hinzugefügt). Doch, die Liste "Paradigmen" in der Infobox muss aus den genannten Gründen entfernt werden. Und den Fließtext müssen wir auch in Angriff nehmen, da gebe ich dir Recht. --Sunks (Diskussion) 17:07, 26. Mai 2012 (CEST)

Ergänzt du nun die Informationen im Fließtext? —Gorlingor (Diskussion) 14:47, 3. Jun. 2012 (CEST)

Ich finde, der ganze Abschnitt "Eigenschaften" müsste mal überarbeitet werden. Kannst dich gerne selber daran versuchen. --Sunks (Diskussion) 16:20, 3. Jun. 2012 (CEST)

Könnte man nicht einfach „funktional“ streichen? Dass es multiparadigmatisch ist und das OO, gen., str. und proz. Programmierung mit einschließt, ist doch wohl unbestritten. --Chricho ¹ ² ³ 17:03, 3. Jun. 2012 (CEST)

Das ist eben alles andere als unbestritten. Bitte lies dir die gesamte Diskussion in diesem Abschnitt durch, damit ich nicht alles wiederholen muss. Das ganze Thema ist viel komplizierter, als es auf den ersten Blick scheint. --Sunks (Diskussion) 03:52, 4. Jun. 2012 (CEST)

Zum gesamten Thema siehe auch → falsches Dilemma. --Sunks (Diskussion) 04:00, 4. Jun. 2012 (CEST)

Ich sehe darin, zumindest im Falle von C++ kein Problem, das man nicht lösen könnte. Man könnte festlegen, dass eine explizite Unterstützung wesentlicher Voraussetzungen eines Paradigmas seitens des Sprachkerns, Standardbibliothek oder Vergleichbarem für eine Nennung in der Infobox maßgeblich ist, man sich auf explizit darauf ausgelegte Sprachfeatures beschränkt, und es nicht darum geht, dass sie völlig dem jeweiligen Paradigma folgen (Definition 3 wäre ausgeschlossen) oder nur einen Softwareentwicklungsansatz erlauben (Definition 2 wäre ausgeschlossen, damit wäre etwa auch C objektorientiert zu nennen). Funktionale Programierung wäre zu streichen, weil C++ keinerlei Features anbietet, die darauf ausgelegt sind, Programmteile nur aus Funktionen aufzubauen.

Ich sehe da eigentlich kein Problem, das man lösen müsste. Tabellen können eingesetzt werden, solange sie sinnvoll sind und ihren Zweck erfüllen, wie z.B. bei den Normen (ISO/IEC 14882:1998 usw.), und wenn sie das nicht tun, dann lässt man sie eben weg. Jede "Festlegung" die man bezüglich der Aufnahme in die Tabelle treffen würde, wäre willkürlich und von der persönlichen Sichtweise abhängig, also POV. Aber wie gesagt: Das Thema lässt sich eigentlich sehr gut ohne Tabellen darstellen. --Sunks (Diskussion) 21:47, 4. Jun. 2012 (CEST)

Nun, die Infoboxen sind aber egtl. auch nicht dafür gedacht, nur eine Minimaldosis absolut uninteressanter Attribute aufzunehmen. Natürlich sehe ich die Problematik. Da das vmtl. auf die Artikel zu so gut wie allen Programmiersprachen zutrifft und es wohl bislang flächendeckend so gehandhabt wurde, größzügig Attribute – nach bestimmten Maßstäben oder auch einfach so – einzutragen: Wie wäre es mit einer Diskussion Wikipedia Diskussion:Redaktion Informatik? --Chricho ¹ ² ³ 00:44, 8. Jun. 2012 (CEST)

Ich möchte widersprechen, dass es unzulässig ist, ein Kriterium für die Infoboxen festzulegen. Es ist nun einmal so, dass Wörter unterschiedlich gebraucht werden. Nehmen wir einmal geographische Artikel als Beispiel, dort ist es eindeutiger, dass so etwas in der Wikipedia möglich sein muss: Landesname, Einwohnerzahl (insb. bei Städten↔Metropolregionen), Hauptstadt, Staatsform, Regierungssystem, überall da muss festgelegt werden, nach welchen Kriterien man vorgeht, und gerade das ist das, was sinnvollerweise in eine Infobox gehört. Noch etwas: Sinn einer Infobox ist übrigens auch nicht, darzustellen, was man im Fließtext nicht gut darstellen kann – dafür sind sonstige Tabellen und Listen da, darum geht es an dieser Stelle nicht – eine Infobox soll einen schnellen Blick auf gewisse grundlegende, strukturierte Informationen liefern (womöglich sogar maschinell verarbeitet werden). Ich denke also: Infoboxen sind sinnvoll und wenn es denn machbar ist, ist es besser, einheitliche Kriterien festzulegen, als auf sie zu verzichten. --Chricho ¹ ² ³ 00:57, 8. Jun. 2012 (CEST)

Es geht um etwas anderes. Nimm mal diesen Artikel → Aachen. Die Liste der unter Stadtgliederung angegebenen Stadtbezirke ist eindeutig und vollständig. Da gibt es nichts zu deuteln. Das mit den Paradigmen ist aber Interpretationssache. --Sunks (Diskussion) 02:57, 11. Jun. 2012 (CEST)

Ich habe nicht behauptet, dass es bei allen Infoboxen Möglichkeiten zur Willkür gäbe. Nimm eben z. B. die, die Regierungssystem aufführen. Ich bezweifle, dass dir die Infoboxen in C, Perl, PHP oder Java viel besser gefallen. Die alle zu leeren, ohne vorher mal ein paar Gedanken gemeinschaftlich sich gemacht zu haben, halte ich für wenig sinnvoll, die Infobox ist im Moment völlig nutzlos, und ich denke, man sollte es zumindest in Erwägung ziehen, bei manchen Einträgen Maßstäbe festzulegen. Wärst du vllt. bereit, deinen Standpunkt in der Redaktionsdiskussion einmal darzulegen? Sonst würde ich dort bald einmal eine Diskussion versuchen anzustoßen, aber du hast das ja schließlich auch hier initiiert. --Chricho ¹ ² ³ 03:26, 11. Jun. 2012 (CEST)

Du hast das Beispiel mit den Geografieartikeln gebracht, und ich habe dir gezeigt, warum es sich dort anders verhält. Die Handhabung in den Geografie-Artikeln ist nicht auf die bei Programmiersprachen übertragbar.

Ich habe nicht vor, die Infoboxen von C, Perl, PHP oder Java zu bearbeiten. Eine Diskussion in einer größeren Runde ist für mich also uninteressant. Ich habe im Moment auch leider nicht die Zeit dafür. Vielleicht ein anderes Mal. --Sunks (Diskussion) 05:24, 11. Jun. 2012 (CEST)

Wie gesagt, der Artikel Aachen braucht auch weder Regierungssystem, noch Hauptstadt, noch ist es dort sinnvoll, von irgendeiner Monopolregion zu sprechen. --Chricho ¹ ² ³ 11:04, 11. Jun. 2012 (CEST)

Zu den von dir erwähnten "einheitlichen Kriterien": Die einheitlichen Kriterien sind möglicherweise eine der Wurzeln des Übels, denn die Materie Programmiersprachen ist zu komplex und inhomogen um sie in einfache, einheitliche Kriterien zu fassen. Nehmen wir beispielsweise das so genannte "Erscheinungsjahr". Es lässt sich für C++ nicht sinnvoll bestimmen, für andere Programmiersprachen aber schon. Für C++ könnte man hingegen die Verabschiedungszeitpunkte der jeweiligen Normen angeben (dann unter einem anderen Eintrag, nicht unter "Erscheinungsdatum"), die meisten Programmiersprachen sind aber gar nicht genormt. Mit anderen Worten, man kommt nicht um Einzelfallbetrachtungen herum. --Sunks (Diskussion) 17:22, 15. Jun. 2012 (CEST)

Ich werde die eine oder andere Sache an Infoboxen anderer Programmiersprachen doch ändern. Das wird in erster Linie Unbelegtes betreffen. --Sunks (Diskussion) 03:41, 27. Jun. 2012 (CEST)

Ich habe die Infobox wieder hineingegeben so wie sie vor der Löschung von Sunks drinnen war. Bitte um Diskussion vor Änderung. Bitte auch darzustellen, warum C++ anders als alle anderen Programmiersprachen gehandhabt werden soll. Bitte auch zu bedenken dass Projekte wie Wikipedia:Wikidata auf Infoboxen angewiesen sind. --Sebastian.Dietrich ✉ 18:14, 27. Jun. 2012 (CEST)

Die Diskussion hat bereits stattgefunden. Wenn du eine Änderung möchtest, kannst du eine neue Diskussion starten. Aber bitte erst ausdiskutieren, dann ändern. --Sunks (Diskussion) 17:28, 28. Jun. 2012 (CEST)

Nein dem ist nicht so. Du hast die Diskussion "beendet" indem du gesagt hast, dass du es mal so machst, wie du es vorgeschlagen hast. Niemand anderer hat sich davor dafür ausgesprochen. --Sebastian.Dietrich ✉ 17:36, 28. Jun. 2012 (CEST)

Da kann ich dir leider nicht folgen. Es ist der Diskussionsstand. --Sunks (Diskussion) 19:02, 28. Jun. 2012 (CEST)

Dann lies diesen Abschnitt nochmal. Da steht nirgendwo drinnen, dass es gelöscht gehört. Nur, dass du dies tust. --Sebastian.Dietrich ✉ 17:29, 2. Jul. 2012 (CEST)

Lieber Benutzer:Sunks, ziehe doch bitte einmal die Möglichkeit in betracht, dass andere nicht deiner Meinung sind und du vielleicht falsch liegst. Manche Dinge werden per Mehrheitsentscheidung bestimmt, und dann wird es eben nicht so gemacht, wie es ein einzelner gerne hätte.

Soweit ich das sehe, hat außer dir niemand ein Problem damit, C++ als

• imperativ
• objektorientiert
• teilweise funktional

zu bezeichnen, auch wenn nicht alles 100%ig da/möglich sein mag. --arilou (Diskussion) 14:38, 5. Jul. 2012 (CEST)

Typisierung

Es scheint mir so, als gäbe es einen Dissens bezüglich der Typisierung von C++ zu geben (so um [13]). Um das nicht in einen Edit-War ausarten zu lassen, sollten wir uns mal einigen. Wie in Starke Typisierung beschrieben, ist Typisierung nichts absolutes, bestenfalls etwas vergleichbares. Mal paar Argumente für jede Seite:

C++ ist stark/streng typisiert:

• Keine implizite Konvertierung zwischen Klassen (ob es das irgendwo gibt?)
• Keine implizite void* -> xyz*-Konvertierung
• eindeutig unterschiedliche Datentypen, Klassen etc
• Keine implizite Konversion von Klassenpointern virtuell abgeleiteter in ihre Basisklassen (blöd zu beschreiben, aber in etwa so: Derived* xyz = dynamic_cast<Derived*> abc; // where decltype(abc) == Base*)

C++ ist schwach typisiert:

• Implizite Konversion z.B. zwischen Zahlwertvariablen, C-Strings, Zahl-Arrays... (im Extremfall double -> char)
• Implizite Konversion von Klassen, die auf bestimmte Weise verwandt sind (sogar unter Datenverlust, Derived -> Base)
• Implizite Konversion von Klassenpointern, die auf bestimmte Weise verwandt sind (Derived* -> Base*)
• Ergänzung: Der Messer ^{meckern? - Bew} 19:33, 8. Jun. 2012 (CEST): Nach Bereitstellung der passenden Operatoren ist eine implizite Konvertierung zwischen so ziemlich allem möglich

Wie gesagt, es ist schwer zu bestimmen, was C++ jetzt eigentlich ist. Ich persönlich würde für stark plädieren, aber, wie gesagt, nur persönlich. Nach Argumenten ist es beides und keins :-) Was sagt ihr? --Der Messer ^{meckern? - Bew} 18:56, 7. Jun. 2012 (CEST)

Da C++ die Eigenschaften von C erbt, ist es a fortiori nur schwach in Sachen Typen. Vielleicht sollte man die Begriffe im Text stärker herausarbeiten. -- ZZ (Diskussion) 19:07, 7. Jun. 2012 (CEST)

C++ erlaubt implizite Konvertierung zwischen Klassen, und zwischen Klassen und elementaren Datentypen, auf nahezu beliebige Weise, die Konvertierungen müssen nur jeweils implementiert werden. Sind elementare Datentypen beteiligt, können sogar mehrere implizite Konvertierungen infolge ausgeführt werden. Es gibt eine große Vielzahl an Typunterschieden (Basisklassen, Qualifier und aufwändigere Konvertierungen), die beim Aufruf (potenziell überladener) Funktionen erlaubt sind. Auch Konvertierungen zwischen elementaren Datentypen finden mitunter unter Datenverlust statt (allerhand Typen → bool, größerer Ganzzahltyp → kleiner Ganzzahltyp, Fließkomma → Ganzzahl, Ganzzahl → Fließkomma). Ebenfalls ist char *str = "abc"; erlaubt – unter Verlust des const-Qualifiers. Schlussendlich bietet C++ Konstrukte wie unions, direkten Zugriff über char-Pointer und reinterpret_cast, die das Typsystem umgehen. Ich denke, das ist recht eindeutig und es hatte das nur übereifrig jemand geändert gehabt. --Chricho ¹ ² ³ 19:23, 7. Jun. 2012 (CEST)

Wobei der letzte Punkt eher Unsicherheit zu nennen ist, habe das ergänzt. --Chricho ¹ ² ³ 19:27, 7. Jun. 2012 (CEST)

Ich sehe da die gleichen Probleme wie bei starker/schwacher Typisierung. Mal abgesehen davon, dass die beiden Konzepte so stark miteinander zusammenhängen, dass eine getrennte Darstellung fraglich erscheint. --Sunks (Diskussion) 21:37, 7. Jun. 2012 (CEST)

@Der Messer: Wie in starke Typisierung beschrieben, ist Typisierung nichts absolutes. Genau. In die Infobox zu schreiben, C++ sei stark oder schwach typisiert, ist genauso, als würde man in die Infobox zum Eiffelturm schreiben, der Turm sei groß. Oder eben klein, je nachdem. Mit anderen Worten: Der Eintrag ist so nicht sinnvoll. Wie ich schon geschrieben habe, halte ich Tabellen in manchen Fällen für eine sinnvolle Ergänzung zu Artikeln; hier brauchen wir aber Fließtext. Das gleiche gilt für "Typsicherheit". In der Newsgroup comp.lang.c++.moderated hat sich übrigens Alexandrescu in einem Beitrag genau dazu geäußert, nämlich (sinngemäß) dass Typsicherheit keine binäre, sondern eine Art kontinuierliche Eigenschaft sei.

Insgesamt halte ich das Thema Typisierung in C++ für ein komplexes Thema, dem man wahrscheinlich einen eigenen Artikel widmen könnte. Oder auch ein ganzes Buch.

@ZZ: Richtig, die Lücken, die C aufreißt, schließt C++ nicht. Mit einer signifikanten Ausnahme: void* lässt sich, anders als in C, nicht jedem Zeiger zuweisen. Darüber hinaus könnte man argumentieren, dass ein "moderner Programmierstil" die von C geerbten Nachteile vermeidet, so dass es in realen C++-Programmen diesbezüglich effektiv deutlich weniger Probleme gibt. (So vermeidet beispielsweise unique_ptr<T> viele derartige Probleme.) Die Begriffe im Text stärker herauszuarbeiten findet jedenfalls meine volle Zustimmung (s.o.). --Sunks (Diskussion) 21:34, 7. Jun. 2012 (CEST)

Un nu? Einfach rausnehmen, da es unmöglich ist, das zu definieren? --Der Messer ^{meckern? - Bew} 19:42, 13. Jun. 2012 (CEST)

Die Einträge schwach und unsicher würde ich in jedem Fall rausnehmen. Aber was machen wir mit statisch? Es gibt ja auch dynamische Typinformationen. --Sunks (Diskussion) 21:27, 13. Jun. 2012 (CEST)

Gemäß → statische Typisierung ist nicht entscheidbar, ob C++ als statisch oder dynamisch typisiert zu bezeichnen ist. Also alles raus. --Sunks (Diskussion) 17:35, 14. Jun. 2012 (CEST)

Die Bezeichnungen schwach und unsicher sind weit verbreitet. Es ist auch nicht unmöglich, das zu definieren, es bleiben nur Grauzonen. Deswegen schlage ich eine Erweiterung des oben beschriebenen Ansatzes vor: 1. Quellen finden und zitieren, 2. sagen, was es heißen soll, 3. wie Sunks sagte, darauf hinweisen, dass es um die Sprache geht, es aber sehr wohl Programmierstile bzw. Programmierdisziplin gibt, die eingesetzt werden. In anderen Worten, man kann auch in einer schwach getypten Sprache typsicher programmieren. Nur will man das nicht immer. -- ZZ (Diskussion) 13:44, 16. Jun. 2012 (CEST)

Die Einträge in der Tabelle nehme ich dann erst mal raus. --Sunks (Diskussion) 07:36, 27. Jun. 2012 (CEST)

Versuch einer Zusammenfassung: C++ ist sowohl stark als auch schwach, sowohl statisch als auch dynamisch typisiert (jeweils unterschiedliche Teile). So wie Fassade des Empire State Buildings (in jeweils unterschiedlichen Teilen) aus Glas, Kalkstein, Granit besteht plädiere ich dafür alle Typisierungen von C++ aufzunehmen.--Sebastian.Dietrich ✉ 19:30, 29. Jun. 2012 (CEST)

Nein, C++ ist nicht sowohl stark als auch schwach typisiert. Das steht auch nirgendwo. --Sunks (Diskussion) 01:07, 4. Jul. 2012 (CEST)

Steht oben, und dem hast auch du zugestimmt: "In die Infobox zu schreiben, C++ sei stark oder schwach typisiert, ...". Was jetzt?

"statisch" und "dynamisch" passt dir also?

Ich such mal nach Literatur... --Sebastian.Dietrich ✉ 09:09, 4. Jul. 2012 (CEST)

Zweitägige Vollsperrung

Wegen Bearbeitungskrieg wurde der Artikel in einer Vorkriegsversion für zwei Tage vollgesperrt. Bitte hier die Diskussion sachlich austragen, ggf. eine dritte Meinung einholen und der nächste Revertieren (nach Ablauf der Sperre) wird temporär zum Lesen verdammt. Sollte ein vorzeitiger Kompromiss/Konsens gefunden worden sein, bitte bei mir oder dem nächsten Admin melden. Danke. --Kuebi [∩ · Δ] 19:16, 28. Jun. 2012 (CEST)

Auch wenn ich halbwegs aktiv bei dem Artikel hier bin, wollte ich fragen (ist mir gerade unklar, zu viele Edits), weshalb die Sperrung erfolgt -- wegen der Typisierungssache? Grüße, --Der Messer ^{meckern? - Bew} 19:54, 28. Jun. 2012 (CEST)

Siehe nächster Abschnitt. Ich habe die Infobox wiederhergestellt und um Diskussion darüber gebeten. Wurde von Sunks reverted ("wurde bereits ausdiskuttiert"). Nachdem das nicht stimmte (siehe nächster Abschnitt) hab ich das in die disk geschrieben und reverted. Sunks hat dann reverted und Vandalismus gemeldet. --Sebastian.Dietrich ✉ 20:35, 28. Jun. 2012 (CEST)

Ist C++ eine Programmiersprache?

Bestandsaufnahme:

• C++ ist eine Programmiersprache - warum keine Infobox:Programmiersprache? Weil am 27.6. von Sunks entfernt ([14]). lt. Diskussion waren dafür: 0 Personen (nichtmal Sunks hat das angekündigt/erwähnt/vorgeschlagen). C++ ist somit die einzige Programmiersprache in der Wikipedia, die keine Infobox:Programmiersprache hat.
• C++ beeinflusste andere Programmiersprachen und wurde von anderen Programmiersprachen beeinflusst - warum steht das nicht in der Infobox? Weil am 24.5. von Sunks ohne Diskussion darüber entfernt ([15])
• C++ folgt Paradigmen - warum steht das nicht in der Infobox? Weil am 3.6. von Sunks "lt. Diskussion" entfernt ([16]). lt. Diskussion waren dafür: 1 Person (Sunks), dagegen waren 2 Personen (Benutzer:Chricho, Benutzer:Gorlingor)
• C++ unterstützt verschiedene Arten von Typisierungen - warum steht das nicht in der Infobox? Weil am 27.6. von Sunks "siehe Diskussion" entfernt ([17]). lt. Diskussion waren dafür: 0 Personen (nichtmal Sunks hat das angekündigt/erwähnt/vorgeschlagen). Einzig Benutzer:Der Messer hat die Frage in den Raum gestellt, ob man das löschen sollte, aber niemand hat sich dafür oder dagegen ausgesprochen.
• C++ wurde hauptsächlich von Bjarne Stroustrup entwickelt - warum steht das nicht in der Infobox? Weil am 24.5. von Sunks ohne Diskussion darüber entfernt ([18])
• C++ erschien irgendwann - wann (zumindest Anfang der 80er) steht nicht in der Infobox? Weil am 21.5. von Sunks ohne Diskussion darüber entfernt ([19])
• C++ wird durch C++ Builder etc. implementiert - warum steht das nicht in der Infobox? Weil am 22.5. von Sunks ohne Diskussion darüber entfernt ([20])

Tolle Leistung. Siehe auch Sunks "Verbesserungen" in C-Sharp, COMAL, COBOL, Cω, Ceylon (Programmiersprache), Basic Combined Programming Language, Alef (Programmiersprache), ACUCOBOL, ABAP, A+ (Programmiersprache), Ada (Programmiersprache), D (Programmiersprache), PHP, Java (Programmiersprache) --Sebastian.Dietrich ✉ 20:26, 28. Jun. 2012 (CEST)

Anstatt zu versuchen mir Formfehler nachzuweisen, solltest du Argumente zur Sache bringen. Nur so kommen wir weiter. Niemandes Meinung soll hier unter den Teppich gekehrt werden. Allerdings sollte sich jeder, der sich hier beteiligt, in die Diskussion einlesen, damit wir nicht bei jedem neuen Diskutanten komplett von vorn anfangen müssen. Wichtig ist auch, auf die Argumente der anderen Diskutanten einzugehen und nicht gebetsmühlenartig den eigenen Standpunkt zu wiederholen.

Anders als du es darstellst, wurden fast alle Themen, die du oben erwähnst, hier auf die eine oder andere Art besprochen, allerdings wurden den Punkten "Erscheinungsjahr" und "Entwickler" noch keine eigenen Abschnitte gewidmet, deshalb schlage ich für die weitere Diskussion vor, damit zu beginnen (s.u.). --Sunks (Diskussion) 00:45, 29. Jun. 2012 (CEST)

Formfehler ist was anderes. Klar soll sich jeder in Diskussionen einlesen (darum auch oben die Zusammenfassung der Pro- und Contra- Stimmen). Das gilt aber auch für dich. Wenn bei Diskussionen klar herauskommt, dass etwas bleibt, dann solltest du es nicht löschen. Nochmals eine Zusammenfassung für Dich:

• Infobox lassen/löschen - wurde nicht diskuttiert
• Beeinflusste/wurde beeinflust lassen/löschen - wurde nicht diskuttiert
• Paradigmen lassen/löschen - wurde diskuttiert +1 für löschen, +2 für lassen
• Typisierungen lassen/löschen - wurde nicht diskuttiert (nur die Frage wurde gestellt)
• Entwickler & Erscheinungsjahr - wurde nicht diskuttiert (s.u.)
• Implementierungen - wurde nicht diskuttiert

Ich trage jetzt die fehlenden Diskussionen unten nach --Sebastian.Dietrich ✉ 08:35, 29. Jun. 2012 (CEST)

Doch, mit Ausnahme der Vorlage Infobox und Entwickler/Erscheinungsjahr wurde alles schon einmal auf die eine oder andere Art aufgegriffen. Es spricht allerdings nichts dagegen, die Themen noch zu vertiefen. Ich bin also damit einverstanden, dass du unten einige neue Abschnitte einführst. Was die Vorlage Infobox betrifft: Ich bin nicht dagegen, aber warum nicht etwas verbessern, falls es möglich ist? Typisierung: Doch, wurde sogar verhältnismäßig ausführlich diskutiert. Ich halte es in diesem Fall nicht für sinnvoll, noch einen neuen Abschnitt dafür zu beginnen. Den letzten Kommentar von ZZ, bevor ich geschrieben habe, dass ich den Eintrag entferne, sehe ich als Zustimmung, die Darstellung auf den Fließtext zu verlagern. Vielleicht äußert er sich selber noch einmal dazu.

Auch bei dem Abschnitt zu den Paradigmen halte ich es nicht für sinnvoll, noch einen neuen Abschnitt anzufangen. Übrigens werden Diskussionen zu Inhalten nicht per Abstimmung entschieden. Entscheidend ist also nicht die reine Willensäußerung, sondern die Begründung. --Sunks (Diskussion) 17:03, 29. Jun. 2012 (CEST)

Es geht mir nicht um den Inhalt der einzelnen Felder, sondern dass diese nicht gelöscht werden, nur weil diese nicht 100% klar sind. Wenn man z.B. nicht exakt wissen würde, wann C++ erstmals der Öffentlichkeit präsentiert wurde (1985), so sollte das drinnen stehen, was man dazu weiss (in den 1980er Jahren). Infoboxbefüllung ist keine exakte Wissenschaft. --Sebastian.Dietrich ✉ 10:51, 30. Jun. 2012 (CEST)

Infobox

Ich möchte nur gerne auf diese Abstimmung verweisen. Curtis Newton ↯ 10:44, 30. Jun. 2012 (CEST)

Infobox lassen/löschen

Wie alle Programmiersprachen verdient auch C++ eine Infobox. Infoboxen sind ein wichtiger Bestandteil der Wikipedia, sie helfen Lesern gleichartige Informationen an der gleichen Stelle zu finden. Sie sind für behinderte Menschen (v.a. Blinde&Sehbehinderte) extrem hilfreich, um sich in der Wikipedia zurechtzufinden. Sie sind Voraussetzung für Software (siehe z.B. Wikipedia:Wikidata) um Daten lesen/abgleichen/verstehen zu können --Sebastian.Dietrich ✉ 08:44, 29. Jun. 2012 (CEST)

Was nicht sinnvoll ist, bleibt draußen. Das gilt auch für Infoboxen. Allerdings steht die Box gar nicht grundsätzlich zur Disposition, deshalb sehe ich hier keinen Diskussionsbedarf. --Sunks (Diskussion) 17:29, 29. Jun. 2012 (CEST)

Wunderbar, dann bleibt die Infobox Software also weiter drinnen und du ersetzt sie nicht durch eine Wikitable.  Ok --Sebastian.Dietrich ✉ 19:31, 29. Jun. 2012 (CEST)

Beeinflusste/wurde beeinflust lassen/löschen

Selbstverständlich lassen, wie auch bei anderen Programmiersprachen. Beeinflussungen sind einfach erkennbar, durch Literatur etc. belegbar. --Sebastian.Dietrich ✉ 19:31, 29. Jun. 2012 (CEST)

Nein, im Gegenteil, "Beeinflussungen", wie du es nennst, sind manchmal nicht einfach erkennbar. Soll ich ein Beispiel nennen? Ich tu's einfach: Die Beeinflussung von C durch Java ist so grundlegend, dass sie einen eigenen Abschnitt im Artikel C verdient hätte. Um diesen Zusammenhang zu erkennen, muss man sich eingehend mit dem Thema beschäftigen. In der gesamten Wikipedia findet sich aber nicht der kleinste Hinweis darauf. --Sunks (Diskussion) 09:27, 30. Jun. 2012 (CEST)

Verstehe jetzt deine Argumentation nicht. Du erkennst also an, dass es Beeinflussungen zwischen Programmiersprachen gibt, forderst dafür sogar eigene Abschnitte ein, möchtest diese aber nicht in der Infobox erwähnen? Mein Standpunkt: Alles was Allgemeinwissen (d.h. in dem Fall auf der Uni/FH in Einführungsveranstaltungen gelehrt wird) ist bzw. belegt werden kann soll rein. Egal wie schwer diese selbst im einzelnen nachvollziehbar sind. --Sebastian.Dietrich ✉ 10:29, 30. Jun. 2012 (CEST)

Hier das was Stroustrup dazu sagt [21] Seite 12: "However, only C, Simula, Algol68, and in one case BCPL left noticeable traces in C++ as released in 1985. Simula gave classes, Algol68 operator overloading (§3.3.3), references (§3.3.4), and the ability to declare variables anywhere in a block (§3.3.1), and BCPL gave // comments (§3.3.1)." --Sebastian.Dietrich ✉ 11:08, 30. Jun. 2012 (CEST)

Also von Beeinflussungen sind einfach erkennbar sind wir jetzt bei Egal wie schwer diese selbst im einzelnen nachvollziehbar sind gelandet?

Mein Standpunkt: Was hat der Leser davon, wenn ich (z.B.) in eine Tabelle schreibe "Die Programmiersprache C wurde beeinflusst durch Java."? Hier fehlt ganz einfach der Zusammenhang. Interessant zu wissen ist doch, in welcher Hinsicht die Sprache beeinflusst wurde. Wir schreiben hier eine Enzyklopädie. --Sunks (Diskussion) 16:16, 2. Jul. 2012 (CEST)

Sorry aber mit dieser Argumentation kannst du sämtliche Inhalte sämtlicher Infoboxen wegargumentieren. Gerade als Enzyklopädie ist die WP verpflichtet Wissen kompakt darzustellen. Wir schreiben keine Dissertation über die Beeinflussung von A auf B. Fakt ist - und das gibst du ja zu - dass es Beeinflussungen gibt. Fakt ist, dass diese auch WP-gültig belegt werden können. Ergo gehören diese auch in die Infobox und (wenn du es gerne machen möchtest) auch noch detailiert irgendwo im Artikel genau erklärt. --Sebastian.Dietrich ✉ 17:26, 2. Jul. 2012 (CEST)

Allerdings muss jetzt nicht jede kleine Beeinflussung genannt werden. Wenn z.B. von BCPL gerade mal die '//' gekommen sind, dann seh' ich da keine nennenswerte Relevanz. Es sollte schon bei "wesentliche Beeinflussungen" bleiben. --arilou (Diskussion) 14:53, 5. Jul. 2012 (CEST)

Paradigmen lassen/löschen

Wurde bereits oben (siehe #Infobox - Paradigmen) diskuttiert +1 für löschen, +2 für lassen (Kommentar von Sebastian.Dietrich)

Inhalte werden nicht per zahlenmäßiger Präsenz der Diskutanten entschieden. Bitte hierzu keinen neuen Abschnitt beginnen. Bei weiterem Diskussionsbedarf den Abschnitt von oben bitte hierhin verschieben. --Sunks (Diskussion) 17:29, 29. Jun. 2012 (CEST)

Ähhh wie meinst du das? Es gibt eine Diskussion, 2 sind für Lösung A, einer für Lösung B, und du erkennst dass das Diskussionsergebnis B wäre? --Sebastian.Dietrich ✉ 19:31, 29. Jun. 2012 (CEST)

Lies dies. --Sunks (Diskussion) 09:27, 30. Jun. 2012 (CEST)

Kenne ich, passt hier aber nicht - du hast ja an der Abstimmung teilgenommen. Das Ergebnis war nicht in deinem Sinne, du machst die Änderung trotzdem, und merkst an, dass kein weiterer Diskussionsbedarf besteht (weil du der Meinung bist, dass deine Begründungen die besseren sind).--Sebastian.Dietrich ✉ 10:22, 30. Jun. 2012 (CEST)

Da kann ich dir im Moment leider nicht folgen. An welcher Abstimmung habe ich deiner Meinung nach teilgenommen? Kannst du einen Difflink angeben? --Sunks (Diskussion) 16:16, 2. Jul. 2012 (CEST)

Du sprichst dich im Abschnitt #Infobox - Paradigmen für Löschen aus, 2 Personen sprechen sich gegen Löschen aus. --Sebastian.Dietrich ✉ 17:28, 2. Jul. 2012 (CEST)

Typisierungen lassen/löschen

Inhalt wurde oben (siehe #Typisierung diskuttiert, noch nicht obs gelöscht werden soll. --Sebastian.Dietrich ✉ 08:46, 29. Jun. 2012 (CEST)

Bitte hierzu keinen neuen Abschnitt beginnen. Bei weiterem Diskussionsbedarf den Abschnitt von oben bitte hierhin verschieben. --Sunks (Diskussion) 17:29, 29. Jun. 2012 (CEST)

Wunderbar, dann brauchen wir das also deiner Meinung nach nicht diskuttieren - der Block zu Typisierungen kommt also wieder rein - mit dem Inhalt aus der Diskussion von oben. --Sebastian.Dietrich ✉ 19:31, 29. Jun. 2012 (CEST)

Bevor wir zu dem Thema weiterdiskutieren, müssen wir uns darüber einig werden, wo. Du hast jetzt an zwei Stellen etwas ergänzt. Das ist nun wirklich unübersichtlich. Wir können den ganzen Abschnitt Typisierung, wie ich bereits vorgeschlagen habe, hierher kopieren. Wir können aber auch in diesem Abschnitt den Laden dicht machen und oben weiter diskutieren. Mir ist es egal. Wo machen wir also weiter? --Sunks (Diskussion) 09:27, 30. Jun. 2012 (CEST)

oben - hier haben wir uns geeinigt, dass der Block reinkommt, oben einigen wir uns darauf was in den Block reinkommt.  Ok --Sebastian.Dietrich ✉ 10:14, 30. Jun. 2012 (CEST)

Nein, wir haben uns nicht darauf geeinigt, dass der Block reinkommt. Das lässt sich nicht unabhängig von der Sinnhaftigkeit der Inhalte entscheiden. Deshalb bitte oben weiterdiskutieren. --Sunks (Diskussion) 16:16, 2. Jul. 2012 (CEST)

Wunderbar, dann kommt der Block also rein. Mit dem Inhalt "start, schwach, statisch, dynamisch" --Sebastian.Dietrich ✉ 17:32, 2. Jul. 2012 (CEST)

Nein, kommt er nicht. Wunderbar. --Sunks (Diskussion) 01:03, 4. Jul. 2012 (CEST)

Insbesondere lässt sich das nicht unabhängig von einer Klärung darüber entscheiden, welchen Ansprüchen die Einträge in Infoboxen genügen sollten und ob Festlegungen auf bestimmte Bedeutungen erlaubt sein sollen. --Chricho ¹ ² ³ 01:13, 4. Jul. 2012 (CEST)

Das Hauptproblem bei den Infoboxen sehe ich im fehlenden Kontext. In einigen Fällen wird man die jeweiligen Einträge durch aussagekräftigere Bezeichnungen, oder ggf. Kommentare retten können (und dadurch den Kontext herstellen), in anderen Fällen wird es wahrscheinlich zu kompliziert. --Sunks (Diskussion) 01:34, 4. Jul. 2012 (CEST)

Bitte das generell unter Hilfe_Diskussion:Infoboxen diskuttieren. Die Infobox dient nicht zum erklären der Inhalte, sondern zur kompakten Darstellung dieser. Ich zitiere aus Hilfe:Infoboxen: "...sollen ein anschauliches Hilfsmittel zum Fließtext sein und diesen nicht ersetzen, sondern lediglich ergänzen. Alle zur angemessenen Erklärung des Begriffs nötigen Informationen müssen deshalb auch im Fließtext vorhanden sein." --Sebastian.Dietrich ✉ 08:57, 4. Jul. 2012 (CEST)

Implementierungen lassen/löschen

Selbstverständlich lassen, wie auch bei anderen Programmiersprachen. Alle relevanten erwähnen (relevant nach den WP Kriterien), das sind eh nur eine Handvoll. --Sebastian.Dietrich ✉ 19:31, 29. Jun. 2012 (CEST)

Ich bin dagegen. Siehe Abschnitt Abschnitt "Kritik am Sprachdesign". --Sunks (Diskussion) 09:27, 30. Jun. 2012 (CEST)

Dort verweist Du auf dein Kommentar beim Löschen - dieses war "was wichtig oder unwichtig ist, ist POV". Deine Kritik richtet sich also nicht gegen die Auflistung der Implementierungen, sondern gegen das Wort "wichtige". Es ist also eine allgemeine Kritik an der Darstellung der Infobox - bitte die dort abzugeben.

Nochmal: Was spricht dagegen alle relevanten zu erwähnen (relevant nach den WP Kriterien), das sind eh nur eine Handvoll. --Sebastian.Dietrich ✉ 10:30, 30. Jun. 2012 (CEST)

Das ist in etwa vergleichbar mit Themenkreisen, die in Wikipedia nicht erwünscht sind, da Wikipedia-Autoren über die Bestandteile entschieden haben. In der Wikipedia sollen aber objektivierbare Informationen dargestellt werden. Die Frage ist also, wie ein Thema von überprüfbaren, verlässlichen Informationsquellen „da draußen in der Welt“ gesehen wird. Ich mache folgenden Vorschlag: Wenn auf eine Darstellung von C++-Compilern Wert gelegt wird, dann soll so eine Zusammenstellung nach Vollständigkeit streben. Aufgrund der Menge käme dann aber eventuell eher eine "Liste von C++-Compilern" in Frage. Ausgangspunkt könnte diese Liste sein. --Sunks (Diskussion) 16:16, 2. Jul. 2012 (CEST)

"This list is incomplete; you can help by expanding it." - du widersprichst dir. --Sebastian.Dietrich ✉ 17:34, 2. Jul. 2012 (CEST)

Erscheinungsjahr lassen/löschen

Ein Erscheinungsjahr lässt sich bei C++ nicht bestimmen. Deshalb ist dieser Eintrag nicht sinnvoll. --Sunks (Diskussion) 00:45, 29. Jun. 2012 (CEST)

Erscheinungsjahr ist das Jahr an dem ein Ding erstmals in der Öffentlichkeit erschienen ist. Im Artikel steht "1985 erschien die erste Version von C++". Also ist entweder dieser Satz falsch, oder muss 1985 als Erscheinungsjahr auch in die Infobox. Stroustrup dazu: "I started work on what became C++ in 1979. The initial version was called "C with Classes". The first version of C++ was used internally in AT&T in August 1983. The name "C++" was used late that year. The first commercial implementation was released October 1985 at the same time as the publication of the 1st edition of The C++ Programming Language."[22] Erscheinungsjahr ist also lt. Stroustrup 1985, davor war alles "internally used". --Sebastian.Dietrich ✉ 10:40, 30. Jun. 2012 (CEST)

Anderes Paper [23]: "...book that defined C++ in October 1985" (Seite 1), "..C++ as released in 1985" (Seite 12), "commercial release of C++ in 1985" (Seite 40)

Ja, der Satz ist falsch. Es ist richtig, dass der erste kommerzielle Compiler in dem Jahr herauskam, aber das als Erscheinungsdatum von C++ danach festzulegen, wäre Willkür. Mein Vorschlag: Eine Zeitleiste o.ä. in Form einer Tabelle anlegen, in der Beginn der Entwicklung, erster Compiler, erster kommerzieller Compiler, ISO-Norm usw. aufgeführt werden. Das ist auch informativer. --Sunks (Diskussion) 16:16, 2. Jul. 2012 (CEST)

Stimmt nicht. Lies dir einfach nochmal durch, was Stroustrup dazu sagt: "...book that defined C++ in October 1985". --Sebastian.Dietrich ✉ 17:36, 2. Jul. 2012 (CEST)

Es bedeutet, das Buch beschreibt die Sprache in dem Zustand, wie sie im Oktober 1985 vorgelegen hat. C++ und C++-Compiler hat es aber auch schon vor 1985 gegeben, und auch das geht aus eben dem von dir angegebenen Dokument hervor. Was spricht gegen eine Zeitleiste anstelle des willkürlich festgelegten Einzeldatums? --Sunks (Diskussion) 00:44, 4. Jul. 2012 (CEST)

Zeitleiste ist gut, aber was anderes - hier gehts um das "Erscheinungsjahr". Erschienen ist die Sprache 1985 das ist belegt. Davor gabs interne Dinge, erschienen ist C++ 1985, das ist nochmals belegt. --Sebastian.Dietrich ✉ 08:48, 4. Jul. 2012 (CEST)

Lieber Benutzer:Sunks, für den Begriff "Erscheinungsjahr" gibt es Definitionen, die mitnichten "Willkür" sind, sondern allgemein anerkannt, z.B. für Bücher ("...book that defined C++ in October 1985"), für Produkte (Markteinführung des "erster kommerzieller Compiler [..] 1985"). Soweit ich das hier lese, hat 1985 da sehr starke Argumente. --arilou (Diskussion) 15:22, 5. Jul. 2012 (CEST)

Entwickler

Es gibt hunderte von Personen, die an C++ mitentwickelt haben. Wer kennt sie alle? --Sunks (Diskussion) 00:45, 29. Jun. 2012 (CEST)

Es reichen die maßgeblichen Beteiligten - siehe dazu Vorlage:Infobox_Programmiersprache/Doku#Parameter

In der Literatur wird fast überall ausschließlich Stroustrup erwähnt - auch im ersten Buch zu C++ (C++ Primer, Preface), detto C++ Primer Plus, Teach yourself C++, A Brief History Of Computing, Mastering C++ --Sebastian.Dietrich ✉ 09:05, 29. Jun. 2012 (CEST)

Es gibt unzählige maßgeblich Beteiligte.^{<ref name="wg21">[24]</ref>} --Sunks (Diskussion) 17:29, 29. Jun. 2012 (CEST)

Nix davon ist vor 1992. Zu diesem Zeitpunkt war die Sprache schon längst etabliert und hat sich nur mehr in Kleinigkeiten (verglichen zu dem was vorher da war) verändert. Keiner der "unzähligen" Beteiligten wird irgendwo in der Literatur erwähnt, keiner ist somit maßgeblich. --Sebastian.Dietrich ✉ 19:31, 29. Jun. 2012 (CEST)

Im Gegenteil, die Sprache hat sich seitdem stark geändert.^{<ref name="wg21">[25]</ref>} --Sunks (Diskussion) 09:27, 30. Jun. 2012 (CEST)

Sicher nicht im Vergleich zu dem was vorher da war - dann wäre C++ nicht mehr wiedererkennbar und diese "maßgeblichen Entwickler" wären in jedem C++ Standardwerk erwähnt. Was wir haben ist 85% so wie vor 1992, 10% Änderungen, 5% Erweiterungen. Wenn Du Literatur findest, die andere Leute als Stroustrup als maßgebliche Schöpfer von C++ erwähnen, dann rein mit diesen Leuten. Ich kenne nur Bücher, die ausschließlich Stroustrup als Entwickler von C++ belegen. --Sebastian.Dietrich ✉ 09:58, 30. Jun. 2012 (CEST)

Woher hast du denn die Zahlen 85%, 10%, 5%? Eine überprüfbare, verlässliche Informationsquelle, die andere maßgebliche Entwickler als Stroustrup von C++ auflistet, habe ich jetzt schon mehrfach angegeben. Wenn es nach der Anzahl der Änderungsvorschläge ginge, würde ich sagen, Google hat C++ entwickelt.^{<ref name="wg21">[26]</ref>} --Sunks (Diskussion) 16:16, 2. Jul. 2012 (CEST)

Bullshit. Die Liste ist weder eine Liste von Entwicklern, noch nennt sie irgendwer (nichtmal die Liste) maßgeblich.--Sebastian.Dietrich ✉ 17:39, 2. Jul. 2012 (CEST)

Du musst die Dokumente öffnen, die auf den Seiten verlinkt sind. Darin stehen die Namen.

Nochmals meine Frage: Woher hast du die Zahlen 85%, 10%, 5%? --Sunks (Diskussion) 00:50, 4. Jul. 2012 (CEST)

Meine Erfahrung - bring einen Beleg, dass die Entwickler maßgeblich! an der Sprache beteiligt waren, dann kommen sie rein. Ansonsten kommt das rein, was belegt ist. Und das ist nur Stroustrup. --Sebastian.Dietrich ✉ 08:49, 4. Jul. 2012 (CEST)

Du kannst dir die Art der Belege nicht aussuchen. Gefordert sind überprüfbare, verlässliche Informationsquellen (s. Belege), was mit der Angabe der Originaldokumente des C++-ISO-Komitees gegeben ist. Deine eigene Erfahrung ist hingegen als Beleg nicht akzeptabel.

Eine Grenzziehung zwischen den Entwicklern, die man anerkennen möchte, und denen, die man nicht anerkennen möchte wäre ferner subjektiv, also POV. Deshalb ist die Aufnahme des Punktes "Entwickler" für die Infobox der Programmiersprache C++ nicht sinnvoll. Ergo bleibt dieser Punkt draußen.

Ich bin mir nicht sicher, wie sinnvoll eine Weiterdiskussion mit dir ist, wenn du nicht einmal die Originaldokumente des C++-ISO-Komitees als Quelle anerkennen möchtest. Deshalb sollten wir vor allem Anderen zunächst einmal diesen Punkt klären. --Sunks (Diskussion) 20:26, 5. Jul. 2012 (CEST)

Was draußen bleibt und nicht, bestimmst zum Glück nicht du. Wenn man sich die weiteren Diskutanten und deren Argumente unterhalb anschaut, stehst du auf alleinigen Posten da. Daher bin ich auch dafür, deine ganzen Streichungen wieder reinzunehmen. 20:37, 5. Jul. 2012 (CEST)

Genau. Sunks kann also nicht belegen, dass andere als Stroustrup maßgeblich an C++ beteiligt waren. Darum versteift er sich auf die Begriffsdefinition des Infoboxeintrages bzw. das Wort "maßgeblich" - darüber kann er gerne diskuttieren, aber nicht mit mir und nicht hier sondern in der Infobox. Ich denke dieser Punkt ist fertig diskuttiert - Stroustrup ist der einzige belegbare maßgebliche Entwickler von C++. --Sebastian.Dietrich ✉ 08:48, 6. Jul. 2012 (CEST)

Zurück auf Mai

Ich empfehle, inhaltlich auf einen frühen Zustand (etwa Anfang Mai) zurückzugehen und von einer über Jahre hinweg bewährten Basis aus jede der Einflüsterungen von Sunks zu einer Löschung kritisch zu überprüfen.

• Das schließt nicht aus, dass die eine oder andere Änderung einmal sinnvoll sein kann; unter dem Stichwort „Schrotschussmethode“ werde ich unten erklären, warum.

Sunks fiel vor einigen Tagen damit auf, im 30-Sekunden-Takt in einer Vandalismus gleichkommenden Art serienmäßig Artikel zu verstümmeln. Dabei waren die Löschungen absolut unberechtigt; unabhängig vom Sachverhalt wurde jeweils das Universal-Totschlag-Argument „unbelegt“ angegeben. Einige Kostproben:

• ACUCOBOL – absurd; ACUCOBOL ist ein Dialekt von Cobol und natürlich ist dies beeinflusst.
• ABAP – absurd; ABAP ist nichts anderes als „Cobol für SAP“ und stammt aus einer Zeit, als der Core der SAP-Software zu 100 % in Cobol geschrieben war. (diff)
• PL/I – absurd; PL/I war der Versuch, die Vorteile der Anfang der 1960er Jahre vorhandenen Hochsprachen zu verbinden; darunter Cobol. (diff) – Grace Hopper hatte sich auch etwas von ihrem eigenen FLOW-MATIC inspirieren lassen.
• C hanebüchener Unsinn – erstaunlich, dass ([???]Kernighan und) Ritchie stehenbleiben durften.
• Disku dazu wurde geführt auf Java (Programmiersprache).

Unter den Artikel- oder Disku-Beiträgen von Sunks kann ich nichts finden, das eine Sachkunde belegen würde und konstruktiv irgendetwas aufbauen würde. Alle seine Beiträge zielen auf die Löschung von Artikelbestandteilen ab, völlig egal ob diese wesentlich wären oder nicht. Schon beim Filtern seiner Beiträge zum ANR gucke ich weitaus überwiegend auf rote Zahlen; grün wird es nur mal durch allgemeinsprachliche Stil-Verbesserung oder Einfügung eines (erfolglosen) LA.

• Dabei bedient er sich aus einem Baukasten von Standard-Begründungen, die sich auf jedes Themengebiet von ägyptischen Ausgrabungen über Diesellokomotiven, Sumpfhühnern oder Shakespeare-Stücke anwenden ließen. In der Diskussion spiegelt er jeweils die Argumentation des Gegenübers oder nur das zuletzt genannte Weblink oder die Artikel-Passage wider, erkennbar ohne wirklich zu wissen worum es geht.
• Sobald es dann in der Diskussion konkret wird, offenbart sich selbstbewusstes Auftreten kombiniert mit völliger Ahnungslosigkeit – bekanntlich ein bewährtes Rezept.
• Diese Taktik ist auch als Schrotschussmethode gebräuchlich; als Cold Reading und Barnum-Effekt analog angewendet im Kontext persönlicher Beziehungen. Gemeinsam ist, dass hier Sachkunde und höheres Wissen vorgetäuscht wird, während tatsächlich nur der Diskussion eine vage Ahnung vom Sachverhalt entnommen und gespiegelt wird. Die komplexen Verhältnisse bringen es mit sich, dass man dabei gelegentlich auch Zufallstreffer landet; bei uns eine wirklich nicht ganz exakt formulierte Aussage, eine Nebensächlichkeit oder anderes. Die Gesprächspartner sind beeindruckt ob der scheinbaren Kompetenz und geben um des lieben Friedens Willen nach.
• Ein lustiges Beispiel dazu ist in diesem Artikel die Löschung von Stroustrup als Entwickler mit der abenteuerlichen Begründung, „Es gibt hunderte von Personen, die an C++ mitentwickelt haben. Wer kennt sie alle?“
  • Niemand auf der Welt hatte bisher den Ruhm von Stroustrup bestritten, mit Ausnahme von Sunks, gestützt auf sein übernatürliches Wissen.
  • Es ist völlig klar, dass Stroustrup der Entwickler ist.
  • Die „hunderte von Personen“ gab es dann auch. Etliche Jahre später, als es um die Entwicklung der Compiler ging; sie praxistauglich zu machen, die Standardbibliotheken zu schreiben und diese Software fehlerfrei zu auszuarbeiten.
  • Im Vorwort zur ersten Auflage erwähnt Stroustrup eine Handvoll von Personen, die durch kritisches Hinterfragen und Anregungen, Vorschläge und Ideen zur Entwicklung der Sprache beigetragen hätten. Niemand ist jemals in Erscheinung getreten mit dem Anspruch, er sei der Co-Autor und Mit-Entwickler der Programmiersprache C++.
• Mysteriös auch, warum der Bezug zu C gestrichen wurde; mit dem Referenzierungs-Dereferenzierungs-Gewürge hatte C++ vom syntaktisch kompatiblen C (subset) einen der größten Nachteile geerbt.
  • Stroustrup selbst gibt in der Historical Note (3^rd ed.) einige Einflüsse bekannt – so nennt er Simula67 oder dass die exceptions aus Ada und ML stammen würden; gar die Notation der // aus Algol68 zusätzlich zum C-Kommentar.
  • Auch Smalltalk als erste Programmiersprache, in der in größerem Umfang reale Anwendungen mit Objektorientierung geschrieben wurden, hat so ziemlich alles beeinflusst, was in den 1980er und 1990ern mit OOP um die Ecke kam – mal mehr, mal weniger.
  • Die Sprachdefinition war in der Fassung von 1987 abgeschlossen und von Stroustrup selbst 1990 der Standardisierung durch ANSI und ISO vorgelegt worden. Seitdem ist an der Sprache selbst nichts Nennenswertes mehr verändert worden; Änderungen im ISO-Prozess betrafen die Standard-Bibliotheken und Erweiterungen um neue Standard-Funktionen, Klassendefinitionen etc.
• Sunks ist erkennbar nicht aus eigener externer Sachkunde tätig, sondern reflektiert bestenfalls, was er in anderen Artikeln der Wikipedia oder im jeweils zuletzt vorgetragenen Weblink findet: „muss man sich eingehend mit dem Thema beschäftigen. In der gesamten Wikipedia findet sich aber nicht der kleinste Hinweis darauf.“
  • Die Notation entstammt C, wurde 1:1 kompatibel nach C++ übertragen, und von dort unter Streichung der Referenzierungs-Dereferenzierung und des Präprozessors durch Java übernommen. – In Artikel und Infobox zu Java war aber niemals eine direkte Beziehung C→Java behauptet worden; in der Tat findet sich die C-Notation aber auch in Java, was die Infobox zu C als Großvater-Generation auch korrekt darstellt. – Der Trick ist: Man müsste sich in der Materie auskennen, und das Resultat in die Wikipedia hineinschreiben. Sunks beherrscht die in Rede stehenden Sprachen überhaupt nicht, sondern verwertet allenfalls grad gegoogelte Aussagenbröckchen aus der Sekundärliteratur.
  • Diese fachliche Basis auf dem Gebiet der Programmiersprachen ist viel zu dünn, um derart massive und unqualifizierte Kastrationen der Artikel durchzudrücken.

Ich frage mich, wo hier die versteckte Kamera ist.

Schönes Wochenende allerseits --PerfektesChaos 11:17, 30. Jun. 2012 (CEST)

Interessant herausgearbeitet. Allerdings habe ich nach kurzem Überfliegen der Beiträge von Sunks den Eindruck, dass du dich in der Einschätzung ein bisschen weit aus dem Fenster lehnst. Auch bei Stichproben der Diskussionen hatte ich den Eindruck, dass aus Unmut über die Löschungen noch weitere Positionen gegen Sunks ins Spiel gebracht werden, die nicht so eindeutig sind. Meine Meinung dazu ist: Wikipedia ist ein freies Projekt von Freiwilligen. Es gibt deshalb keine Pflicht, Experte zu sein, Zweifelhaftes vor dem Löschen zu diskutieren – aber auch keine Belegpflicht. Alle scheinbaren "Pflichten" sind (bis auf den lizenrechtlichen Rahmen) Konventionen, die zu guter Zusammenarbeit und Artikelqualität führen sollen. Diese Konventionen besagen aber auch, dass im Zweifel die Belege derjenige bringen muss, der die Information im Artikel haben will. Was in diesem Themengebiet nun Allgemeinwissen ist und was nicht, kann nicht ein WP-Autor entscheiden (dass C++ oder Java eine Programmiersprache ist, ließe sich übrigens leicht bequellen).

Ich habe die Diskussion nicht genau genug gelesen, um Anhaltspunkte zu erkennen, dass die Beiträge von Sunks allein auf Verwertung von Google-Suchen basieren. Unzweifelhaft unpassend finde ich aber seine Position, bei "unklarer Quellenlage" Informationen zu löschen. Es geht offenbar auch um Punkte, die sowieso nicht Kern der Wissenschaft sind: Welche Sprache wie viel Einfluss auf andere Sprachen hatte, wird meist im laxen Plauderton der Kapiteleinleitungen in Lehrbüchern diskutiert, oder in Nebenbemerkungen. Das ist aber auch offensichtlich. Deshalb muss man diesen Eintrag nicht aus der Infobox streichen.

Aber die Meinung von Sunks, dass Fließtext vorzuziehen ist (wenn ich das richtig zugeordnet habe), teile ich auch. Wenn also die Typsierung als stark und/oder schwach angegeben wird oder ALGOL als Einfluss aufgezählt wird, erwarte ich dazu auch Text im Artikel. --Zahnradzacken (Diskussion) 14:14, 30. Jun. 2012 (CEST)

Dass Sunks keine Ahnung haben soll, ist mir aus dem Diskussions- und Bearbeitungsverlauf nicht ersichtlich. Bitte nicht zurücksetzen, außerhalb der Infobox fanden sehr viele Verbesserungen statt. Seine Bearbeitungen haben zu einem sehr großen Teil in der Tat eine Berechtigung, etwa, dass es wirklich verschiedene Auffassungen von (starker|statischer|sicherer) Typisierung gibt, die je nachdem einen anderen Infoboxeintrag implizieren würden. Dass in der Tat die Liste der Beeinflussten keinen Anspruch auf Vollständigkeit haben kann, dass in der Tat der Erscheinungsjahreintrag unterschiedliche Optionen lässt. Dies ist jedoch ein grundsätzliches Problem solcher Infoboxen, das man, meiner Meinnug nach, wie ich auch schon einmal gesagt habe, nicht dadurch lösen sollte, dass man nur noch völlig nutzlose Informationen stehen lässt, statt dessen sollte man festlegen, nach welchen Kriterien die Einträge auszuwählen sind (die Probleme gibt es auch in ganz anderen Gebieten – ich brachte das Beispiel Geographie, zählt man bei einer Einwohnerzahl die Metropolregion? Kann Englisch als Amtssprache der USA bezeichnet werden? Wie sind Staatsform und Regierungssystem zu bezeichnen?). Notwendig ist meiner Meinung nach daher eine Grundsatzdiskussion, wie man damit umgehen soll und am besten, wenn es Zustimmung dafür gibt, die Festlegung von Kriterien für die Infoboxen. Es scheint mir unausweichlich, wenn man denn Infoboxen haben möchte, was bislang die gängige Praxis war.

Unangenehm überrascht bin ich allerdings davon, dass er nun auch in anderen Artikeln ohne weitere Rücksprache in anderen Artikeln Informationen aus Infoboxen löscht. Hier teilte er mir mit, dass er keine Grundsatzdiskussion führen wolle, weil er lediglich an diesem Artikel interessiert sei und etwa im Artikel C (Programmiersprache) nichts ändern wolle, obwohl er das zu diesem Zeitpunkt bereits getan hatte. Und nun macht er auch noch bei anderen Artikeln weiter. Seine jüngsten, von PerfektesChaos aufgeführten Änderungen wurden zum Glück revertiert. --Chricho ¹ ² ³ 14:41, 30. Jun. 2012 (CEST)

Bei den Eingriffen ging es um die Beleglage. Da sind die Wikipediaregeln eigentlich sehr klar, und eine Grundsatzdiskussion muss deshalb nicht auf's Neue geführt werden. --Sunks (Diskussion) 16:20, 2. Jul. 2012 (CEST)

Ich denke auch nicht, dass wir auf Mai zurücksteigen sollten. Nicht alles was seitdem geschreiben wurde ist schlecht, das was schlecht ist wird mit der Zeit wieder rauskommen.

Ich denke aber, dass wir das Treiben von Sunks genau beobachten sollten (ich werde das auf jeden Fall machen & bei gegebenen Anlässen reverten (wie bei seinen globalen Infoboxänderungen) & nehme da natürlich auch Sunksche Vandalismusmeldungen in Kauf). Ich denke zwar nicht das Sunks keine Ahnung hat (vielleicht haben mich seine Methoden aber verblendet), sein Umgang mit Entscheidungsprozessen in der Wikipedia ist allerdings fragwürdig. --Sebastian.Dietrich ✉ 17:05, 30. Jun. 2012 (CEST)

<Quetsch> Ich fürchte die Diskussion mit Sunks führt zu keinem grünen Zweig. Wie PerfektesChaos anmerkt spiegelt er meist nur meine Aussagen ohne selbst (neue) Argumente zu bringen. An Diskussionsergebnisse hält er sich ja nachgewiesenermaßen ohnedies nicht. Was also tun mit ihm bzw. mit dem Artikel? --Sebastian.Dietrich ✉ 17:45, 2. Jul. 2012 (CEST)

(Am besten mit WikEd oder Schnark-Diff zu vergleichen)

• 34.644 bytes 2012-05-20 → 27.579 bytes 2012-06-28 – Kürzung um 20%

Die Löschungen gehen weitaus überwiegend auf Sunks zurück.

• Ich habe überhaupt nichts dagegen, wenn mal etwas knapper, klarer formuliert wird. Hier geht es um etwas anderes.
• Die inhaltlichen Löschungen von Sunks sind im Alleingang erfolgt; sie wurden zuvor nicht auf der Disku abgestimmt. Sofern die laufenden Löschungen anschließend überhaupt ansatzweise auf der Disku thematisiert wurden, hatte Sunks dann bereits weiter gelöscht, bevor ein Konsens gefunden war und als es noch deutlichen Widerspruch gab, und gleichzeitig schon die nächsten Abschnitte des allgemeinen Textes gelöscht (ich meine nicht die Kurz-Zusammenstellung in der Infobox).
• Inhaltliche Neugestaltungen durch Sunks kann ich nicht finden – bestenfalls Umformulierung der Überreste; ansonsten eigenmächtige Löschung, Löschung, Löschung, ...
• Derart grundlegende Überarbeitungen von Artikeln laufen anders ab; nicht ohne irgendeinen konkreten Anlass oder eine vorherige Absprache über Ziele und Vorgehen.
• Ich denke, dass jetzt eine Bestandsaufnahme erforderlich ist.

Schönes Wochenende --PerfektesChaos 20:11, 30. Jun. 2012 (CEST)

Eine (ungefragte, grundsätzliche) dritte Meinung

Ich habe mir gerade die Diskussion durchgelesen und möchte alle Beteiligten zu Besonnenheit aufrufen. So ist es zwar richtig, dass Unbelegtes entfernt werden darf, aber es ist durchaus Konsens in Fällen, wo Quellen zu erwarten sind erst die Löschung in der Diskussion oder per Vorlage anzumahnen und eine gewisse Frist verstreichen zu lassen, bevor man dann selber löscht. Ein mehrmaliges Missachten dieses Konsens könnte als Vandalismus gesehen werden und zeitnah auf WP:VM vorgelegt werden. Dort wird dann etwa der Artikel gesperrt, bis in der Diskussion ein Konsens gefunden wurde.

Zweitens sollten sich alle Beteiligten aber ebenso ins Gedächtnis rufen, dass die Wikipedia nur gesichertes Wissen abbilden kann und soll. Eigene Überlegungen sind also nicht erlaubt, so einfach das auch manchmal scheint (und eventuell ist). Hier sei exemplarisch auf den Abschnitt "Typisierung" verwiesen. Der korrekte Weg wäre, passende Literatur zu sichten und dann die Einschätzung, die ein reputabler Autor vornimmt in den Artikel zu übernehmen. --engeltr 01:48, 4. Jul. 2012 (CEST)

Bin ganz bei dir. Belegt (durch passende Literatur & reputable Autoren) sind Erscheinungsjahr, Entwickler, Beeinflusste, Wurde beeinflusst und Implementierung. Dennoch geht die Diskussion weiter und weiter und weiter. --Sebastian.Dietrich ✉ 09:03, 4. Jul. 2012 (CEST)

Ich werde mich aus zeitlichen Gründen an dieser Diskussion für eine Weile nicht weiter beteiligen können. Aber irgendwann geht es weiter. Ich wünsche allen Beteiligten einen guten Start in die Woche. --Sunks (Diskussion) 06:44, 9. Jul. 2012 (CEST)

Erläuterung der Präprozessor-Direktive im HW-Programm

Guten Tag!

Mir ist aufgefallen, dass der Präprozessor nicht angesprochen wurde. Bitte einen Link zum Wiki-Artikel oder eine minimalistische Erklärung des Aufbaus wären toll.

MfG, --79.210.126.203 12:38, 7. Okt. 2012 (CEST)

Bjarne Stroustrup

Selbst nach langer Recherche finde ich nichts außer der Aussage von Herrn Stroustrup SELBST, was darauf hinweist dass er "Erfinder" von C++ ist. Er hat definitiv zu der Entwicklung große Teile beigetragen, aber muss man diesem selbstherrlichen Typ Raum auf Wikipedia geben? (schaut euch seine HP an, lest seinen Wikipedia Artikel...)

--95.90.250.180 01:37, 30. Nov. 2012 (CET)

Lieber Benutzer 95.90.250.180, ist dir in deinen langen Recherchen denn ein Widerspruch untergekommen, dass jemand anderes (seinerseits belegbar!) angibt, (wesentlicher) Erfinder von C++ zu sein?

Dann sind wir hier durchaus bereit, Herrn Stroustrup auf einen -hm- z.B. "wesentlichen Mitentwickler" umzustufen.

Auch ein selbstherrlicher Mensch kann Erfinder einer Programmiersprache sein... --arilou (Diskussion) 09:13, 30. Nov. 2012 (CET)

- 2013 -

direkter Befehl

Was meinst du mit "direkten Befehlen"? Es gibt überhaupt keine Befehle in C++. :-/ --RokerHRO (Diskussion) 15:06, 6. Feb. 2013 (CET)

if
for
do
while

Operatoren + - * /

Zuweisung =

Wie nennst du sowas? Eine bessere Bezeichnung als "direkter Befehl der Sprache" darf gerne in den Artikel.

--arilou (Diskussion) 17:09, 6. Feb. 2013 (CET)

Das was du da aufführst, würde ich als Sprachkern bezeichnen. Dieser ist in C++ aber gerade nicht größer oder kleiner wie in anderen Sprachen. Vielmehr ist dieser in C, C++, C# und auch Java ungefähr gleich groß. Was sich deutlich unterscheidet, ist die Größe der Standardbibliothek. Diese ist in C++ sehr klein im vergleich zu .NET oder Java. Ich habe die Änderung deshalb zurückgesetzt. --Steef ³⁸⁹ 21:26, 6. Feb. 2013 (CET)

C,C++,C# und Java sind ja auch gerade die Beispiele, welche aus der C-Welt stammen... Schon mal Pascal, Basic, Lisp, Fortran oder Assembler programmiert ? Ich habe in all diesen Sprachen (und auch C,C++,Java,C#,Python) schon gearbeitet.

"Dieser ist in C++ aber gerade nicht größer oder kleiner wie in anderen Sprachen." ist eine Behauptung deinerseits (siehe auch WP:TF). Vergleich doch mal mit Fortran oder Basic, wo File-IO, Stringbehandlung, trigonometrische Funktionen, Textein-/ausgabe, z.T. Grafikausgabe direkt Bestandteile des "Sprachkerns" sind...

--arilou (Diskussion) 08:32, 7. Feb. 2013 (CET)

"Schlüsselwort". So wie es jetzt dasteht ist es einfach nur grausig. --85.199.24.165 10:29, 8. Feb. 2013 (CET)

Hab's jetzt zu "Schlüsselwort" geändert, so gefällt mir's auch besser. --arilou (Diskussion) 09:26, 13. Feb. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:26, 13. Feb. 2013 (CET)

Schwachpunkte

Die unter "Im Design der Sprache gibt es aber auch einige Schwachpunkte, die bei ihrem Einsatz berücksichtigt werden müssen.[2] Einige davon sind:" genannten Punkte sind Eigenschaften. Der Zweite, "unvollständige Objektorientierung", ist eine Unschönheit. Was aber ist an der OO "unvollständig"? Datenkapselung bedeutet nicht: "Der Benutzer darf nur das öffentliche Interface kennen", sondern: "Der Benutzer kann nur das öffentliche Interface benutzen". Die beiden anderen sind eben Eigenschaften und per se weder Vorzug noch Schwachpunkt. Analog möge man bitte im Artikel "Schusswaffe" darauf hinweisen, daß es im Design ebendieser auch einige Schwachpunkte gibt, die bei deren Einsatz berücksichtigt werden müssen. Einige davon sind: Man kann sich damit ins Bein schießen. Sie haben in der Regel ein endliches Magazin. Sie sind zum Brötchenbacken ungeeignet. --85.199.24.165 10:29, 8. Feb. 2013 (CET)

Manchmal ist aber durchaus gewünscht, dass der Benutzer tatsächlich nur das öffentliche Interface kennt, z.B. wenn eine Bibliothek zugekauft wird, und die interne Umsetzung Firmengeheimnis des Lieferanten bleiben soll.

--arilou (Diskussion) 10:58, 8. Feb. 2013 (CET)

-> pimpl. Hat aber mit Vollständigkeit der Abbildung des Konzepts OO nichts zu tun.

--85.199.24.165 11:53, 8. Feb. 2013 (CET)

Da gebe ich dir Recht. Eine Kritik ist's allerdings trotzdem. --arilou (Diskussion) 09:33, 13. Feb. 2013 (CET)

Wenn OO korrekt umgesetzt wäre bräuchte man PIMPL nicht. Genau dass ist ja die Kritik. --TT (Diskussion) 15:10, 9. Apr. 2013 (CEST)

Außerdem verhindert es, dass Intelligenzbolzen auf die Idee kommen, dass man doch unregulär auch von außen auf private Daten zugreifen könnte, wenn sie denn "sowieso bekannt" sind... (alles schon erlebt!)

--arilou (Diskussion) 10:58, 8. Feb. 2013 (CET)

Erleben tut man viel. Zugriff auf private member gibt's trotzdem nicht.

--85.199.24.165 11:53, 8. Feb. 2013 (CET)

Es ist sogar noch schlimmer: Ich kann jedes Objekt mittels Umweg über void in jeden anderen Typ casten. Allein die Tatsache dass das funktioniert zeigt schon wie schwach die OO in C++ ist. --TT (Diskussion) 15:10, 9. Apr. 2013 (CEST)

Nur das dieses Programm dann kein C++ mehr ist (undefiniertes Verhalten). --Florian Weber 23:44, 3. Mai 2013 (CEST)

es lässt sich doch aber mit jedem C++-Compiler übersetzten, warum soll es dann kein gültiges C++ sein? Die Kritik an C++ ist doch, dass sowas nicht verhindert wird. --TT (Diskussion) 13:52, 17. Mai 2013 (CEST)

Nein. Dir scheint nicht klar zu sein, was "undefiniertes Verhalten" (engl. "undefined behavior") in C++ bedeutet. Ein Programm, dass "undefiniertes Verhalten" (im Sinne der C++-Sprachnorm) enthält, ist kein gültiges C++-Programm. Punkt. (Einen Großteil von Quellcodekonstrukten, die zu "undefiniertem Verhalten" führen würden, können heutige C++-Compiler erkennen, für andere müssten sie quasi das Halteproblem lösen, was aber nicht möglich ist.) --RokerHRO (Diskussion) 18:03, 17. Mai 2013 (CEST)

Der nicht existierende Garbage Collector gilt i.A. wohl schon als Schwachpunkt, insbesondere bei Vergleichen mit anderen OO-Sprachen. Das kann bestimmt mit etlichen Literaturstellen belegt werden, hab' ich aber gerade keine Lust dazu. --arilou (Diskussion) 11:05, 8. Feb. 2013 (CET)

Abgesehen davon, daß ich dir nicht zustimme: Wer sprach von GC?

--85.199.24.165 11:53, 8. Feb. 2013 (CET)

Eine Kritik ist "hat kein Speichermanagement". Es ist korrekt, dass "Speichermanagement" nicht zwangsweise auch einen GC umfassen muss; ein -hm- vernünftiges, komplettes beinhaltet aber einen GC. Und dass das Fehlen von Speichermanagement und GC oft als Nachteile von C++ aufgefasst werden, dafür lässt sich mit Sicherheit so manche Literaturstelle finden. --arilou (Diskussion) 09:33, 13. Feb. 2013 (CET)

Die Aussage das keine Unterstützung für Speichermanagment exisitiert ist in jedem Falle falsch (RAII ist eine Form von Speichermanagment). Korrekt ist, dass das Nichtvorhandensein einer GC oft kritisiert wird. Ich habe den Artikel mal entsprechend angepasst. --Florian Weber 23:44, 3. Mai 2013 (CEST)

Nachdem keine (Gegen-)Argumente mehr kommen: Schaut euch mal den Abschnitt http://en.wikipedia.org/wiki/C%2B%2B#Criticism in en an. Das ist Kritik. --89.144.192.101 23:26, 9. Feb. 2013 (CET)

Ich hab' auch noch anderes zu tun, als nur WP zu beobachten. Antworten können schon mal 3-4 Tage dauern. ~Geduld~ ist eine Tugend. --arilou (Diskussion) 09:33, 13. Feb. 2013 (CET)

Die engl. WP hat andere Anforderungen bezüglich Quellen und Meinungen. Die persönliche Meinung einer Einzeplerson, die C++ weder benutzt noch sich an der Weiterentwicklung der Sprache irgendwie konstruktiv beteiligt hat, hat in einem C++-Artikel IMHO z.B. nichts zu suchen. --RokerHRO (Diskussion) 18:01, 11. Feb. 2013 (CET)

"[...] Die persönliche Meinung einer Einzeplerson, die C++ weder benutzt noch sich an der Weiterentwicklung der Sprache :::irgendwie konstruktiv beteiligt hat [...]

Soll /ich/ mich hier angesprochen fühlen!?

--85.199.24.165 12:34, 3. Apr. 2013 (CEST)

Ich habe den Link auf die fqa rausgenommen, weil diese Seite definitiv nicht auch nur ansatzweise in die Kategorie reputable Quelle fällt. Eine erste Erklärung findet sich hier: http://stackoverflow.com/questions/3171647/errors-in-c-fqa

Es wäre aber in der Tat schön, fundierte Kritik verlinken zu können. --Florian Weber 23:44, 3. Mai 2013 (CEST)

Sowas scheint aber irgendwie rar zu sein. Mir wäre "Kritik von innen" (also von Leuten, die C++ gut(!) kennen und damit auch arbeiten, möglicherweise sogar mitentwickelt haben) lieber als "Kritik von außen", da letztere eben meist sehr oberflächlich und schnell persönlich und damit unsachlich wird. --RokerHRO (Diskussion) 23:56, 3. Mai 2013 (CEST)

Da wird sich doch gar nicht mit C++ auseinander gesetzt sondern damit, was über die Sprache veröffentlicht wurde. Unter "Kritik" verstehe ich was anderes... --TT (Diskussion) 15:10, 9. Apr. 2013 (CEST)

Hello World

In der damaligen Diskussion wurde beschlossen, dass das Hello-World den ostream-Header einbinden soll. Allerdings mit dem Hinweis, dass das entfernt werden kann/soll sobald es im nächsten Standard nicht mehr nötig ist. Letzterer ist nun schon eine ganze Weile erschienen und dieser Aspekt wurde auch schon zu C++98-Zeiten von praktisch allen Implementierungen umgesetzt. Da dieser Artikel C++ und nicht C++98 behandelt und das Ganze ohnehin eher ein Bug im Standard war, würde ich diesen include, sofern es keinen Widerspruch gibt, in den nächsten Tagen löschen. --Florian Weber 23:54, 3. Mai 2013 (CEST)

done --Florian Weber 00:37, 5. Mai 2013 (CEST)

Links

Ich habe eben mal den TAMU-Link aus dem Artikel genommen, da dieser nicht mehr funktioniert hat. Damit verbleiben noch drei Links auf externe Seiten. Sofern sich niemand meldet würde ich zu diesen die Folgenden hinzufügen:

• http://www.stroustrup.com/ Webseite von Bjarne Stroustrup mit dessen FAQs und starkem C++-Fokus.
• http://www.parashift.com/c++-faq/ Dürfte die ausführlichste, beste und strukturierteste FAQ zum Thema sein.

Ansonsten gäbe es natürlich noch den wirklich exzellenten Talk von Bjarne auf der Going Native. --Florian Weber 23:57, 15. Mai 2013 (CEST)

+1 --Sebastian.Dietrich ✉ 00:50, 16. Mai 2013 (CEST)

done --Florian Weber 20:32, 17. Mai 2013 (CEST)

"Kritik"

Mit der Tatsache im Hinterkopf, dass ich hiermit ein sensibles Thema anspreche: Ich habe einen Abschnitt "Kritik" geschrieben, da ein solcher in einer Rückmeldung gegeben wurde. Ich habe die obige Diskussion nur überflogen, aber noch mitgekriegt, dass "Kritik von innen" gut wäre. Insofern: Ich bin C++-Programmierer, würde mich auch als halbwegs erfahren bezeichnen (Babel-artig: C++-3 oder -4) und bin wirklich aufgeschlossen. Nichtsdestotrotz gibt es natürlich an jeder Sache in der Welt Kritikpunkte. Was meint Ihr zu meinem Abschnitt? Ich habe versucht, ein paar Belege einzubauen, sodass klar wird, dass nicht nur ich der Meinung bin ;) Verzeiht mir, wenn ich ab und zu den Konjunktiv I vergessen habe, und schaut ihn Euch generell mal kritisch an. Solche Abschnitte finde ich in der Wikipedia immer am schwersten zu schreiben. --Der Messer ^{meckern? - loben?} 12:40, 20. Mai 2013 (CEST)

Auch „Kritik von innen“ sollte belegt werden. Und ein "ich bin selber C++-Programmierer" taugt leider nicht als zitierfähige Quelle. Und du hast für deine vielen Behauptungen nur eine einzige mit einer Quelle ausgestattet, wobei mir beim ersten Überfliegen nicht klar geworden ist, ob es eine "Kritik von innen" ist oder von außen. --RokerHRO (Diskussion) 11:58, 21. Mai 2013 (CEST)

Besser wäre mMn eine Übersetzung des (recht gut belegten) Abschnittes aus http://en.wikipedia.org/wiki/C%2B%2B#Criticism --Sebastian.Dietrich ✉ 13:25, 21. Mai 2013 (CEST)

Mich überkam die typische Situation, dass ich die Dinge schon tausendmal gelesen habe, die tatsächlichen Quellen leider aber gerade in dem Augenblick nicht mehr fand. Da ich in Eile war, wollte ich den Text einfach schnell mal wegspeichern und Euch zur Diskussion überlassen (den Wartungsbaustein habe ich vergessen, danke RokerHRO). Ich versuche noch, ein paar Quellen zu finden; in der englischen Wikipedia gibt es einige vielversprechende Links. --Der Messer ^{meckern? - loben?} 13:48, 21. Mai 2013 (CEST)

Was meint Ihr hierzu: http://forum.golem.de/kommentare/opensource/canonical-ubuntu-phone-angekuendigt/c-c-als-programmiersprache-ist-problematisch/69679,3214014,3214014,read.html ? Als Foren-/Diskussionsbeitrag gerechtfertigt für "Kritik", da sie ja "aus dem Volke" kommt. --Der Messer ^{meckern? - loben?} 13:54, 21. Mai 2013 (CEST)

Forenbeiträge taugen nicht als Quelle. Es ist halt das gleiche, ob Wikipedia-Autor X seine Meinung kundtut oder Forenteilnehmer Y. --RokerHRO (Diskussion) 22:57, 21. Mai 2013 (CEST)

Da widerspreche ich: Wenn es ein Forenbeitrag ist, dann fand die WP:TF woander statt. --Der Messer ^{meckern? - loben?} 16:47, 24. Mai 2013 (CEST)

Es geht nicht darum, wer wann wo TF betreibt, sondern ob die Aussagen aus einer glaubwürdigen Quelle stammen. Ein Forumsbeitrag mag geeignet sein, um eine Meinung zu belegen oder dass darüber gesprochen wird - er ist jedoch hier nicht geeignet, um in diesem Fall sachliche und fundierte Kritik zu üben.

Mal davon abgesehen, dass der Forumsbeitrag einfach nur das übliche Geweine eines Java-Jüngers ist. --Plankton314 (Diskussion) 18:38, 24. Mai 2013 (CEST)

Die Frage ist nun, was als Kritik zählt. Fundiert ist die Kritik allemal -- die genannten Fakten sind wahr. Nur weil manche Personen die beschriebenen Effekte als Vorteil sehen (gibt es ja auch), existiert die Kritik immer noch als solche und sollte auch so aufgeführt werden. Und ja, natürlich ist es das Rumheulen eines Java-Programmierers, der Angst vor jedem bisschen Maschinennähe hat, aber nur weil es Linuxer gibt, die wegen Windows rumheulen, sollten Kritikpunkte, die auch von den Heulenden benutzt werden nicht allgemein verworfen werden. Versteht Ihr, was ich meine? Ich habe das Gefühl, dass ich meinen Punkt nicht richtig rüberbringen konnte... Wie auch immer :) --Der Messer ^{meckern? - loben?} 21:49, 25. Mai 2013 (CEST)

Ich denke/hoffe doch zu verstehen was du meinst :)

Im Grunde ist es ja auch nicht die Kritik an sich das Problem, sondern nur wo und wie sie geäußert wird. Ich bin mir sicher, dass für jeden herangetragenen Forenbeitrag über die Schwächen von C++ ebenso einer hervorgekramt werden kann, der genau das als Vorteil herausstellt.

Wie SD oben schrieb, wäre der Artikel [27] mit Niklaus Wirth aus der EN-WP wohl ein guter Anfang. Und weiterhin werden sich schon einige Coding-Blogs finden, die etwas Kritik kompetent darstellen. --Plankton314 (Diskussion) 14:50, 26. Mai 2013 (CEST)

Ich denke, dass (soblad hier genügend Nachweise angeführt wurden) der Unterabschnitt aus dem Abschnitt "Design" hier her gehört. --TT (Diskussion) 10:42, 22. Mai 2013 (CEST)

Ich habe mal Tatsachenbehauptungen durch „Kritiker empfinden“ ersetzt (ich persönlich empfinde C++ definitiv nicht als fehleranfälliger als andere Sprachen. Damit ist die Aussage, dass dem so sei, ohne gute Quelle in dieser Endgültigkeit nicht haltbar (Ein Gegenbeispiel genügt sonst)). Pointerwerden nicht dermaßen unisono kritisiert, dass ich das in dieser Form ohne Quelle nennen würde. Die Aussage, dass es schwer ist, gut zu programmieren ist so allgemein, dass se für jede Sprache stimmt. Das Bjarne-Quote würde ich eher in den Design-Bereich verschieben, da ein solches Verhalten gewünscht sein kann (Wenn ich beispielsweise zeigen kann, dass Zugriffs-checks für ein bestimmtes Array unnötig sind, will ich möglicherweise nicht dafür zahlen; dabei nehme ich aber bewusst in Kauf, dass ein Bug an dieser Stelle dem Programm erlaubt die Weltherrschaft zu übernehmen). Der letzte Satz ist so allgemein und unspezifisch, dass man ihn konkretisieren sollte (Präprozessor, schwache Typisierung von Build-in-Typen, char* an viel zu vielen Stellen, einige Ausöser für undefiniertes Verhalten (etwa die Verwendung von uninitialisierten Variablen, auch wenn dies theoretisch sicher wäre (etwa lesen des Wertes)), Type-Promotion-Regeln, …) --Florian Weber 23:35, 23. Mai 2013 (CEST)

Ich finde den Kritikversuch an sich ja prima, nur trägt er nicht.

C++ ist nicht fehleranfälliger als andere Programmiersprachen. Programmieren fängt im Kopf an, und meiner unmaßgeblichen Erfahrung nach scheitern Anfänger daran, dass sie nicht gründlich genug darüber nachgedacht haben, was sie eigentlich wollen. pebkac, hat nichts mit einer konkreten Programmiersprache zu tun. Java ist einfacher zu lernen, aber das Fehlen von Mehrfachvererbung ist für mich oft unangenehm, genauso wie die Trümmer generischer Programmierung. Das im angewandten C++ generische Programmierung zu- und OOP abnimmt, hat ja solide Gründe.

Mit der Behauptung, c++ wäre fehleranfällig, kann ich gar nix anfangen. Was ist eine fehleranfällige Programmiersprache?

Viele low-level-Funktionen hat c++ auch nicht, sondern nur eine: Zeiger. Ohne geht es nunmal nicht, Java verbirgt die nur. Weder Zeiger noch die fehlende GC sind so ein Problem: Man schachtelt alles in Klassen, und was man an Speicher manuell anfordert (kommt auch in c++ nicht so oft vor) das gibt man im Destruktor wieder frei. Den aufzurufen übernimmt der Compiler. Statt auf Zeige greift man ganz überwiegend auf Referenzen zurück, die sind typsicher.

Das Zitat bringt es exakt auf den Punkt, dem ist eigentlich nichts beizufügen.

Weiterhin greift man nicht auf "höhere Sprachen" zurück, die Meinung, c++ wäre lowlvl kommt stets von Laien, die meinen, c++ wäre im Grunde ein aufgebohrtes c. c ist lowlvl (und soll das auch sein). C++ ist eine Sprache, die gradezu darauf getrimmt ist, große Projekte umzusetzen, soweit eine Sprache dabei überhaupt helfen kann. Im Gegensatz zu Java hat c++ eine kleine Standardbibliothek, das nimmt bei einer Sprache, die den Programmierer möglichst wenig bevormunden will, aber auch nicht Wunder. Für C++-Entwickler ist es völlig üblich, sich Bibliotheken für bestimmte Probleme zu ergoogeln, der Umfang der mitgelieferten Bibliotheken hat mit der Sprache selbst recht wenig zu tun. Eben deshalb ist C++ weitgehend mit C kompatibel. Java ist ganz einfach ein im Sprachumfang beschnittenes c++.

Letztens: Die Ausführungsgeschwindigkeit von Programmen ist auch heute noch wichtig, genauso wie sparsamer Hauptspeichergebrauch und Stromsparen.

Das es so etwas wie Java gibt, hat einen einfachen Grund: Programmiererzeit ist teurer als Programmzeit, C++ ist schwer zu lernen und hat eine sehr steile Lernkurve.

Auf der anderen Seite ist allerdings auch auffällig, dass c++ meistens verwendet wird, "wenn es drauf ankommt", Java hingegen gerade dann nie. Schön, dass es einen GC gibt, aber keiner verwendet Software von Programmieren, die sowas brauchen, für kritische Bereiche. Wer weiß, wo da sonst noch Pfusch lauert, gegen den die gewitztesten Sprachdesigner machtlos sind.

Wem es darum geht, Programmieren zu lernen, wem es darum geht, relativ schnell kleinere Anwendungen zu schreiben, der ist bei Java gut aufgehoben, für diejenigen die das Thema "Programmieren" ausreizen wollen oder müssen, führt an C++ jedoch kein Weg vorbei. Java wurde aus der Erkenntnis heraus geschaffen, dass der Alltag der Mehrzahl der Programmierer keine eierlegende Wollmilchsau braucht, eine ökonomische Frage, keine theoretische.

</innenansicht> Tmtx (Diskussion) 22:32, 6. Mai 2014 (CEST)

Jedem seine Meinung.

1. "Was ist eine fehleranfällige Programmiersprache?"
   Ein Maß dafür, wie schwierig es ist (für einen Programmierer mit Erfahrung n, z.B. 1000 Stunden), ein fehlerfreies Programm zu erstellen. Und das hat sehrwohl etwas "mit einer konkreten Programmiersprache zu tun", nämlich damit, wie einfach sie zu erlernen ist, wie gut der Compiler Fehler findet, ob man sinnvolle Fehlermeldungen erhält, ob sie stark typisiert, ob sie zur Laufzeit Array-Zugriffe auf Indexgrenz-Einhalten prüft, usw.
2. "die fehlende GC [ist kein] Problem" - im Allgemeinen nicht. In seltenen Fällen aber durchaus (hab' ich persönlich erlebt).
3. "C++ ist eine Sprache, die gradezu darauf getrimmt ist, große Projekte umzusetzen" - das ist nicht wirklich dein ernst, oder?!?
   Manche (Fremd-)Bibliotheken wollen statisch gelinkt werden, andere dynamisch. Die eine benötigt Bibliothek-X in Version 2, die andere will ebenfalls zusammen gelinkt werden mit Bibliothek-X, aber bitte Version 3 - willkommen in der Linkerhölle.
   Manche wollen Strings als 0-terminierte UTF-8, andere möchteneinen Struct { (unsigned short*) (2-Byte-Unicode-Array) ; unsigned int LEN }. Und schon ist man am hin- und herwandeln von Strings, nur weil die DirectX-Bibliothek sie anders haben will als die Netzwerk-Lib und der Xml-Parser 'ne dritte Variante liefert.
   Und wo der Xml-Parser voll-IEEE754-konforme Gleitkommazahlen liefert, unterstützt die Physik-Effekt-Bibliothek die nur teilweise, und kann mit manchen speziellen Werten nichts anfangen, die der Xml-Parser liefert.
   Da lobe ich Javas umfangreiche Standardbibliothek, deren Komponenten harmonieren nämlich miteinander.
4. "Die Ausführungsgeschwindigkeit von Programmen ist auch heute noch wichtig" - du unterliegst also auch noch dem veralteten Glauben, Java wäre langsam? In vielen Fällen ist heute Java schneller als C++ und schneller als C, da ein JIT-Compiler zur Laufzeit Optimierungen vornehmen kann, die zuvor nicht möglich sind. Beispielsweise kann eine Arrayindex-Prüfung weggelassen werden, wenn (z.B. nach dem Festlegen entsrechender Variableninhalte (z.B. Einlesen einer Konfigdatei)) sicher ist, dass die Grenzen nicht verletzt werden können.
   "Auf der anderen Seite ist allerdings auch auffällig, dass c++ meistens verwendet wird, "wenn es drauf ankommt", Java hingegen gerade dann nie." ~ v.a. von Personen, deren Wissensstand bzgl. Java deutlich veraltet ist.

Wie gesagt, jedem seine Meinung. Und ja, ich verwende v.a. Java, unter anderem, weil ich zuvor jahrelang C/C++ verwenden musste.

Meine Meinung? C/C++ für hardware-nahe Anwendungen (Treiber, Betriebssystemkomponenten) - für alles andere gehört's in die Tonne ~ man ärgert sich andauernd mit Problemen rum, die's bei Java einfach nicht gibt.

--arilou (Diskussion) 11:57, 7. Mai 2014 (CEST)

Mir ging es ja gerade darum, dass der Kritikabschnitt POV ist (offenbar sind wir da ja einer Meinung), und das der einzige objektive Kritikpunkt die steile Lernkurve ist (siehst du ja genauso).

1. eine schwer zu lernende Programmiersprache ist schwer zu lernen, nicht fehleranfällig. Computer machen keine Fehler, sie tun, was man ihnen sagt. Fehler macht der Programmierer :-)
   Das man C++ nach 1000 Stunden beherrscht, halt ich für ein wenig optimistisch. Das man nach 1000 Stunden Schwierigkeiten damit hat, fehlerlosen C++-Code zu schreiben, ist allerdings doch wohl stark übertrieben. Bei C++ gibts eine einfache Regel: Wenn es beginnt, unelegant oder kompliziert auszusehen, dann machst du vermutlich schon was falsch.
   Übrigens ist C++ stark typisiert, wenn du zum reinterpret_cast greifst, machst du ziemlich sicher Mist, wenn zu einen c-cast machst, ganz sicher. Steht auch in Stroustrups Buch, das ein C++-Interessent vor allen anderen lesen sollte. Das C++ keine Array-Grenzen prüft, stimmt. Nur das man Arrays selten nutzt, und wenn man die Container, die man eigentlich benutzen sollte, richtig verwendet, gibts gar kein Problem mit Überläufen. Überhaupt an Arrays zu denken ist ein Beispiel für "vorher nicht genau genug nachgedacht". Auch hier ist mit Stroustrups Zitat alles gesagt :-)
2. GC sorgt gern mal für Stalls im Zehntelsekundenbereich, und das nur um unfähigen Programmierern hinterherzuputzen. C hat auch keine GC, und dort regt sich keiner drüber auf, obwohl Speicherlecks bei C-Code wirklich ein Problem sind. Bei C++ nicht.
3. Zum einen verwechselt du Bibliotheken und Programmiersprache. Bibliotheken kommen in C und C++ von Drittanbietern. Wenn die etwas vermurksen musst du das schon denen zuschreiben. Zum anderen: Bevor du dich über die unterschiedlichen link-Arten erregst, solltest du dich lieber mal fragen, warum es die gibt. Übrigens hat das Linken mit Programmiersprache rein gar nix zu tun, gelinkt wird Object-code, kein Quellcode. Müsste einer, der sich mit C++ auseinandergesetzt hat, aber wissen. Im Übrigen will eine C++-Bibliothek string, nicht irgendwelchen mystischen Krimskrams. Und der ist weder nullterminiert (das wäre ein C-Konstrukt) noch irgendein struct-Gefummel (was auch C ist), und wie der string-Datentyp intern funktioniert, kannst du dir anschauen, wenn du willst, wissen braucht man das mit Sicherheit nicht. Irgendwelches Einlesen oder Rausschreiben macht man mit streams und Iteratoren (also C++-Mechanismen allgemeinster Couleur), wie die Zeichenkette intern gespeichert wird, kann dir da so egal sein wie nur was. Wenn du wirklich eine nullterminierte Zeichenkette brauchst, gibts die Memberfunktion c_str(), außerdem gibts noch das Member data() zusammen mit length() oder size() womit sich dein struct ohne Schwierigkeiten basteln lässt. Sowas als Problembeispiele anzuführen ist doch wohl nicht dein Ernst, oder?
   Die DirectX-Libs, stammen von Microsoft und sind afaik C und nicht C++ (wenigstens die Schnittstelle), als Netzwerk-Lib greift man zu boost (auch das müsste ein erfahrener C++-Programmierer wissen). Das eine Physik-Bibliothek von A nicht mit einem XML-Parser von B zusammenarbeitet, dafür kann C++ nun auch nichts, übrigens sind Gleitkomma-Datentypen in C++ plattformspezifisch, auch das hat gute Gründe. double ist wenigstens so genau wie float, mehr ist nicht definiert. 'Das' wäre Sprache, und nicht 'Bibliothek A kann nicht mit Bibliothek B'.
   Das die Erfindung von Java Gründe hat, habe ich ja selbst geschrieben. Allerdings wurde Java nicht erfunden, um Programmierern das Leben zu erleichtern, oder meinst du wirklich, SUN verteilt Geschenke? Über die eigentlichen Motive von SUN kannst du ja mal in Ruhe nachdenken, und auch, ob die dir gefallen:-)
4. Auffälligerweise ist die genau die Argumentation seit Jahren die selbe. Java war noch keinen Monat raus, und schon wimmelte es von Leuten, die behauptet haben, man "unterliegt also auch noch dem veralteten Glauben, Java wäre langsam". Die wenigen, die sich dazu herabließen, diese offensichtlich so unsinnige "Behauptung" zu widerlegen, stellten dann ein auf Java optimiertes Laborproblem grottenschlechtem C/C++ gegenüber. Wenn man die Prämissen entsprechend wählt, kann man alles beweisen. Java übersetzt zur Laufzeit Bytecode in Maschinencode, ein Compiler produziert Maschinencode. Java ist schneller, weil es erheblich mehr Arbeit leisten muss, für jeden, der durchblickt, ist das offenkundig, alle anderen hängen veralteten logischen Vorstellungen an.
   Der Java-Interpreter (und nicht "Compiler") hat eine Stapelmaschine unter der Haube, sowohl x86 als auch ARM sind Registermaschinen. Java ist schneller, weil es von der zu Grunde liegenden Hardware zwangsläufig ungenügenden Gebrauch macht, wer das nicht einsieht, hängt einfach nur veralteten Vorstellungen an. Vorstellungen, die schon von Anfang an "jahrelang" veraltet waren. Du kannst nunmal einen Arbeitsschritt optimieren wie du willst, du wirst nicht schneller als einer, der ihn schlicht weglässt. Von den fantastischen Laufzeitoptimierungen habe ich unzählbar viel gehört, und noch nie etwas gemerkt. Mit dem Yeti ists ähnlich :-).
   Sogar Google hat auf Linux aufgebaut, statt ein OS in Java zu entwickeln. Warum wohl? Glaubt man den Java-Apologeten, dann kann Java auch nativen Code (was ja geht, nur wenig überraschend zu einer ziemlichen Fummelei ausarten kann), und das mindestens x mal schneller wenn nicht noch, wegen "Optimierungen". Die setzen Java halt genau so ein, wie mans gewöhnlich einsetzt, als gehobene Scriptsprache. Unter der Haube ist alles C/C++. Weils langsamer ist und für größere Projekte völlig ungeeignet. Klar. In reinem Java könnte man nicht mal die grafische Benutzeroberfläche bauen, die dein OS dir anbietet, zu langsam, zu speichergierig. Oder schreib doch mal einen Browser rein in Java :-)

Zu Personen, deren Wissensstand bezüglich Java veraltet ist, zähle ich btw nicht, ich verdiene mit Anwendungsprogrammierung meine Brötchen, da hat man nicht den Luxus, sich die Programmiersprache aussuchen zu dürfen.

Ich habe mich auch viel mit C++ herumgeärgert. Mein Ärger stellte sich hinterher immer als Unzulänglichkeit meinerseits heraus, und immer wenn ich ein Stück weiter durchgeblickt habe, habe ich vor allem gelernt, woran ich alles nicht gedacht habe.

Steile Lernkurve, eierlegende Wollmilchsau die im Programmieralltag oft den Aufwand nicht wert ist... Hab ich doch alles geschrieben :-( Tmtx (Diskussion) 00:46, 8. Mai 2014 (CEST)

Jungs, könntet ihr bitte euch mehr an WP:DS halten? Eure Meinungen zu C++ sind ja alle sehr interessant, aber überlegt bitte selbst, welcher Teil von euren Romanen wirklich der Verbesserung des Artikels dient. Ich fürchte, kein einziger. Können wir diese Diskussion also beenden, wenn niemad mehr etwas fruchtbringendes beitragen kann? --RokerHRO (Diskussion) 16:39, 8. Mai 2014 (CEST)

Wenn du unsere Diskussionsbeiträge nicht liest, dann kommentiere sie bitte auch nicht. Kritik am Artikel und Kritik an der Kritik dienen doch der Verbesserung, wär dir bei dem kontroversen Thema ein edit war lieber?Tmtx (Diskussion) 22:22, 8. Mai 2014 (CEST)

Ich habe sie gelesen. Und nur persönliche Meinungen, aber keinerlei verwertbare und mit Quellen belegte Aussagen (die man im Artikel dann einbauen könnte) gefunden. :-( --RokerHRO (Diskussion) 07:43, 9. Mai 2014 (CEST)

Man könnte das so verstehen, dass nun Quellen gesucht werden sollen, die die Punkte im Artikel widerlegen, das wäre eine seltsame Herangehensweise :-) Tmtx (Diskussion) 21:00, 9. Mai 2014 (CEST)

Geschwindigkeit C++ / Java

Quellen:

• c't 2003: Numerik, prozedurale Vorgänge
• c't 2003: OO-Vorgänge

Zitat:

"Die Hauptfrage war und ist natürlich:
Wenn jemand vorschlägt, eine Anwendung in einer der vier Programmiersprachen [Anmerkung: C++, C#, Delphi, Java] zu implementieren – lässt sich heute noch pauschal dagegenhalten, nein danke, damit _muss_ das ja fürchterlich langsam werden? Vor gar nicht so langer Zeit hätte man das in einigen Fällen durchaus noch sagen können:
3D-Ballerspiele schreibt man beispielsweise nicht in GW-Basic, sondern eben mit einer richtigen Programmiersprache. Diese Frage scheint uns mittlerweile klar beantwortet:
Sprüche wie „X nutzt ja gerade mal zehn Prozent der Maschinenleistung“ sind bei den von uns untersuchten Sprachen definitiv passé."

(Meint: Die vier Sprachen sind, sowohl im Bereich Numerik als auch bei OO-Vorgängen, meist auf Augenhöhe.)

Sowie: Zusammenfassung verschiedener anderer Veröffentlichungen, Java vs. C, v.a. Numerik . Insbesondere dieser Beitrag ist durchaus lesenswert, inkl. eines Abschnitts, warum "Java ist langsam" eine so verbreitete falsche Meinung ist.

--arilou (Diskussion) 09:56, 23. Mai 2014 (CEST)

Stimmt, aber diesen Ruf wird Java auch in 1000 Jahren nicht mehr loswerden Vorlage:Smiley/Wartung/:p  --Plankton314 (Diskussion) 11:24, 23. Mai 2014 (CEST)

Wenn man bedenkt wie alt diese Artikel sind und wie viele Performanceoptimierungen seit damals (2003 = Java 1.4) in die JVMs eingebaut wurden (und wie wenig sich bei C++ seit damals performancemäßig getan hat), dann sollte man eigentlich meinen, dass heute niemand mehr ernsthaft glaubt, dass Java langsamer als C++ wäre.

Aber das Gerücht hält sich hartnäckig. Wird immer wieder mit Aussagen wie "Java übersetzt zur Laufzeit Bytecode in Maschinencode, also muss es zwangsläufig langsamer sein" oder "Wenn Java so schnell ist, warum sind Betriebssysteme dann nicht in Java geschreiben?" oder "Java hat einen GC, also muss es langsamer sein" hinterlegt. Alles nichts neues, alles Blödsinn. Die Welt ist auch nicht flach, nur weil sie manchen mit ihrem beschränkten Horizont so vorkommt. Gerade weil Java erst zur Laufzeit Maschinencode erzeugt und weil es einen GC hat ist es schnell (bzw. oft schneller als C/C++). Und Betriebssysteme werden nicht in Java geschreiben weil Java plattform- und somit betriebssystemunabhängig ist. --Sebastian.Dietrich ✉ 11:34, 23. Mai 2014 (CEST)

Blödsinn, die Erde ist flach… Wenns in der Sache nicht geht, versuchts man rhetorisch. Auch Betriebssystemquellcode hat Partien, die in Assembler geschrieben sind, auch in C++ kann man keinen Interrupt aufrufen, auch in C++ keine Register lesen oder schreiben. Das weißt du ja noch aus dem Studium, wo du ein (rudimentäres) Betriebssystem selbst geschrieben hast. Das man bei einem Java-OS auch auf ein wenig C oder so zurückgreift, wäre gar nicht das Problem. Kernfunktionen eines OS sind nicht Treiber und Register, sondern Prozess-, Speicher- und Benutzermanagement. Sowas in Java zu schreiben kann ja wohl kaum unmöglich sein. Das ein GC langsamer ist als manuelle Verwaltung habe ich nicht geschrieben, nur, dass er spürbare Stalls verursacht. Der Umstand ist bei Echtzeitprogrammen (oder -teilen) ein wenig unangenehm. Und für Anwender die eine flüssige Handhabung schätzen. Für Numbercrunch-Aufgaben nimmt man ohnehin am liebsten ASM, aber die sind wohl doch eher eine Nische. Zum dem auch von dir geübten Argumentationsstil habe oben schon etwas geschrieben. Schon der erste Satz lässt auffällig jedes handfeste Argument vermissen, weil wers anders sieht als du, der peilts einfach nicht. Wie ich schon vorwegnahm, ziehst du in unbestimmtester Weise 'Performanceoptimierungen' herbei, die 'viele' sind, und, ich vermute, auch allergrößten Effekt haben. Substanz? Braucht man nicht, weil das ja jedem klar ist. Bis auf denen, die 'hartnäckigen Gerüchten' anhängen.

@arilou: Pay-content verlinken ist reichlich sinnlos, es wird keiner Geld ausgeben um mit dir zu diskutieren :). Und um mal die Qualität des anderen Artikels anzureißen: Consider what happens when you do a new/malloc: a) the allocator looks for an empty slot of the right size, then returns you a pointer. b) This pointer is pointing to some fairly random place. a) ja was denn sonst, b) ist einfach falsch. Wars auch 2003 schon. Und natürlich ist die Java-Speicherverwaltung (glibc-c&p) schneller als glibc. Btw nur mal als Denkanstoß: vector<> alloziiert normalerweise doppelt so viel Speicher wie eigentlich benötigt, wegen möglichem Zuwachs und der Speicherlokalität. Fantastische Optimierungskonzepte von Java sind auch anderen Systemen nicht fremd, schon deshalb, weil die STL- und Compilerentwickler in die Zukunft gereist sind um bei Java zu klauen :) Das bei Java viele nicht mehr benötigte Speicherblöcke gesammelt freigegeben werden ist ohne großen Wert, Weil 1. viele wirklich viele sein müssen und man 2. in C++ in solchen Fällen einen eigenen Allokator schreiben kann. In C, worauf is o.g. Dokument bezieht, sind Speicherpools für solche Probleme ohnehin üblich, siehe Linux-Quellcode. In C++ kann ich eigene Allokatoren schreiben, in C habe ich Speicherpools, und in Java? Braucht man das nicht. Hat man nicht zu brauchen. Btw hast du nichts Moderneres? Der Stand von 2003 ist wohl in keine Richtung mehr repräsentativ :) Tmtx (Diskussion) 22:38, 23. Mai 2014 (CEST)

Wir können jetzt natürlich alle deine Punkte einzeln durchgehen und dir zu jedem einzelnen Punkt einen leicht im Internet auffindbaren Artikel etc. beibringen. Aber mach dich bitte doch selbst auf die Suche. Arilou hat Artikel beigebracht, die schon 2003 belegten, dass Java keineswegs langsamer ist als C++. Wennst gut suchst, findest die Artikel auch ohne dafür zahlen zu müssen... Wennst also weiterhin das Gegenteil behauptest, dann bring uns Belege bei, dass das inzwischen nicht mehr der Fall ist. --Sebastian.Dietrich ✉ 00:37, 24. Mai 2014 (CEST)

Ich glaube nicht, das sich jemand von dir vertreten lassen braucht, oder war das pluralis majestatis? Du könntest alle meine Punkte einzeln durchgehen und mir zu jedem einzelnen Punkt leicht im Internet auffindbare Artikel etc. beibringen? Dann tu es doch einfach. Aber erzähl nichts von “ich könnte, hab nur keine Lust”, oder würdest du anderen so eine Haltung abnehmen? Das wirkt eher so, als wärst du bei deiner Suche wenig erfolgreich gewesen… Tmtx (Diskussion) 01:25, 24. Mai 2014 (CEST)

Wie wärs, wenn du mal was beitragen würdest? Es wurden bereits 3 Artikel verlinkt, die belegen, dass du Unrecht hast. Jetzt bist du dran mehr als nur deine Meinung abzugeben. --Sebastian.Dietrich ✉ 11:37, 24. Mai 2014 (CEST)

Nicht 'es wurden', sondern 'arilou hat'. Nicht du. Dein Beitrag besteht in blanken Allgemeinplätzen. Keine Quellen, keine Argumente. Du hast hier garnix zu fordern. Du hast mehr als deine Meinung abzugeben, statt “Haltet den Dieb” zu schreien. Ich stelle allerdings fest, das du erneut keine Belege hast. Wenn du welche gefunden hättest, würdest du wohl kaum zögern, sie mir unter die Nase zu reiben. Übrigens ist mir die (ziemlich prekäre) Quellenlage durchaus vertraut. Die Erkenntnis, das Java vs. C++ ein heiliger Krieg ist, führt zumindest bei mir dazu, keiner Seite vorbehaltlos zu glauben. Versuchs doch auch mal.

Dass ich das Alter der genannten Quellen betont habe, liegt daran, das es hier um den Artikel geht. Wenn man die als Quelle verlinkt, wird jemand kommen, der genau das kritisiert. Jemand, der, na sagen wir, nur mal beispielsweise, schreiben würde: Wenn man bedenkt wie alt diese Artikel sind und wie viele Performanceoptimierungen seit damals in die C++-Compiler eingebaut wurden (und wie wenig sich bei Java seit damals performancemäßig getan hat), dann sollte man eigentlich meinen, dass heute niemand mehr ernsthaft glaubt, dass Java schneller als C++ wäre.. Außerdem weiß ich nicht, ob es günstig ist, online-Payware als Quelle im Artikel zu verlinken. Und du wirst schon zugeben müssen, das in einem Thema, in dem sich in 11 Jahren viel getan hat (das behauptet unter anderem Sebastian.Dietrich) 11 Jahre alte Quellen vorsichtig ausgedrückt angreifbar sind. Tmtx (Diskussion) 21:50, 24. Mai 2014 (CEST)

Ich dachte Wikipedia wäre ein Gemeinschaftsprojekt. Wenn du jetzt forderst, dass jeder seine eigenen Quellen bringen muss und nicht auf die Quellen von anderen verweisen darf, dann muss ich wohl meine Vorstellung von der Wikipedia revidieren.

So und damit du ein bisschen zufriedener wirst hier die Quellen zu den Performancesteigerungen der JVMs und der Klassenbibliothek. Wie gesagt, leicht zu finden - Java 5 hier, Java 6 hier, Java 7 hier und hier, Java 8 hier. Bitte dich darum im Gegenzug dazu die Performancesteigerungen der C++ Compiler & C++ Klassenbibliotheken seit 2003 zu belegen. Achja - und wennst einen Garbage Collector haben möchtest der nie die Welt stoppt (und trotzdem concurrent & compacting ist - was es ja unter C++ nicht wirklich gibt), dann schau dir den Zing C4 Collector an. --Sebastian.Dietrich ✉ 00:56, 25. Mai 2014 (CEST)

Klar kann man “auf Quellen anderer verweisen”. Aber du kannst deine Forderungen nicht auf die Beiträge anderer gründen als wären es deine Beiträge. Es ist ein Unterschied, ob arilou, der ja was geliefert hat, sagen würde “und was hast du?”, oder ob du das tust, der vorher nichts mir ersichtliches geliefert hat. Du kannst ja schließlich auch nicht in fremder Sache Klage einreichen^^. Die Links schau ich mir morgen oder Montag an, nachts um 2 und paar Bierchen, das bringt nun nicht so viel. Ich habe btw nichts von Performancesteigerungen bei C++ geschrieben, ich wollte dir nur zeigen, das man deine Argumentation auch umdrehen kann. Ich habe dich ja nicht umsonst ‘zitiert’. Tmtx (Diskussion) 02:10, 25. Mai 2014 (CEST)

Der Punkt, den hier irgendwie kaum jemand / niemand sieht, ist, dass es nicht um Perfomance geht. C++ ist keine "perfomante" Sprache. Java ist keine "perfomante" Sprache. Keine Sprache ist "perfomant", dass ergibt überhaupt keinen Sinn. Es geht um Kontrolle. Mit Java ist es schwierig die Perfomance zu kontrollieren, weil es nunmal diverse Möglichkeiten dies explizit zu tun nicht gibt (hint: empirisch an GC-Einstellungen zu fummeln ist keine Kontrolle.). C++ bietet hingegen eine Fülle von Möglichkeiten die Perfomance zu kontrollieren. Wer das jetzt nicht verstanden hat, dem kann ich nicht wirklich helfen. (In vielen relevanten Fällen ist übrigens Java aus anderen Gründen nicht wirklich zu gebrauchen, häufig z.B. weil das *Buffer-Konzept überhaupt nicht auf die Anwendung mappt und man am Ende haufenweise Daten mindestens einmal durch die Gegend kopieren muss.) Phiarc (Diskussion) 00:00, 5. Nov. 2014 (CET)

Garbage Collection

Interessante Quellen zu GC der JVM:

• Die verschiedenen GC-Methoden, welche IBMs "J9"-JVM anbietet:
  http://www.ibm.com/developerworks/websphere/techjournal/1106_bailey/1106_bailey.html
• Java-GC für harte Echtzeit-Anwendungen:
  http://www.ibm.com/developerworks/library/j-rtj4/

--arilou (Diskussion) 14:06, 12. Jun. 2014 (CEST)

- 2014 -

return 0;

Wann wurde das denn aufgenommen? AFAIK war das Beispiel hier früher ohne return-Anweisung. --RokerHRO (Diskussion) 16:59, 11. Mär. 2014 (CET)

War wohl dieser Edit;

ist imo aber auch -hm- konformer, den return nicht wegzulassen.

--arilou (Diskussion) 08:43, 12. Mär. 2014 (CET)

Konform ist beides: Bei der main (und nur dort) darf man auf explizites return verzichten, obwohl der Rückgabetyp nicht void ist. Ich persönlich würde eher dazu neigen es rauszuwerfen weil es überflüssig ist. --Florian Weber 22:14, 24. Apr. 2014 (CEST)

WP-Artikel sind für WP:OmA; ich denke, zu Beginn sollte man solche Spezial-Einzelfall-Regeln möglichst nicht verwenden. --arilou (Diskussion) 08:51, 30. Apr. 2014 (CEST)

Wichtig?

"Wichtig für das Verständnis von undefiniertem Verhalten ist insbesondere, dass niemals nur eine einzelne Operation ungültig ist, sondern das gesamte Programm ungültig wird und kein wohlgeformtes C++ mehr darstellt."

Das mag wichtig sein, es ist auf jeden Fall unverständlich, bzw. klingt nach einem theoretischen, bzw. fast schon moralischen Gelaber vom sehr hohen Ross. --88.66.12.200 14:35, 11. Mai 2014 (CEST)

Ich stimme zu. Der ganze Abschnitt ist fragwürdig. Undefiniertes Verhalten bei Überlauf usw. ist in anderen Sprachen nicht anders, weil es auch Prozessorabhängig ist und daher nicht von einer Sprache definiert werden KANN. Ich traue mich daher, den Abschnitt herauszunehmen. Grüße, --Schotterebene (Diskussion) 15:56, 11. Mai 2014 (CEST)

gudn tach!

naja, es wird in verschiedenen programiersprachen unterschiedlich gehandhabt. wenn ich in python oder in perl auf ein nicht vorhandenes array-element zugreife, dann bekomme ich einen entsprechende exception bzw. warning ausgespuckt. ein zugriff auf a[-1] bzw. $a[-1] wird als zugriff auf das vorletzte element interpretiert und ist somit kein fehler und erzeugt auch kein undefiniertes verhalten. in c und c++ fliegt mir ein a[-1] hochkantig um die ohren... vielleicht... manchmal; gleiches gilt fuer a[array_size+123]. c und c++ sind unter den programmiersprachen schon besonders bekannt fuer undefiniertes verhalten, siehe auch w:en:Undefined_behavior.

es gibt also mindestens zwei gruende fuer den erhalt des abschnitts: 1. man kann den abschnitt nutzen, um unterschiede zu anderen programmiersprachen aufzuzeigen; 2. c und c++ sind quasi beruehmt dafuer, deswegen sollte der leser darueber informiert werden. -- seth 19:33, 11. Mai 2014 (CEST)

Diesen Abschnitt sollte man auf alle Fälle erhalten. Ein undefiniertes Verhalten von diversen Sprachkonstrukten ist bei anderen Programmiersprachen nicht üblich, sondern eher ein Alleinstellungsmerkmal von C++.

Zu behaupten, dass es ein undefiniertes Verhalten bei Überlauf in anderen Sprachen so wie in C++ gäbe ist einfach falsch. Java z.B. hat kein undefiniertes Verhalten bei Überlauf, Nullpointern, Arrayzugriffen mit ungültigem Index, bitweisen Verschiebungen etc. Für all die im Artikel genannten Beispiele gibt es ein exakt definiertes Verhalten das Compiler oder recherarchitekturunabhängig ist.

Wer sich mit C++ beschäftigt sollte schon wissen, auf welche Besonderheiten er in C++ achten muss, die in anderen Programmiersprachen exakt definiert sind. --Sebastian.Dietrich ✉ 23:14, 11. Mai 2014 (CEST)

In C erfolgt keine Typkontrolle und es gibt keine Exceptions, und deswegen folgt auf einen Fehler, eine "ungülige Operation", unvorhersehbares Verhalten. Das ist alles bekannt und beklagenswert, und wird aus guten und weniger guten Gründen akzeptiert, und das muß in den Artikel, alles klar.

Das ganze Programm aber deswegen als ungültig zu bezeichnen ist dummes Geschwätz. Das kann man so definieren, wenn man glaubt der liebe Gott zu sein, aber es hat keinerlei Konsequenzen. Theologie würde ich es nenenn, definitiv nicht wichtig.

Gruß, --Maxus96 (Diskussion) 16:53, 12. Mai 2014 (CEST)

Dummes Geschätz also? Na gut, dann ignorierst du, was die ISO-Norm zu C und C++ über undefined behavor festlegen (oder eben gerade nicht festlegen und somit an Verhalten erlauben). Allerdings zählt hier nicht deine Meinung, sondern … eben das, was die ISO-C++-Norm festlegt. Tut mir leid. --RokerHRO (Diskussion) 23:52, 12. Mai 2014 (CEST)

@Maxus96: Ein Programm ist ein Algorithmus (also, neben anderen Bedingungen, 'eindeutig'). Ein einziges auch nur möglicherweise undefiniertes Verhalten reicht aus, damit das Programm kein Algorithmus ist. Das hat nichts mit 'Gott' oder 'dummem Geschwätz' zu tun, sondern mit Informationstheorie.

@Sebastian.Dietrich:

1. Das Verhalten bei Überläufen ist architekturabhängig, x86 setzt ein Flag, das man abfragen muss, Prüfroutine, Zeitverlust, etc.
2. Die Umwandlung von signed nach unsigned (vice versa) ist architekturabhängig, weil sie auf dem Überlaufverhalten aufbaut, die Hardware kennt bei Ganzzahlen nur unsigned.
3. Das Nullzeigerverhalten hängt oft vom OS ab, x86 (als Beispiel) löst nur einen pagefault-Interrupt aus, den zu behandeln ist Sache des OS. Wird fürs Swapping benutzt. Da kanns kein unabhängiges Verhalten seitens C++ geben.
4. Arrayzugriffe mit ungültigem Index bauen darauf auf, Arrays sind in C++ Zeiger, auch die mit von vorneherein definierter Größe.
5. Schiebeoperationen mit unzulässigem rechten Operanden sind ebenfalls architekturabhängig.
   

Für all die im Artikel genannten Beispiele gibt es ein exakt definiertes Verhalten das Compiler oder recherarchitekturunabhängig ist. Beispiele würden mich ehrlich interessieren. Tmtx (Diskussion) 21:44, 13. Mai 2014 (CEST)

Du verwechslst „undefiniertes Verhalten“ (undefined behavior) mit „unspecified behavior“ und „implementierungsspezifischem Verhalten“ (implementation-defined behavior).

Ganzzahlüberläufe, Verhalten bei Überschreitung von Arraygrenzen und Nullzeigerdereferenzierungen sind alles undefined behavior. Dafür gibt es kein "exakt definiertes Verhalten". Darum kann der Compiler beim Optimieren davon ausgehen, dass in dem Programm kein undefined behavior auftritt und entsprechend optimieren (möchtest du dafür Beispiele?). Der GCC macht das auch in neueren Versionen immer mehr und es gab genug – fehlerhaft geschriebene – Software, die damit dann auf die Nase geflogen ist.

--RokerHRO (Diskussion) 00:42, 14. Mai 2014 (CEST)

Ne, für das kursive wollte ich welche :-) Tmtx (Diskussion) 22:16, 14. Mai 2014 (CEST)

Deine Punkte 1,3,4,5 sind "undefined behavior". Dein Punkt 2 ist "implementation-defined behavior". Für Punkt 2 gibt die ISO-C-Norm genau 3 Möglichkeiten vor, die den 3 erlaubten Möglichkeiten entsprechen, wie negative Zahlen gespeichert werden: Zweierkomplement, Einerkomplement und "Betrag mit Vorzeichen". C++ verweist an dieser Stelle auf die ISO-C-Norm.

Ist dir denn der Unterschied zw. "undefined behavior", "unspecified behavior" und "implementation-defined behavior" klar? Falls nein, sollte das im Artikel wohl deutlicher erklärt werden. :-/ --RokerHRO (Diskussion) 07:27, 15. Mai 2014 (CEST)

Den Unterschied übergehe ich schlicht, weil er für mich in der Praxis Wurst ist. Ich schrieb "@Sebastian.Dietrich". Ich will dich keineswegs mit "misch dich nicht ein" abbürsten, aber du musst dann schon schauen, worauf ich mich beziehe :-) . Er schrieb, es gebe für alle im Artikel genannten Fälle architekturunabhängige Implementationen. Dafür wollte ich Beispiele, und habe nur meine Zweifel zu begründen versucht. Ich habe die Fälle aus dem Artikel genommen, ich habe nun nicht geprüft, dass Punkt 1 undefined ist und Punkt 2 ( bei mir), resp. Punkt 1 in Klammern (im Artikel) implementation-defined ist. Ist das so, dann solltest du das im Artikel unter Punkt 1 in Klammern geschriebene entfernen, aber das war alles in allem nicht das, worum es mir ging... Tmtx (Diskussion) 21:55, 17. Mai 2014 (CEST)

Bitte zitier mich richtig. Ich habe angemerkt, dass es für alle im Artikel genannten Fälle in anderen Sprachen architekturunabhängige Implementierungen gäbe. Das gilt natürlich auch für deine nachher genannten Punkte - die sind in C++ vielleicht architekturabhängig, undefined oder implementation-defined, führen in Java aber z.B. bei jeder Architektur und jeder Java-Implementierung zum exakt gleichen Verhalten.

Darum halte ich es für wichtig, dass dieser Abschnitt im Artikel verbleibt, damit man weiss worauf man sich bei C++ einlässt... --Sebastian.Dietrich ✉

Richtig zitiert habe ich dich schon, das du den Satz auf andere PS bezogen hast, war mir nicht ersichtlich. Da haben wir wohl aneinander vorbei geschrieben. :-) Tmtx (Diskussion) 22:12, 18. Mai 2014 (CEST)

Ich hab den Satz auf den Satz davor bezogen... --Sebastian.Dietrich ✉ 11:57, 24. Mai 2014 (CEST)

Ich habe glaube ich eine gütliche Kompromissformel verwendet. Hier gehts um C++, wenn du dich auf Java beziehst und das nicht hinreichend deutlich machst, wirst du möglicherweise missverstanden. Das ich dich missverstanden habe, habe ich doch zum Ausdruck gebracht. Wessen Schuld das ist und ob überhaupt, ist schnurz. Erwartest du, das ich mit Tränen in den Augen auf Knien rutschend demütigst Verzeihung von dir erflehe? Tmtx (Diskussion) 21:11, 24. Mai 2014 (CEST)

Sicher. Wimmern würde auch noch gut rüberkommen :-)--Sebastian.Dietrich ✉

Explizite Typisierung noch zutreffend?

In der Infobox steht, dass C++ explizit Typisiert ist. Mittlerweile gibt es aber auch die Möglichkeit den Typ nur implizit anzugeben z.B. mit dem Schlüsselwort auto. Ich frage mich daher, ob man noch verallgemeinernd von einer expliziten Typisierung sprechen kann.--Trockennasenaffe (Diskussion) 12:12, 3. Jun. 2014 (CEST)

Ähnlich könnte man vor auto und C++11 auch fragen, ob der Typ des Parameters bar explizit dasteht:

template< typename T >
void foo( T bar )
{
	// ...
}

int main()
{
	foo( 42 );
}

--Swordfishx86 (Swordfishx86) 03:36, 27. Dez. 2014 (CET)

Der Einwand ist berechtigt auch wenn wahrscheinlich erst mit auto regelmäßig in hohem Umfang davon Gebrauch gemacht wird. Jetzt steht in der Infobox implizit, aber ob das richtig ist? Ich würde sagen C++ kann beides.--Trockennasenaffe (Diskussion) 12:05, 6. Feb. 2015 (CET)

Das in der Infobox habe ich geändert, ohne diesen Beitrag gesehen zu haben. Zur Frage ob es beides kann: Jain. Praktisch jede implizite Sprache kann auch explizit, insofern ist das halt bedeutungslos. Wenn eine Sprache implizit kann, ist sie implizit, sonst explizit. Eigentlich wäre es auch eine Überlegung wert, den Kommentar zu statisch raus zunehmen, da auch der auf praktisch jede statische Sprache in gewissem Maße zutrifft. ----Florian Weber 01:51, 20. Feb. 2015 (CET)

std::endl im Programmbeispiel

Meiner Meinung nach ist std::endl hier fehl am Platz, es ist lediglich ein Zeilenumbruch gewünscht (wenn überhaupt, der Zeilenumbruch ist ja bei Hello-World-Programmen nicht üblich). Ein std::endl flushed den betroffenen Stream zusätzlich, also synchronisiert den Stream mit dem Buffer. Das sollte man dann auch hier anpassen.

Gruss, --Asfdlol (Diskussion) 15:13, 28. Jul. 2014 (CEST)

Mich störts nicht. Und offensichtlich auch keinen anderen. Dass ein Hello-World-Programm keinen Zeilenumbruch enthalten soll, ist mir allerdings neu.

Von mir aus kann das std::endl durch "\n" ersetzt werden oder auch komplett rausfliegen.--Plankton314 (Diskussion) 15:12, 2. Aug. 2014 (CEST)

In den Erklärungen zum Hello-World findet sich noch mehr Quatsch. Das Beste:

"Der Operator << ruft die Ausgabe-Operation auf; er ist in der Klasse std::ostream überladen und wird von std::ofstream geerbt."

omfg. Ich wurschtel mal d'rüber.

--Swordfishx86 (war: 89.144.207.2) (Diskussion) 09:01, 27. Dez. 2014 (CET)

gudn tach!

ob das nun mit \n oder endl beendet wird, ist fuer das beispiel wurscht. (grundsaetzlich empfehle ich, "std::endl" zu benutzen, weil dann zumindest einige seltsame buffer-ungereimtheiten nicht auftreten.)

dein "druebergewurschtel" fand ich sehr gut. sprachlich und inhaltlich ist die beschreibung jetzt wesentlich praeziser. -- seth 23:13, 27. Dez. 2014 (CET)

Hallo seth,

danke fürs d'rüberschaun, korrigieren und sichten. Da es auch in der Stroustrup-FAQ nacht explizit steht zur Sicherheit: ISO/IEC 14882:2012 (E) Programming Language C++, § 3.6.1.5: "[...] If control reaches the end of main without encountering a return statement, the effect is that of executing return 0;"

Würdest Du mir für "seltsame buffer-ungereimtheiten" im Bezug auf cout/cin bitte ein Beispiel geben?

--Swordfishx86 (war: 89.144.207.2) (Diskussion) 00:45, 28. Dez. 2014 (CET)

beim old-style-debugging ohne flush kann man sich z.b. bei vermeintlich fehlenden debug-ausgaben in der zeile vertuen, in der ein seg fault auftritt. -- seth 00:59, 28. Dez. 2014 (CET)

cerr für Debugausgaben verwenden??

--Swordfishx86 (Diskussion) 01:20, 28. Dez. 2014 (CET)

ja, das ist grundsaetzlich moeglich, aber das hat man in grossen projekten nicht immer in der hand und dann kommen philosophische fragen dazu, ob debug-ausgaben nach STDOUT oder -ERR gehoeren. und teilweise tauchen ja vielleicht auch mal sehr seltene segfaults ohne explizite debug-ausgaben auf, sodass man sich dann nur an den normalen ausgaben orientieren kann (abgesehen natuerlich von analytischen tests, die aber sehr langwierig sein koennen). aber wie gesagt, das fuehrt ueber das eigentliche thema hinaus, da es im beispiel voellig egal ist. -- seth 10:39, 28. Dez. 2014 (CET)

@Codc: Du hast meine Änderung (Quellcode ergänzt Stroustroup: "Die C++ Programmiersprache." 4. Auflage. Addison-Wesley, 2009, S. 50, nach http://bks1.books.google.mk/books?id=3uhuFrKoyL8C&lpg=PP1&pg=PA50#v=onepage&q&f=false) Rückgängig gemacht mit dem Vorwurf "Revert: Hat keine Schöpfungshöhe und verdeckte Buchwerbung". Wie Soll ein Verweis auf einen Titel mit Seitenangabe verdeckte Buchwerbung sein, wenn das Werk schon laaange in der Literaturliste steht? Hat aber den Wert, daß die Diskussion "to endl or not to endl" in einem Hello World vielleicht endgültig geklärt ist. --Swordfishx86 (Diskussion) 03:49, 28. Dez. 2014 (CET)

Implementierung in Microsoft Visual Studio

@Chricho: Ließ bitte die Zusammenfassung nochmal: "es gibt weder die Sprache 'MS Visual C++(C++/CLI)' noch ein ebenso benahmstes Produkt" und denk drüber nach. Mit der aktuellen Version bin ich aber so oder so zufrieden. --Swordfishx86 (Diskussion) 19:34, 3. Mär. 2015 (CET)

c++14

Hallo, wäre es an der Zeit einmal einen Abschnitt zu c++14 hinzuzufügen? Der Standart ist immerhin schon einige Zeit draußen. (nicht signierter Beitrag von 87.174.17.197 (Diskussion) 12:58, 28. Dez. 2014 (CET))

ja, wäre es ... hast Du Zeit dafür? Schreib' dann aber bitte vom Standard. Danke

-- Swordfishx86 (Diskussion) 14:07, 28. Dez. 2014 (CET)

Wesentlich unschöner finde ich, dass C++11 nur in einem kleinen Abschnitt abgehandelt wird, obwohl die Änderungen sehr weitreichend sind und z.B. sehr viel umfangreicher als bei C++14. Viele der großen Sprachversionen haben zu C++11 einen eigenen Artikel. Natürlich müsste den jemand schreiben und das ist sicherlich eine Nummer zu groß für mich. Mithelfen würde ich allerdings schon.--Trockennasenaffe (Diskussion) 12:08, 6. Feb. 2015 (CET)

Ich habe damit schonmal angefangen und dem Abschnitt nach eigenem Ermessen mal etwas mehr Struktur beigefügt und weitere wichtige Features kurz beschrieben. Da ich den Charakter eines Auszugs zum 11er Standard nicht verändern wollte, ist der Abschnitt auch weiterhin schmal und ohne tiefere Darlegungen gefasst. Hier kann man sicher weiterführend immer noch einiges verbessern und links nachtragen.

--Petrucciation (Diskussion) 16:45, 4. Apr. 2016 (CEST)

- 2015 -

Beispiele

@Sebastian.Dietrich: Das Beispiel passt nicht zu dem Zitat. Es geht ja gerade darum, dass man ggü. C zum Beispiel einen gewissen Komfort hat, dann aber auf Grundlage von dem an umso schwerer zu durchschauende Probleme geraten kann. Es geht nicht um beliebige fehlende Sicherheiten, die jede Low-Level-Sprache hat. Siehe die Anmerkung von Stroustrop: “As you protect people from simple dangers, they get themselves into new and less obvious problems.” Etwas nicht zu deallozieren etwa gehört zu den bekannten “simple dangers” aus C. Es ist besser, wir verzichten auf die Theoriefindung solcher Beispiele oder wir verzichten gar lieber ganz auf das Zitat, Stroustrop scheint es ja auch nicht so wichtig zu nehmen. --Chricho ¹ ² ³ 15:02, 18. Aug. 2015 (CEST)

Das Zitat ist mMn zu wichtig um es wegzulassen. Aber es ist nicht selbsterklärend, d.h. eine Erklärung, was er damit gemeint hat ist mMn notwendig. Dieser Erklärung wäre natürlich mit einem Beispiel gut geholfen. Etwas nicht zu deallozieren ist ein in vielen Fällen mit simplen Mittel (RAII, Ref-Counting etc.) nicht lösbares Problem - ist also mMn keine "simple danger". Mein Lieblingsbeispiel für "less obvious problem" in C++ ist die Verwirrung, die durch übermäßige Verwendung von operator-overloading gestiftet wird. Aber vielleicht hast du einen bessere Vorschlag für ein "less obvious problem". --Sebastian.Dietrich ✉ 22:16, 18. Aug. 2015 (CEST)

C++ Wiki

Ich möchte vorschlagen cppreference.com unter C++#Weblinks zu erwähnen. Begründung:

• Das Wiki ist gut gepflegt und wird stetig weiter entwickelt 1
• In Diskussionen wird gerne auf die Seiten verlinkt, z.B. 2, 3, 4
• Die Bedeutung unterstreicht, dass der Initiator auf der cppcon 2015 über das Projekt vortragen durfte 5
• Meines Wissens gibt es nichts Vergleichbares, auch wenn jemand etwas anderes behauptet 6

-- χβ22ƕƕ (Diskussion) 15:04, 23. Okt. 2015 (CEST)

Das Schweigen werte ich nun als Zustimmung. -- χβ22ƕƕ (Diskussion) 13:12, 18. Nov. 2015 (CET)

Ich habe nicht "etwas anderes behauptet", sondern auf eine mangelnde Begründung verwiesen. Diese hast du ja jetzt erbracht, mit unterstützenden Links.

--arilou (Diskussion) 16:41, 1. Dez. 2015 (CET)

Tschuldigung! War nicht persönlich gemeint. Habe mich an Deinem Satz C++ -Wikis gibt's wie Sand am Meer orientiert. -- χβ22ƕƕ (Diskussion) 17:24, 1. Dez. 2015 (CET)

- 2016 -

Name 'C++'

Siehe Diskussion:D (Programmiersprache)#D -1. --arilou (Diskussion) 13:33, 11. Mär. 2016 (CET)

Kritik

Während ich mit den meisten genannten Zitaten und Punkten im Kritikabsatz konform gehen kann, finde ich den Punkt

"C++ gilt zwar als schnell, beispielsweise wegen der Möglichkeit, frei mit Pointern zu arbeiten, doch diese Leistung sei auf den heutigen, schnellen Computersystemen nur in Ausnahmefällen nötig: Während es sinnvoll sei, Betriebssysteme o. Ä. in C++ zu schreiben, sei es softwaretechnisch viel günstiger, Anwendungsprogramme in höheren Sprachen zu schreiben, da diese leichter zu warten seien und immer noch eine ausreichende Leistung aufwiesen"

nicht nur mittlerweile wieder mindestens in Teilen überholt, sondern auch viel zu allgemein geblieben. Sieht man sich den Blog der Quelle an, bleibt auch der Autor dort sehr kurz, allgemein und verweist im Kern eigentlich auch nur auf einige Aussagen und Zitate von Stroustrup. Vielmehr sollte vielleicht herauskristallisiert werden, dass nach wie vor viele größere komplexe Programme, welche höher performantes Rechnen erfordern, oft eine native C++ Bibliotheksabhängigkeit aufweisen und zumindest sollten nach strengeren Kriterien typische Felder konkreter verglichen werden, wo C++ heutzutage nicht mehr die beste Wahl ist oder eben doch noch sein kann. Letzteres dürfte vorallem den Großteil an Software betreffen, die Hardwareinteraktion, Rendering, Streaming/Sampling, High Performance Computing, wissenschaftliche Berechnungen und ähnliches aufweisen bzw. durchführen und das sind nach wie vor nicht wenige. Des Weiteren gibt es auch derzeit immer noch sehr kontroverse Diskussionen über das hoch gelobte Garbage Collection. Dieses hier pauschal zu nennen, vorallem wo mit Weak/Shared/Unique Pointer und anderen C++11/14 Konstrukten mittlerweile sehr robuste Mittel zur Verfügung stehen, die zumindest in vielen wichtigen Punkten der Notwendigkeit eines Garbage Collectors entgegen stehen, halte ich mindestens für zu kurz angebracht und für den Laien auch missverständlich. Auch ist mir derzeit keine größere bekannte Sprache bekannt, die die Mächtigkeit von Templates auch nur im Entferntesten abdeckt. Dass "höhere" Sprachen (welche?) per se leichter zu warten seien, ist mir auch ein zu großes Allgemeinplätzchen und hängt im Zweifel auch mit der jeweiligen Problemstellung zusammen. Meine Erfahrung hat jedenfalls gezeigt, dass die Wartbarkeit zu einem sehr großen Teil eher direkt an die Disziplin und Kompetenz der jeweiligen Entwickler geknüpft ist, sich an gewisse Guidelines und Regeln sauberen Programmierens und auch Dokumentierens zu halten. Wenn jemand in C++ inkonsistent oder/und schlampig programmiert, wird er dies in der Regel auch in Java oder C# tun. In Sachen Wartbarkeit kann man in so ziemlich jeder Sprache grobe Fehler machen (wer schonmal in C# die Windows Forms beispielsweise für eine GUI robust wrappen musste, der weiß, dass bereits Microsoft damit in Teilen ordentliche Probleme hatte und hat...). So oder so könnte der Kritikbereich etwas ausführlicher und differenzierter ausgearbeitet werden.

--Petrucciation (Diskussion) 21:35, 4. Apr. 2016 (CEST)

In den letzten drei Jahren ist an dem Artikel nicht viel geändert worden, dass er in Teilen veraltet ist, würde mich von daher nicht wundern. Wenn Du etwas beitragen kannst, wäre das schön. Denk aber bitte daran, dass alles belegt werden muss - Du klingst so, als wüsstest Du selbst ziemlich gut Bescheid, leider reicht das als Beleg nicht ;-) -- Perrak (Disk) 23:33, 4. Apr. 2016 (CEST)

Alles klar, ich setze mich die Tage mal ran. Die Quellennachweise sollten, wie auch beim RAII-Punkt, kein Problem sein. --Petrucciation (Diskussion) 00:00, 5. Apr. 2016 (CEST)

RAII

Mir ist es ein Rätsel, wie man RAII bei einem Artikel über C++ komplett unerwähnt lassen kann. Der Artikel ist auch in Teilen schon zu spezifisch, als dass man damit argumentieren könnte, dass dies ein zu spezifischer Aspekt sei. Wenn es keine Einwände gibt, würde ich diesen Aspekt zeitnah entsprechend nachziehen (ich weiß nur noch nicht so recht, wo...).

--Petrucciation (Diskussion) 21:43, 4. Apr. 2016 (CEST)

Sei mutig! -- Perrak (Disk) 23:33, 4. Apr. 2016 (CEST)

ISO ist *keine* Behörde

Die ISO ist keine Behörde, sondern ein Verein. Behörden gibt es nur im direkten staatlichen Kontext und sind explizit mit Hoheitsbefugnissen ausgestattet.

Welche Änderung schlägst du vor? Grüße, --Schotterebene (Diskussion) 14:41, 18. Aug. 2016 (CEST)

Ja, wurde es. Tipp: Die meisten Webbrowser haben eine integrierte Suchfunktion, die sich üblicherweise mittels Strg+F erreichen lässt ;-) --nenntmichruhigip (Diskussion) 14:57, 18. Aug. 2016 (CEST)