Einleitung dieser Diskussionsseite anzeigen

Dieses Diskussionsarchiv hat die empfohlene Seitengröße erreicht und gilt damit als abgeschlossen. Sein Inhalt sollte nicht mehr verändert werden (ausgenommen Kleinbearbeitungen wie Link- und Vorlagenfixe). Verwende für die Archivierung von Diskussionsbeiträgen bitte das aktuelle Archiv und benutze bitte für aktuelle Diskussionen die aktuelle Diskussionsseite.

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/1#Abschnittsüberschrift]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:C%2B%2B/Archiv/1#Abschnittsüberschrift

- 2004 -

Fehler im Artikel?

Laut Bjarne Stroustrup hat Rick Mascitti im Sommer 1983 den Begriff C++ geprägt (Bjarne Stroustrup: Die C++ Programmiersprache; 3. Auflage 1998; S. 11). Im Artikel steht 1982.

Stärken und Schwächen

Mir erscheint die Darstellung der Vor- und Nachteile von C++ ein bisschen einseitig, man spürt die Handschrift eines Autors (oder einer Autorin?) die C++ nicht so sehr mag oder vielleicht auch nicht ganz verstanden hat. (But as always: "your mileage may vary")

Die Unterteilung in Stärken und Schwächen gefällt mir nicht. Hier sollte eher eine Auflistung der Sprachmerkmale erfolgen.
Dass die aktuellen Compiler nicht optimalen Code erzeugen oder nicht ISO konform sind ist doch keine Schwäche der Sprache. Sollte rausgenommen werden.

Naja, es ist keine Eigenschaft der Sprache, aber das Fehlen von guten Compilern schränkt die praktische Verwendbarkeit einer Sprache doch schon ein, oder? --RokerHRO 21:20, 16. Nov 2004 (CET)

DevCpp gibt es nicht mehr für Linux. Es wird nicht mehr weiterentwickelt. Der Autor von DevCpp selber schreibt das auf seiner Seite und verweist zB. auf KDevelop oä. als IDE. Und hier noch ein Link für den ICC -> http://www.intel.com/software/products/compilers/ Gibt es ja nicht nur für Windows.

Einige der wichtigsten (stärksten) Merkmale der Sprache C++ werden nur unzureichend angesprochen: Polymorphismus und Vererbung...

Wer zum Teufel kam denn bitte auf die Idee, die Compiler nach Sprachkonformität zu sortieren. Erstens ändert sich das bei jedem Release; Zweitens gibt es kein vernünftigen Weg das zu messen. Warum sollte der G++ zB. schlechter sein als der MSVC++ oder der ICC? Ich mach den Blödsinn mal wieder weg

Benutzer: Kingruedi, 4. September 2004

Unauffindbar unter "C++"

Wenn ich "C++" oder "Programmiersprache C++" ins Suchfeld eingebe gelange ich nicht zu diesem Artikel. Kann man das ändern? -- 84.57.39.129 01:30, 9. Okt 2004 (CEST)

Leider nein - der Artikelname ist unser Sorgenkind, weil die Software ein "+" im Artikelnamen nicht erlaubt. -Uli 01:31, 9. Okt 2004 (CEST)

Weblinks

Habe mal http://www.cppreference.com/ hinzugefügt, weil noch keine Online-Dokumentation dabei war. Denke aber, ein paar von den Links kann man löschen, wie zum Beispiel den Garbage Collector, das ist eigentlich schon zu speziell. -- KL47 18:36, 30. Okt 2004 (CEST)

Seit wann ist "zu speziell" ein Ausschlusskriterium für Wikipedia-Artikel? Im Gegenteil: Wikipedia soll andere Nachschlagewerke an Tiefe übertreffen. Was ich eher störend finde, sind kommentarlos hinzugefügte Links und Buchempfehlungen. Ich schlage vor, alle vorhandenen und vor allem zukünftigen Links und Buchempfehlungen mit einer kurzen Beschreibung zu versehen, die auch die Qualität bewerten. So schützen wir uns ein wenig vor minderwertigen Einträgen und den Missbrauch durch reine Werbelinks.

"Sehr Vollständigkeit" und Kompetenzen...

Was bedeutet "sehr vollständig"? Vollständig oder nicht? So etwas müsste geändert werden. Da ich aber nicht weiß, inwieweit die einzelnen Compiler den Standard umsetzen, lass ich mal die Finger davon. Meinungen? Gibt es außerdem noch einen Grund, warum es keinen Artikel "C++" gibt?

Nachtklavier

Ich zweifle über ...

Ich zweifle über die sprachliche Kompetenz mancher Autoren. Was "sehr vollständig" bedeuten soll, werde ich mich wohl noch im Grabe fragen. Ich habe jedenfalls die Tabelle des vollständig-fetischistischen Autors geändert...

--Nk94.com 13:23, 26. Nov 2004 (CET)

Wir brauchen nicht ausschließlich Autoren mit hoher oder überdurchschnittlicher sprachlicher Kompetenz. Wikipedia ist ein Gemeinschaftsprojekt, in das sich jeder mit seinen individuellen Fähigkeiten einbringen kann. Denn sieh mal: der Artikel hat doch jetzt die von dir gewünschte Formulierung. Es funktioniert also.

Hihi - jemand, der "zweifelt über", bemängelt sprachliche Kompetenz... *grins*

- 2005 -

g++ (directory.fsf.org) vs. g++ (gcc.gnu.org)

Hi, meiner persönlichen Meinung nach, sollte man den gcc.gnu.org link verwenden, der directory.fsf.org link ist extrem veraltet und wird offensichtl. nicht gepflegt! --Helm 17:29, 7. Feb 2005 (CET)

Vorallem handelt es sich dabei nur um ein Eintrag in einem Directory und nicht um den offiziellen Link. GCC ist eben nicht mehr nur ein C Compiler sondern enthält verschiedene Front- und Backends. Selbst wenn man nur C++ meint, ist der Link auf gcc.gnu.org richtig. Etwas anderes deutet nur auf ein Missverständnis der GCC hin. (GCC == GNU Compiler Collection). Im Zweifelsfall bitte C++-Code mittels gcc -lstdc++ foo.cpp kompilieren. Es gibt halt keinen direkten Link für das C++ Frontend in der GCC.--Kingruedi 21:17, 7. Feb 2005 (CET)

Wenn directory.fsf.org veraltet ist und nicht mehr gepflegt wird, dann bitte gcc.gnu.org! Lostintranslation 18:56, 8. Feb 2005 (CET)

Buchliste

Ich finde übrigens die Buchliste zu lang und würde sie gerne kürzen. Alle Bücher ohne Kommentar raus, und in Zukunft nur noch kommentierte zulassen. Lostintranslation 18:56, 8. Feb 2005 (CET)

sehe ich genauso. nimm raus!

Hier ist ein Buchtipp TICPP. Ist zwar nur in englisch, dafür aber sehr gut und ganz umsonst.

"Schrott-Entfernung"

Frage zum Link auf Wikibooks: Hat nicht auch die Wikipedia mal klein angefangen? Daher lieber mitarbeiten, denn ich bin der (nicht neutralen) Ansicht, daß aus dem Schrott eine Perle werden kann.--modified by old.cpp 12:26, 2. Mär 2005 (CET)

Sicher. Wenn es soweit ist, kann ja der Link wieder rein.

Geplante Erweiterungen der Programmiersprache C++

Welche geplanten Spracherweiterungen wären wohl Erwähnenswert? Poldi 19:25, 6. Mär 2005 (CET)

Stärken und Schwächen von C++

Die folgenden unter Schwächen aufgeführten Punkte sollten ersatzlos gestrichen werden:

Die aktuellen Compiler (Stand: 2005) sind rückständig bezüglich der Umsetzung der ISO-Norm.

Das galt mal vor 5 Jahren. Das stimmt einfach nicht mehr. Sowohl der Microsoft compiler, als auch der gnu compiler sind beide sehr nah am Standard. Wie der Autor darauf kommt ist mir absolut schleierhaft. Der Borland compiler schlägt aus der Art, aber den kann man nicht als aktuell bezeichnen.

Das sind 3 Compiler. Von wievielen? Und welcher von den dreien hat export implementiert?

Diese drei Compiler decken den überwiegenden Teil des Marktes ab. Willst du embeded compiler für Waschmaschinen zum Maßstab machen?

Eclipse 14:27, 23. Jun 2005 (CEST)

Die aktuellen Compiler produzieren nicht immer optimalen Code, sowohl in Bezug auf Geschwindigkeit als auch auf Code-Größe.

Was bitte soll denn das bedeuten? Kein compiler für irgendeine Sprache erzeugt optimalen code. Es gibt den Intel C++ compiler der zumindest laut Aussage von Intel speziell für Intel architekturen optimierten code liefert und auch 20% schneller sein soll.

Du kannst doch nicht einen Compiler herauspicken und das für allgemeingültig erklären.

Was ist optimaler Code? Kein compiler für irgend eine Sprache erzeugt immer optimalen Code. Optimaler code sieht für jeden Prozessor anders aus, das ist kein Argument weil es für alle Sprachen gilt hier aber als C++ Schwäche gelistet wird.

Eclipse 14:27, 23. Jun 2005 (CEST)

Was bitte ist optimal in bezug auf Code Grösse?

Möglichst klein.

Was hat das mit der sprache zu tun. Jeder compiler hat entsprechende optimierungsoptionen.

Es hat mit der Sprache zu tun, dass es aufgrund der Sprachdefinition sehr aufwändig ist, diese Optimierungen zu implementieren.

Folgenden Punkt unter Vorteile finde ich auch diskussionswürdig:

Sehr hohe Ausdrucksstärke und Flexibilität - Beispiel: die anpassbare Freispeicherverwaltung, in die sich zum Beispiel nahtlos eine Garbage-Collection integrieren lässt

Was ist denn ein Maß für Ausdrucksstärke in einer Programmiersprache?

Über die Formulierung lässt sich sicher streiten. "Abstraktion" wäre vielleicht passender.

Flexibilität ja, ohne wenn und aber. Trotzdem: das Fehlen eines eigenen Garbage Collectors wie in Java ist eher ein Nachteil. Hier wird als Vorteil aufgelistet das man Features, die in anderen Sprachen integraler Bestandteil sind von Hand programmieren kann.

Es geht hier nicht um den vorhandenen oder nicht vorhandenen Garbage-Collector, sondern um ein Beispiel für die Flexibilität: Die Sprache ist so flexibel, dass sich sogar ein Garbage-Collector nachrüsten lässt. Das ist ein Vorteil.

Ich bleibe dabei: Die Möglichkeit zum Nachrüsten eines fehlenden Features ist kein Vorteil. Wenn du ein Auto kaufst ist es dann ein Vorteil, das es einen Platz für den Ersatzreifen gibt aber keiner mitgeliefert wird während die meisten anderen Autos eins haben? Das

Eclipse 14:27, 23. Jun 2005 (CEST)

Wenn du willst, kannst du ja zusätzlich das Nichtvorhandensein des GCs als Nachteil aufführen. Darüber gibt es aber heiße Diskussionen, und viele sind der Meinung, das Nichtvorhandensein sei ein Vorteil.

Erfahrungsgemäß starte ich dann einen Edit War mit Leuten die noch nie an einem großen Projekt mitgearbeitet haben und den nutzen eines Garbage Collectors daher auch nicht kennen.

Eclipse 14:27, 23. Jun 2005 (CEST)

Könntet ihr bitte eure Beiträge mit 4-Tilde Zeichen unterschreiben: ~~~~. Das macht es leichter die Diskussion zu verfolgen. Ansonsten würde ich das mit der Standard unterstützung rausnehmen, da diese bei neuen Compilern recht gut ist. export ist das einzige Feature was nicht implementiert wird. Aber darauf verzichten die Compiler-Hersteller wohl bewusst.

Um das mal auf den Boden der Tatsachen zu holen: Beim Boost-Regressionstest versagt der hochgelobte GCC in 4 Prozent aller Fälle, und das ohne Berücksichtigung von export. ~~~~

Selbst die Standard-Komitee Leute halten es [export] wohl mittlerweile für kaputt.

export gehört zur Sprache, also tut das nichts zur Sache.
Darüber hinaus bezweifle ich diese Aussage und bitte ich dich, so eine drastische Behauptung zu belegen. ~~~~

http://www.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1426.pdf --RolandIllig 22:21, 16. Okt 2005 (CEST)

Das mit der Geschwindigkeit trifft so auch nicht mehr zu. Es gibt mittlerweile sehr viele Optimierungstechniken auch für kompliziertere Features. Sogar virtuelle-Funktionsaufrufe werden mittlerweile wegoptimiert (siehe aktuelle CUJ Ausgabe).

Es geht nicht nur darum, welche Optimierungstechniken theoretisch möglich sind, sondern und vor allem auch um deren tatsächliche Verbreitung in real existierenden Compilern. ~~~~

Die größeren Binarys gehen eher auf die Standard Library zurück, als darauf, dass der Code schlecht optimiert wird. Aber die ist einfach größer und umfangreicher als die von C.--Kingruedi 12:48, 28. Mär 2005 (CEST)

Die Binärdatei ist größer, weil die Bibliothek größer ist? Nee. Probiers einfach mal mit dem eigenen Compiler aus! ~~~~

Die Tildes natürlich ohne das nowiki-Tag. Ansonsten, die Binärdatei soll größer als was sein? Was soll ich genau ausprobieren? Das mit der Größe und Geschwindigkeit finde ich einfach nicht haltbar. Du musst schon ein Beispiel machen, dass zeigt, dass praktikabler C++ Code von gängigen C++-Compilern schlecht übersetzt wird.--Kingruedi 21:45, 28. Mär 2005 (CEST)

Du hast geschrieben Die größeren Binarys gehen eher auf die Standard Library zurück. Wie kommst du darauf?
Ich habe dir bezüglich Performance eine Quelle angegeben (s.o.). Hast du dort nicht nachgesehen? --217.95.166.4 20:48, 29. Mär 2005 (CEST)

Naja, link einfach mal die Standard Library zu einem Programm hinzu und einmal nicht und schau dir die Größe an. Ansonsten wie gesagt, bräuchte man ein Vergleich um in die Details zu gehen. Welche Quelle meinst du? Die Boost-Regressiontests? Die haben ja nichts mit Performance zu tun. --Kingruedi 11:33, 30. Mär 2005 (CEST)

Wenn das so ist, wie du beschreibst, dann hast du doch das beste Beispiel dafür, wie schlecht Compiler optimieren.
(Die Regressionstests waren nicht auf dieses Thema bezogen. Entschuldige den Gedankensprung.) --217.95.166.4 20:12, 30. Mär 2005 (CEST)

Nö, wieso? Hat wenn etwas mit dem Linker zu tun und der ist ja Sprachneutral. Also bist du immer noch ein Beispiel schuldig. -- Kingruedi 13:10, 31. Mär 2005 (CEST)

Der Linker ist nicht sprachneutral. Schön wärs. Welchen Compiler verwendest du denn? --217.95.166.4 20:37, 31. Mär 2005 (CEST)

Hallo-Welt-Programm

Letzter Kommentar: vor 19 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt

Wenn man allerdings neuere Compiler benutzt, die NAMESPACES unterstützen, kann man das Hallo-Welt Programm auch so schreben:

#include<iostream>
using namespace std;
int main() {
cout << "Hallo Welt" << endl;
return 0;
}

Schau dir das Programm im Artikel nochmal genau an. Da steht "std::cout" und "std::endl"; ein Compiler mit namespace-Unterstützung wird also bereits vorausgesetzt. Es wurde bestimmt schonmal ausdiskutiert, wieso std::cout und nicht using benutzt wird. btw, unterscheib deine Beiträge bitte mit vier Tilden, damit man der Diskussion leichter folgen kann: ~~~~ --Christoph 19:17, 26. Apr 2005 (CEST)

Ich bin auch dafuer das man es mit using namespace std; schreibt, ist einfach einfacher und simpler ;)

Viperb0y 12:54, 22. Mai 2005 (CEST)Beantworten

Ein Hallo-Welt sollte kurz und einfach sein. using namespace std; führt ein zusätzliches Konzept ein, das auch nicht völlig trivial ist. std::cout funktioniert außerdem immer, auch wenn man ein using namespace mein_programm_ns; o. ä. benutzt. -- Helm 07:53, 23. Mai 2005 (CEST)Beantworten

Namespaces global zu öffnen ist aber nicht so schön. Das gewöhnt man sich zu leicht an! Wo ist das Problem, den Namespace explizit anzugeben? --Kingruedi 12:35, 23. Mai 2005 (CEST)Beantworten

Ich bin auch dafür, das using namespace std; wegzulassen, weil gerade Leute, die die Sprache noch nicht kennen, gar nicht wissen können, was für Namen sie sich damit definieren. Gegen ein using std::cout; habe ich prinzipiell nichts, aber für ein Hello World ist das zu kompliziert. --RolandIllig 22:05, 16. Okt 2005 (CEST)

Ich möchte darauf hinweisen, dass std::endl in einem Hallo-Welt-Programm überflüssig ist und dort nichts zu suchen hat: Es flusht den Stream, was bei seiner Zerstörung sowieso geschieht und ist deshalb stilistisch äußerst fraglich. Ich wäre deshalb für einen einfachen Zeilenumbruch mit \n.

Ich sehe darin keine Verbesserung des Programmes. Deshalb für << std::endl.

Die weit verbreitete Fehlbenutzung von std::endl sollte nicht schon in einem Hello-World-Programm Einzug finden. Es ist guter Stil, den Stream nur dann zu flushen, wenn es auch notwendig ist. Ein Hello-World-Programm ist allerdings aus leicht ersichtlichen Gründen das beste Gegenbeispiel für die Benutzung von std::endl. Ich würde gerne Meinungen hören, die die Benutzung von std::endl hier rechtfertigen.

Die Erfahrung zeigt,

dass ein mit std::endl geschriebenes Programm für Anfänger leichter zu verstehen ist,
dass sich Anfänger darüber wundern, wenn keine Bildschirmausgabe erscheint.

Man kann für beide Arten Argumente finden. Da dies kein Programmierkurs ist, würde ich solche Feinheiten aber nicht überbewerten. ... statt dessen lieber die anderen Teile des Artikels verbessern!

Literatur (Wollenschein)

Florian Wollenschein: C++ Programmierung für Anfänger, BoD, ISBN 3-8334-2216-5, für Anfänger sehr gut geeignet, aber nichts für Profis

Dieser Literaturhinweis kam gerade von Benutzer:195.93.60.105. Revert, da ich die Begründung auf der Diskussionsseite vermisse. An den anonymen Poster: Bitte schreib eine kurze Begründung, wieso dieses Buch in die Liste aufgenommen werden sollte. --Christoph 20:11, 26. Apr 2005 (CEST)

Programmierkurs

Änderungen vom 22.4.2005

Es tut mir leid, diesen wie einen Programmierkurs gehaltenen Eintrag rückgängig zu machen, aber diese Art der Darstellung ist i.Allg. nicht in Wikipedia-Artikeln gewünscht. Dafür bietet sich aber z.B. www.wikibooks.de an.

Änderungen vom 29.4.2005

Das Beispielprogramm ("Hallo Welt") soll nur zeigen, wie C++-Programme grundsätzlich aussehen. Die Erläuterungen wurden deshalb angefügt, weil das Programm - obwohl so einfach - so oft verschlimmbessert wurde. Detailliertere Ausführungen sind besser in einem Programmierkurs zu C++ aufgehoben.

Stärken und Schwächen

Folgender Abschnitt wurde am 19.7.2005 hinzugefügt:
* Einige Details der Sprache sind compilerspezifisch, so ist beispielsweise der Wertebereich eines Integers nicht etwa in der Sprachdefinition enthalten, sondern je nach Compiler und Plattform unterschiedlich. Andere Programmiersprachen bieten hier klare Angaben zu den Wertebereichen, was sehr angenehm sein kann.
Argumentation zu vordergründig. Gerade feste Wertebereiche haben schwerwiegende Nachteile. Kein Grund also, dies bei Schwächen zu verbuchen.

Hallo Namenloser, im zweiten Punkt geht es offenbar um die Portabilität. Ich habe das jetzt mal nach meinem Verständnis umgebaut, um diesen Punkt besser hervorzuheben. --jpp 18:24, 20. Jul 2005 (CEST)

Hallo Abgekürzter ;) da steht also jetzt:
* Einige Details der Sprache sind compilerspezifisch, so ist beispielsweise der Wertebereich eines Integers nicht etwa in der Sprachdefinition enthalten, sondern je nach Compiler und Plattform unterschiedlich. Dies erschwert die Portierung von C++-Programmen zwischen Rechnertypen, Betriebssystemen und teilweise sogar Compilern.
Das ist aber immer noch zu vordergründig argumentiert, denn feste Wertebereiche sind ein Hemmschuh für die Geschwindigkeit. Wenn also dadurch beim Portieren die ganze Leistung verloren geht, gibt es ein riesen Problem. Das ist einfach nicht akzeptabel. Gerade der Verzicht auf den festen Wertebereich ist also ein Vorteil. 19:21, 20. Jul 2005 (CEST)

Dann schreib diesen Aspekt doch unter Vorteile hin. Sei mutig! Schließlich gibt es Eigenschaften, die für einen Aspekt ein Vorteil sind und für einen anderen ein Nachteil. :-) --jpp 19:32, 20. Jul 2005 (CEST)

Richtig. Aber dann kann ich so eine Eigenschaft nicht unter Stärke/Schwäche einer Sprache verbuchen. Deshalb werde ich die Passage löschen (habe statt dessen die Auswertungsreihenfolge von Teilausdrücken genannt).
Dass feste Wertebereiche ein gravierender Nachteil seien, ist schlicht ein Anfängervorurteil. Ich appelliere an alle Autoren dieses Artikels, bitte hier nur unter Fachleuten anerkannte Charakteristika der Sprache aufzuzählen. Ziel ist wie immer in Wikipedia die Theoriedarstellung, nicht Theoriebildung. Persönliche Meinungen und Vorlieben sind hier fehl am Platz. 21:05, 20. Jul 2005 (CEST)

Na, dass ist doch ein guter Kompromiss! War doch gar nicht so schwer, oder? ;-) --jpp 21:07, 20. Jul 2005 (CEST)

Folgender Abschnitt wurde am 19.7.2005 hinzugefügt:
* C++ bietet dem Programmierer mitunter sehr viele Möglichkeiten, auf verschiedene Weise zum gleichen Ziel zu kommen, was zum einen Programmiereinsteiger verwirren kann (welcher Weg ist der richtige?), zum anderen macht es diese Eingenart der Sprache jedem, der an schon vorhandenem Code weiterarbeiten soll, unnötig schwer. Letzteres ganz einfach deswegen, weil man zunächst herausfinden muss, welche Programmierstile/Programmierkonstrukte im vorhandenen Code enthalten sind, um ein konsistentes Gesamtbild beizubehalten.

Die darin gemachten Aussagen sind zu pauschal. Die Eigenheit "auf verschiedene Weise zum gleichen Ziel" kommen zu können, ist keine Besonderheit von C++. Ich habe den Abschnitt entfernt.

Folgender Abschnitt wurde am 19.7.2005 hinzugefügt:
* Es stehen keine eingebauten Mechanismen zur Serialisierung/Deserialisierung eines Objektes bereit, wie von einigen anderen Sprachen (z.B. C#, Java) gewohnt,

Das Argument scheint für das Gesamtbild von eher geringer Relevanz.

Schwächen/Fehlende Bibliotheken

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

Falscher Titel. In fr-Wikipedia klappt es!

Schaut euch mal die französische Wikipedia an, da klappt es mit dem + im Titel: fr:C++ haben die eine neuere Wikimedia Version oder wie bekommen die das hin? Ich kann leider kein französisch, sonst würde ich dort mal nachfragen. --Kingruedi 08:01, 23. Aug 2005 (CEST)

Die benutzen kein normales Plus-Zeichen, sondern das "FULLWIDTH PLUS SIGN" (U+FF0B) (entsprechend lautet der Link fr:C＋＋).

Laut Tabelle entspricht das Zeichen ungefähr dem ASCII-Pluszeichen, außer, dass es volle Breite hat (dürfte bei + nicht stark auffallen, bei ! oder . sieht man das deutlicher). Der Nachteil ist, dass Betriebssysteme ohne Unicode-Zeichensätze vermutlich Fragezeichen o.ä. anzeigen; Browser ohne Unicode-Unterstützung (kA, ob's das überhaupt noch gibt), könnten vielleicht sogar dem Link nicht folgen. OS' ohne (zumindest teilweise) Unicode-Unterstützung gibt es aber praktisch kaum noch und Browser sollten eigentlich auch kein Problem mehr damit haben. Wenn keine großen Gegenargumente genannt werden, bin ich dafür, den französischen Titel zu übernehmen, wenn der alte Titel als redirect erhalten bleibt. Oder zumindest den Unicode-Titel als redirect auf diesen Artikel einzurichten (was ich noch nicht tue, um ein Verschieben nicht zu unnötig erschweren). --Christoph 18:12, 23. Aug 2005 (CEST)

So sieht der französische Titel bei mir aus: Datei:Cplusplus fr.png (mit Internet Explorer unter WinXP).

Also nicht so toll. --Poldi 19:55, 27. Aug 2005 (CEST)

Internet Explorer, tsetse... ;)

naja, über die Macken bestimmter Browser zu diskutieren führt zu nichts. Im Sinne der Kompatibilität habe ich einen auf C＋＋ einen Redirect hierher eingerichtet. Bleibt nur zu hoffen, dass eine zukünftige Wiki-Version Pluszeichen im Artikelnamen unterstützt. --Christoph 20:09, 27. Aug 2005 (CEST)

Aber welchen Sinn hat das jetzt? Der Titel ist ja immer noch falsch! --Poldi 13:13, 28. Aug 2005 (CEST)

Templates

Folgender Abschnitt wurde eingefügt:
Templates (generische Programmierung) haben ihre Vorteile, aber einen gravierenden Nachteil kann man mindestens mit existierenden Compilern nicht übersehen: Da der Templatecode erst bei der Instanziierung übersetzt wird, muss er in jedem Programm, das ihn benötigt als Quelle vorliegen. Das macht präcompilierten Code schwierig. Somit steigen die Übersetzungszeiten stark an. Die automatische Templateexpandierung führt tendenziell zu riesigen Maschinencodedateien.
Die Aussagen darin finde ich zu pauschal und ungenau. Der Laie kann damit außerdem ohne weitere Erläuterung zu wenig anfangen. Der Abschnitt sollte deshalb noch einmal überarbeitet werden. --Hades 20:24, 14. Sep 2005 (CEST)

Hallo, achte beim Rückgängimachen das nächstemal bitte darauf, Änderungen die nach dem Bemängelten aufgetreten sind, wieder einzupflegen. Gruß --Taschenrechner

weiteres Vorgehen

Was der Artikel braucht ...

eine Generalüberholung

nein braucht der nicht, der ist sehr gut und informativ!!!!

das heißt ja nicht, dass man ihn nicht noch verbessern kann

Was der Artikel nicht braucht ...

eine Änderung am Hallo-Welt-Programm
weitere Buchempfehlungen

ich finde, die beiden Bücher von Bruce Eckel dürfen nicht fehlen, er erhielt den Software Development Jolt Award: best book published für Thinking in C++ und die beiden Bücher sind kostenlos auf seiner Homepage, siehe Artkel über Bruce Eckel

Templates vs. generische Datentypen

Im Unterkapitel "Vergleich mit anderen Sprachen" steht das die Integration der generischen Datentypen von Java und C# in eine etwas andere Richtung als bei C++ geht was für mein Dafürhalten doch etwas schwammig formuliert ist. Genaugenommen handelt es sich bei Templates um etwas völlig anderes! Templates werden beim kompilieren erzeugt und sind deshalb eine Art Textersetzung, Generics hingegen werden erst zur Laufzeit auf best. Datentypen spezialisiert.

Vom Programierer aus gesehen dienen alle Konstrukte dem selben Zweck. Die Technik, die dahintersteckt ist verschieden. dibe 20:39, 4. Dez 2005 (CET)

Nein, Templates und Generics (wie die in C# und C++/CLI) dienen, bedingt durch die unterschiedlichen Konzepte, auch unterschiedlichen Zwecken. Die beiden Konzepte ergänzen sich. Es gibt zwar auch Überschneidungen, aber keines kann das andere vollständig ersetzen. In C++/CLI hat man aus diesem Grund beides!! --Knorxx 20:59, 4. Dez 2005 (CET)

Naja, man hat eher beides, weil C++/CLI C++ mit .NET verbinden soll und das eine nunmal templates, dass andere generics mit bringt. --Kingruedi 21:49, 4. Dez 2005 (CET)

Rechtschreibung

Bei den Compilern steht

Verbreitetster Compiler unter Windows; setzt ab der Version 7.1 die Sprache C++ nahezu vollständig um. Die Nachfolgeversion Visual C++ 2005 Express ist z.Zt. (2005) kostenlos erhältlich.

Die Abkürzung z.Zt. ist noch die alte Rechtschreibung,die Neue sieht zz. oder zzt. vor --Fornax-Galaxies 18:19, 20. Nov 2005 (CET)

Stimmt. Leider. Das ist IMHO ein Bug in der Neuen Rechtschreibung. Denn sonst wird doch alles mögliche neuerdings auseinander und groß geschrieben, und "zur Zeit" heißt doch "zu der Zeit". Das wollen die mit mal "zurzeit" schreiben. Ist ja echt zum Kotzen. :-( --RokerHRO 20:13, 20. Nov 2005 (CET)

Wenn etwas falsch geschrieben ist, dann korrigiere es doch bitte! --DocSnyder 19:03, 4. Dez 2005 (CET)

const

Dass C const von C++ abgeguckt hat, halte ich für ein Gerücht. Möglicherweise gab es Ergänzungen bzgl. const. const an sich existiert aber schon in C89. In K&R meines Wissens nicht. Ich habe allerdings keinen C89 oder ANSI C Standard zur Hand. Eventuell kann das jemand belegen und korrigieren. --Cyclonus

Im Stroustroup steht das afaik drin. C hatte lange keine Möglichkeit const auszudrücken. C++ kam dann wohl mit immutable, was dann aber geändert wurde, als C const einführte um kompatibel zu bleiben. Naja, werd das noch einmal nachlesen. --Kingruedi 14:08, 4. Dez 2005 (CET)

Stimmt, const war zuerst in C++ und wurde erst danach in C89 übernommen. --DocSnyder 19:03, 4. Dez 2005 (CET)

Nein, const wurde in C99 übernommen. C89 hatte kein const! Demnach hat es C "von C++ abgeguckt", oder besser gesagt, sie wollen die Sprachen nicht noch weiter auseinanderdriften lassen. --Philipp 19:36, 5. Mai 2006

Wirklich an (fast) alle: Man sollte erst mal sorgfältig nachlesen, auch wenn das Mühe macht. Und die Wirklichkeit ist einfach manchmal kompliziert. C (KR) hatte kein const. In C++ wurde das const lange konzipiert, bevor es nach C kam. Das C++-const wurde dann im C89-Standard für C übernommen. Es war für C und C++ zunächst identisch. Im Lauf der 1990er Jahre wurde es für C++ verbessert und modifiziert (Feldgrenzen-const, int const i) und der C++-Standard (1999) enthält ein verbessertes const, das nicht mehr mit dem C-const kompatibel ist. Dafür wurde in C (C99) ein weiterer nicht in C++ enthaltener qualifier restricted ergänzt. imutable ist kein C++, sondern Java.

Nee, nee, in Java gibt es kein "immutable". Dort gibt es "final".

Zeitskala:

1980er: C++-const 1980er: C89-const 1989: C89-Standard mit const 1990: Java-final/Java-imutable 1990er: C++-const-Verbesserungen 1998: C++ Standard 1999: C99 Standard mit unverändertem const/volatile und restricted --Brf 11:30, 24. Mai 2006 (CEST)

Unglückliche Formulierung

"Dies führte auch zur Entwicklung zahlreicher externer Bibliotheken (z.B. Boost), die ein teilweise unausgereiftes und uneinheitliches Bild von C++ vermitteln." -- Das liest sich, als ob Boost generell unausgegoren und/oder "überflüssig" wäre. Dabei ist sicher gemeint, daß für viele - eigentlich standardmäßige - Aufgaben, jeweils ein Haufen "externer" Bibliotheken für C++ existieren. - M. Moll 6.12.05

Wie wär's damit, den Verweis auf Boost einfach aus dem Satz zu streichen? Gibt ja keinen Grund, ausgerechnet diese externe Bibliothek zu erwähnen.

Das wäre eine Möglichkeit. Allerdings finde ich auch die Attributierung als "unausgereift" und "uneinheitlich" überzogen. --Poldi 17:49, 14. Jun 2006 (CEST)

Metatexte im Artikel

Im Artikel stand "Die Zersplitterung von C++ kann man auch an der Versionsgeschichte des Artikels erkennen, bei dem regelmäßig Änderungen am Hello World-Programm vorgenommen werden, die auf veralteten C++-Normen basieren".

Ein Text, der sich auf das Verfassen des Artikels bezieht, ist ein Metatext und gehört nicht in den Artikel. --Poldi 18:01, 25. Dez 2005 (CET)

Mehr Sorgfalt bei der Recherche

Das angegebene Papier "Why we can't afford export" ist schon lange überholt. Wenn das Papier Grundlage für die Behauptung im Artikel war, "export" werde in Zukunft entfernt, dann ist die Information schlicht und ergreifend falsch.
Es handelte sich übrigens nur um einen Vorschlag zur Entfernung des Sprachmittels "export". Ein Vorschlag ist aber noch kein Beschluss. Bitte genauer recherchieren! --Poldi 17:51, 25. Dez 2005 (CET)

Der Text sagte ja auch und vermutlich in C++0x nicht mehr enthalten sein wird. Beachte das vermutlich. Fakt ist einfach, dass aktuelle Compiler (bis auf den EDG basierten Comeau), nur noch in dem Punkt export nicht Standard kompatibel sind. Der Text erklärt ja auch wunderbar warum. Ich weiß nichts von aktuellerer Entwicklung zu diesem Thema. Bitte klär mich auf, wenn es aktuellere Entwicklung zu diesem Thema gibt. --Kingruedi 19:20, 25. Dez 2005 (CET)

Der Text sagte ja auch und vermutlich in C++0x nicht mehr enthalten sein wird - Gut, aber wodurch stützt du die Vermutung? Die Informationen, die wir hier anbieten, sollen ja eine gewisse Verlässlichkeit haben. Der Antrag in dem genannten Papier wurde jedenfalls zurückgewiesen. Das ist aber an sich nichts neues. --Poldi 19:18, 26. Dez 2005 (CET)

- 2006 -

Metaprogrammierung?

Sollte bei den Merkmalen nicht auch die Metaprogrammierung aufgeführt werden? Es ist schließlich auch ein Merkmal von C++, einerseits Template-Metaprogrammierung und andererseits makrobasierte Metaprogrammierung die man evtl sogar C als Merkmal hinzufügen könnte--Evilissimo 12:50, 13. Jan 2006 (CET)

Ja, würde bei beiden Artikeln grundsätzlich passen. Ob man es beim Präprozessor als Metaprogrammierung bezeichnen sollte, halte ich zumindest bei C für fraglich, aber ein interessantes Sprachmerkmal, da Alleinstellungsmerkmal, ist der Präprozessor allemal. --Poldi 11:09, 14. Jan 2006 (CET)

Compiler: Dev-C++ oder MinGW noch in die Liste?

Ich kenn mich jetzt noch nicht so mit programmieren und c++ aus aber ich hab gelesen (oder gehört?), dass MinGW auch ein guter Compiler sein soll und Dev-C++ soll auch praktisch sein? Wenn das stimmt, dann sollten die doch auch in der Compiler-Liste stehen, oder? Außerdem wär's vielleicht ganz gut, noch dazuzuschreiben, welche(r) Compiler gratis und welche(r) kostenpflichtig ist/sind .?

--Thomaswm 15:46, 30. Jan 2006 (CET)

MinGW ist nur eine minimalistische GNU-Umgebung für Windows. Daher der Name. Als Compiler wird GCC benutzt. Für dich als Einsteiger wäre aber eine - kostenpflichtige - integrierte Entwicklungsumgebung vielleicht besser geeignet. --RokerHRO 16:47, 30. Jan 2006 (CET)

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

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

Abschnitt: Vergleich mit anderen Sprachen

Hilfe! Das ist ja PPOV^3. Jede Menge Wertungen und "Meinungen von Fachleuten" ohne Quellen dazu. Der Abschnitt zur Objektorientierung zeigt das dessen Autor OOP wohl überhaupt nicht begriffen hat. --Revvar ⒟ 12:58, 29. Jan 2006 (CET)

Hallo Revvar!

Der Artikel hat keinen Abschnitt zur Objektorientierung. Könntest du etwas genauer ausführen, was genau du an dem Artikel inhaltlich für bedenklich hältst? --Poldi 19:23, 29. Jan 2006 (CET)

Meine den Abschnitt: "Vergleich mit anderen Sprachen" ;-) - und dort u.a. die Sätze zur OOP. Lese es dir den mal durch, wenn du dann nichts findest, schreib kurz. --Revvar ⒟ 19:56, 29. Jan 2006 (CET)

Tja, ich weiß tatsächlich nicht, worauf du hinauswillst. Kannst du deutlicher werden? --Poldi 18:14, 30. Jan 2006 (CET)

Hallo, ok, erst mal eine kleine Leseempfehlung;

und dann versuche ich dich mal zu erleuchten ;-):

„Objective-C hat sich aber nie wirklich durchgesetzt, bis auf ....“ - pauschalierte Abwertung - hier fehlt der Bezug - besser und richtig wäre die Formulierung aus Objective-C: „Objective-C konnte sich gegenüber C++ niemals wirklich durchsetzen,...“ - also auch wenn Hundertausende Objective-C benutzen, wird von Millionen noch C++ bevorzugt.

„Ein wesentlicher Unterschied zwischen diesen Sprachen und C++ besteht darin, dass C++ über generische Sprachmerkmale (Templates) verfügt.“ (diese Sprachen sind Java und C#) - dieser wesentliche Unterschied gehört ihmo klar zu den weniger Wichtigeren. Der ganze nachfolgende Vergleich, wie schlecht doch die Umsetzung in Java und C# ist, gehört ohne Quellen in der Form in die PPOV-Tonne. Einen Sprachvergleich nur an der Umsetzung generischer Typen zu machen halte ich für viel zu einseitig - die darauffolgende Verknüpfung mit der angeblichen Rückläufigkeit der OOP setzt den ganzen noch die Krone auf - auch hier wieder eine Pauschalisierung ohne Quellen. Generische Programmierung und OOP sind zwei Konzepte die sich überhaupt nicht ausschließen - hier wird aber genau das unterstellt. Wer glaubt das Polymorphismus das Kernkonzept der OOP sei, und weiterhin annimmt das dies nur eine Variante eines generischen Types ist - der hat die ganzen Themen nicht verstanden.

und das Beste zum Schluß

„Auch in Punkto Wiederverwertbarkeit einmal kodierter Algorithmen übertreffen generische Techniken nach Meinung vieler Fachleute die objektorientierte Programmierung.“ - dafür hätte ich doch gerne mal die Quelle, insbesondere interessiert mich wer diese Fachleute sind.

Gruß --Revvar ⒟ 10:22, 31. Jan 2006 (CET)

Ich stimme zu, der Abschnitt hat ein paar Schwachstellen. Er wurde eben von mehreren Leuten erstellt, und eine Überarbeitung steht eigentlich noch aus. Allerdings ist auch nicht alles völlig daneben. Zu den Punkten im Einzelnen:

besser und richtig wäre die Formulierung aus Objective-C: „Objective-C konnte sich gegenüber C++ niemals wirklich durchsetzen,...“ Ich stimme zu, das ist besser. Allerdings gewinnt man so den Eindruck, Objective-C sei gegen C++ positioniert worden. Vielleicht können wir an der endgültigen Formulierung noch etwas feilen.

Zu in Punkto Wiederverwertbarkeit einmal kodierter Algorithmen übertreffen generische Techniken objektorientierte Programmierung und zur angeblichen Rückläufigkeit der OOP: Die Container der Standardbibliothek sind ein Beleg dafür. Sie verwenden generische Techniken an Stelle von Polymorphie. Ein Vorteil besteht darin, dass sich dadurch auch nicht auf Klassen basierende Typen, wie z.B. die integrierten Typen, effizient verwalten lassen. Die ersten Versionen der Standardcontainer waren noch mit Hilfe von Polymorphie umgesetzt. Später wurden sie zu einem großen Teil durch Generik ersetzt.

Generische Programmierung und OOP sind zwei Konzepte die sich überhaupt nicht ausschließen - hier wird aber genau das unterstellt. Ich sehe eigentlich nicht, wo das unterstellt wird. Kannst du noch einmal näher erklären, worin genau du das siehst?

Wer glaubt das Polymorphismus [...] nur eine Variante eines generischen Types ist - (ich hoffe, ich habe durch die Auslassung ([...]) nicht den Sinn deiner Aussage entstellt) Hier sehe ich nicht, wo der Text das sagt.

Polymorphismus das Kernkonzept der OOP Die Formulierung ist nicht gut, enthält aber einen "wahren Kern": Zur Bedeutung der Polymorphie für die objektorientierte Programmierung in C++ äußert sich B. Stroustrup in seinem Buch "Die C++-Programmiersprache", und zwar in Abschnitt 2.6 (objektorientiertes Programmierparadigma). Dort sagt er sinngemäß in etwa, dass genau solche Programmiersprachen die objektorientierte Programmierung unterstützen, die auf Vererbung basierende Polymorphie ermöglichen.

So viel erst mal. Schreib mal, was du darüber denkst. Gruß --Poldi 12:49, 4. Feb 2006 (CET)

"Die Spracherweiterung bei Java erreicht jedoch bei weitem nicht die Leistungsfähigkeit von C++-Templates." Das ist purer PPOV. Bar jeglicher Begründung. Entweder Begründung rein (am besten erst hier diskutieren, sonst kommt auch noch was falsches dabei raus), oder Satz raus.

"Während die objektorientierte Programmierung in Java und C# nach wie vor den zentralen Abstraktionsmechanismus darstellt, ist diese Art der Programmierung in C++ rückläufig." finde ich in mehrerer Hinsicht zu beanstanden.

Generik ist durchaus in der Lage ist, Vererbung zu ersetzen - aber nur dort, wo Vererbung das Verhalten nicht wirklich ändert und somit eigentlich semantisch gar nicht angebracht ist. Insgesamt daraus Schluss zu ziehen, dass aufgrund der Generik die Polymorphie auf dem Rückzug ist, stellt die Sache meiner Meinung nach aber in einem falschen Licht dar und könnte beim Leser den Eindruck einer Lehrmeinung erwecken, man würde in Zukunft nicht mehr polymorph programmieren.
Woher kommt die Aussage, OOP sei in Java und C# nach wie vor (klingt wie immer noch) der zentrale Abstraktionsmechanismus, nicht aber in C++? Handelt es sich wirklich um einen Unterschied an den Sprachen? Spätestens seit Generics ist es wohl er ein kultureller, nicht sprachlicher Unterschied. Die Collections sind in Java 5.0 alle auf Generics umgestellt. Funktionen wie Vergleichen und Sortieren waren im Java Collections API immer schon weniger auf Vererbung ausgerichtet als vielmehr auf Parametrisierung, nur fehlte mangels Generics bis dato die Typsicherheit.
Ich finde schon, dass die Formulierung so klingt, als würden sich Polymorphie / Vererbung und Typparametrisierung ausschließen.
Allgemein ist Polymorphie nur aufgrund ihrer Existenz natürlich noch lange kein Heilmittel. Ich kann in Java jedoch nicht erkennen, wo sich Polymorphie durch Generics ersetzen lässt. Bei Generics geht es um Typsicherheit an Stellen, in denen von der Semantik her bereits Ähnlichkeiten zu C++-Templates vorhanden sind.
Dass man in C++ an den Stellen, an denen man Polymorphie tatsächlich durch Templates ersetzen kann, dies auch tut, halte ich weniger für ein Entwurfs-, als vielmehr für ein Performance-Thema. Java und C# schlagen mit ihren derzeitigen VMs von SUN, IBM, Microsoft etc. bei der Laufzeit virtueller Methodenaufrufe die meisten C++-Compiler um häufig relevante Größen. Hier wird also ein Performance-Problem von C++-Compilern zu einer allgemeinen Entwurfsthematik stilisiert und anschließend auf andere Sprachen übertragen, die dieses Performance-Problem gar nicht haben. Vererbungshierarchien sind in Java oder C# kein Problem. In Java stellt die durch übliche Programmierpraxis entstehende Flut zusätzlicher Klassen durch anonyme Klassen ein Problem dar, das in C# durch Delegates elegant gelöst wird und in Java häufig durch Reflections minimiert werden kann.
Templates sind in C++ auch nicht sooo toll, gerade weil der Compiler für jede Typparametrisierung eine neue Klasse erzeugt. Die Zahl der Klassen ist natürlich für die Performance eines Programms relevant, sie muss einfach stimmen (natürlich zusammen mit der Verantwortlichkeit). Vererbung durch Templates zu ersetzen, reduziert aber nicht die Zahl der tatsächlichen Klassen, sondern höchstens die Zahl der explizit geschriebenen Klassen. Neuer Code entsteht trotzdem, oder vielleicht sogar mehr. Der Performance-Gewinn durch Wegfallen virtueller Methoden geht durch mehr und redundanten Code bei Templates und damit mehr Cache-Misses zumindest zu einem kleinen Teil wieder verloren.

"Auch in Punkto Wiederverwertbarkeit einmal kodierter Algorithmen übertreffen generische Techniken nach Meinung vieler Fachleute die objektorientierte Programmierung." Ohne Quelle absoluter Nonsense, und wäre selbst mit Quelle erstmal diskussionswürdig.

"Im Gegensatz zu C++ handelt es sich bei Objective-C wirklich nur um einen Aufsatz auf die Programmiersprache C." Wann ist etwas ein Aufsatz auf eine Sprache und wann nicht? Warum ist Objective-C ein Aufsatz, C++ aber nicht? Und wenn C++ kein Aufsatz ist, was ist C++ dann und warum ist Objective-C genau das nicht?

Ich habe wegen all dieser Punkte das ganze Kapitel neu geschrieben. Es ist sicher nicht perfekt, aber es geht mehr auf die Unterschiede ein und ist hoffentlich neutraler. --ChristianHujer 18:41, 3. Mär 2006 (CET)

Den folgenden Satz verstehe ich nicht: „Andere Aspekte der C++-Templates werden in Java durch Interfaces realisiert.“ Welche Aspekte sind dies? --jpp ?! 21:47, 3. Mär 2006 (CET)

Ich habe den Satz mal entfernt, bis er erklärt wird. Ich verstehe auch nicht, wie Interfaces Templates ersetzen könnten. --Kingruedi 21:57, 3. Mär 2006 (CET)

Hallo ChristianHujer,
deine Anmerkungen finde ich zum Teil nachvollziehbar, ich habe aber auch Einwände, sowohl was deinen Beitrag hier auf deiner Diskussionsseite betrifft, als auch deine Änderungen am Artikel.

Fangen wir mal mit der Diskussion an:

Eine Frage zu PPOV (personal point of view). Was genau verstehst du darunter?
dass aufgrund der Generik die Polymorphie auf dem Rückzug ist, stellt die Sache meiner Meinung nach aber in einem falschen Licht dar – Vor deinen Änderungen stand im Artikel "So werden tiefe Klassenhierarchien vermieden, und zu Gunsten der Effizienz und der Minimierung des Ressourcenverbrauchs verzichtet man in vielen Fällen auf Polymorphie". Das entspricht den Tatsachen. Bestes Beispiel sind die Container in der C++-Standardbibliothek. Ich schlage vor, wir stellen diese Passage wieder her.
Spätestens seit Generics ist es wohl er ein kultureller, nicht sprachlicher Unterschied. – Nein, es ist ein wesentlicher Unterschied zwischen den Sprachen, denn Templates unterscheiden sich von Generics fundamental. Wir müssen aber mit der Bezeichnung Generics aufpassen, denn auch die Konzepte in Java und C# unterscheiden sich stark voneinander, so dass man sie nicht über einen Kamm scheren kann. Ein Unterschied zwischen Templates und Java-Generics besteht darin, dass sich Java-Generics nicht auf integrierte Typen wie int anwenden lassen. Einen Hauptunterschied zwischen Templates und C#-Generics würde ich so charakterisieren, dass Templates einen Kompilationszeitmechanismus darstellen, C#-Generics dagegen einen Laufzeitmechanismus.
Ich finde schon, dass die Formulierung so klingt, als würden sich Polymorphie / Vererbung und Typparametrisierung ausschließen. – Auf welchen Satz beziehst du dich dabei?
Java und C# schlagen mit ihren derzeitigen VMs von SUN, IBM, Microsoft etc. bei der Laufzeit virtueller Methodenaufrufe die meisten C++-Compiler um häufig relevante Größen. – Glaube ich nicht. Woher sollte dieser Performance-Unterschied kommen? Kannst du deine Darstellung belegen?
Templates sind in C++ auch nicht sooo toll, gerade weil der Compiler für jede Typparametrisierung eine neue Klasse erzeugt. – Nein, das tut er nicht. Er tut es allenfalls bei unterschiedlichen Typparametern (Du kannst z.B. immer wieder vector<int> schreiben.), und auch dann nicht immer. Und selbst wenn er es tun würde, wäre das nicht unbedingt ein Problem.
Die Zahl der Klassen ist natürlich für die Performance eines Programms relevant – Eher nicht. Eine Rolle spielt viel mehr die Zahl der Objekte.
Vererbung durch Templates zu ersetzen, – Nicht Vererbung, sondern Polymorphie!

Gruß --Poldi 15:35, 5. Mär 2006 (CET)

Vielen Dank Christian Hujer! Das sieht schon bedeutend besser aus. Schönen Gruß --Revvar %&§ 19:40, 5. Mär 2006 (CET)

Hallo Revvar, ich habe mich eigentlich gewundert, dass du dich nicht mehr gemeldet hast. Du bist mir noch eine Antwort schuldig (s.o.). Hoffe, dass du dich noch dazu äußerst. --Poldi 19:55, 5. Mär 2006 (CET)

Schade, dass ihr euch nicht mehr meldet. Ich habe erhebliche Einwände gegenüber den Änderungen vom 3.-5.März. Die vorangegangene Fassung ist zwar auch nicht das Gelbe vom Ei, aber demgegenüber besser. Ich hätte das gerne hier diskutiert, aber da sich nichts rührt, habe ich den Abschnitt erst einmal im Wesentlichen auf den Stand vor dem 3.März zurückgestellt. Gruß, --Poldi 20:58, 8. Mär 2006 (CET)

Langsam, Langsam! Du kannst nicht erwarten, dass alle Leute, die jemals was geändert haben, alle 10 Sekunden diesen Wiki-Artikel anschauen! Dein Verhalten hat bei mir gerade ziemlichen Wiki-Frust ausgelöst. en:Edit_war "Wenn in 20 Tagen keiner widerspricht, ändere ich's zurück" - das wäre okay gewesen, absolut okay, aber nach 5 Tagen einfach zurückändern, ohne dass jemand anderes überhaupt auch nur Zeit für Diskussion oder Kommentar hat, ist ja schlimmer als Erpressung ;) --ChristianHujer 02:20, 17. Mär 2006 (CET)

Die Programmiersprachen Java und C# sind nicht mit C++ kompatibel. Sie haben zwar eine ähnliche Syntax wie C++, trotz dieser Ähnlichkeit unterscheiden sie sich aber in ihrer Semantik, also in dem, wofür die Syntaxelemente stehen, von C++ teilweise beträchtlich.

Ich finde die Syntax von C++ und Java/C# nicht sonderlich ähnlich. Die Gemeinsamkeiten kommen zum größten Teil durch die C Grundlage. Der Rest unterscheidet sich doch enorm. Okay, es gibt einige neu eingeführte Keywords die ähnlich sind wie class (und und ...) aber im groben und ganzen ist die Syntax einfach anders. --Kingruedi 21:30, 8. Mär 2006 (CET)

Würdest du den Satz anders formulieren? Falls ja: wie? --Poldi 21:24, 10. Mär 2006 (CET)

@Poldi: Ich hab' ja nix dagegen, dass man Änderungen, die jemand anderes durchführt, nachbearbeitet - das ist die Natur eines Wikis. Muss man sie deshalb gleich mit der Axt im Walde vollständig entfernen? Wenn Du Dich so gut auskennst, hättet Du ja die paar Deiner Meinung nach fehlenden Punkte, z.B. Templates in C++ führen zu mehr Code durch mehr compilierte Klassen, Generics in Java funktionieren nur mit Objekten aber nicht mit Primitiven, ja einfach ergänzen können. Echt Schade. Ich habe meine Lust, diesen Artikel zu verbessern, jedenfalls gründlich verloren. Ich hätte mir echt gewünscht, dass Du zumindest den Text verbesserst, statt ihn komplett zu löschen. Zumal, das behaupte ich jetzt mal einfach, der allergrößte Teil dessen, was ich geschrieben habe, ziemlich einwandfrei, sachlich und NPOV war. Du hast es aber einfach alles gelöscht und machst es Dir etwas arg einfach. Darüber kannste natürlich anderer Meinung sein, und das können wir gerne diskutieren. Dafür, hier an diesem Artikel noch etwas zu verbessern, ist mir meine Zeit aber echt zu schade. Prima gemacht, Poldi, echt prima.

@Poldi zu 1.: Das ergibt sich dann aus 2. und 3..

@Poldi zu 2.: Wo brauche ich in Java denn eine tiefere Klassenhierarchie als in C++? Es ging doch um einen Vergleich C++ mit Java und / oder C#. Nicht zu vergessen, dass Polymorphie in C++ meist mehr Resourcen verbraucht als in Java oder C#, was aber nicht an der Sprache C++, sondern den Compilern liegt.

@Poldi zu 3.: Nun übertreib' mal nicht. So, wie der Artikel vorher klang, warf er wirklich ein falsches Licht auf Java und C#. Er hat folgendes behauptet: "Die Spracherweiterung bei Java erreicht jedoch bei weitem nicht die Leistungsfähigkeit von C++-Templates." Das ist ist eine subjektive Ansicht. Umgekehrt kann man ja behaupten, die Generics in Java seien leistungsfähiger als die C++-Templates, weil sie nicht zu einer Klassenflut führen und damit zu kleinerem und effizienterem Code. Weil für jede Typparametrisierung in Java derselbe Code ausgeführt wird, wird man bei großen Java-Programmen weniger Program-Cache-Misses haben als bei vergleichbaren C++-Programmen.

@Poldi zu 4.: Damit war gemeint: "Während die objektorientierte Programmierung in Java und C# nach wie vor den zentralen Abstraktionsmechanismus darstellt, ist diese Art der Programmierung in C++ rückläufig. So werden tiefe Klassenhierarchien vermieden, und zu Gunsten der Effizienz und der Minimierung des Ressourcenverbrauchs verzichtet man in vielen Fällen auf Polymorphie, den Kernmechanismus der objektorientierten Programmierung." (Ich betrachte übrigens Typparametrisierung nicht als Polymorphie. Ein Typparameter verändert nämlich nicht das Verhalten einer Klasse. Wobei ich nicht sagen möchte, dass so eine Betrachtungsweise falsch ist, zumal ich die diesbezügliche - ist Typparametrisierbarkeit eine Form der Polymorphie oder nicht - Lehrmeinung nicht kenne.) Nichtsdestotrotz klingt das so, als a) sei Programmierung mit Templates nicht objektorientiert, b) würde man in C++ weniger objektorientiert programmieren als früher, c) würde man in Java oder C# (egal ob mit oder ohne Generics) tiefere, eventuell zu tiefe Klassenhierarchien bekommen. Abgesehen davon, dass das subjektiv ist, halte ich das einfach für nicht richtig.

@Poldi zu 5.: Das stand mal in einem Magazin, schade dass ich es nicht aufgehoben habe. Falls es eine iX oder c't war, werde ich den Artikel schon wieder finden (Abo+). Vielleicht schaffe ich es aber auch, aus dem Kopf die Code-Demo-Beispiele zu rekonstruieren. Falls ja, poste ich's hier. Zu Templates: Wie schon gesagt, in Java weniger Code und deshalb weniger Cache Misses. Abgesehen davon ist das auch garnicht so relevant, weil davon ja nix im Artikel steht oder stand. Würde ich erst in den Artikel schreiben, bis ich's mit einer Quelle belegen könnte, und dafür muss ich erst noch suchen. Oder wollen wir jetzt auch noch eine Diskussion um die Diskussion führen?

@Poldi zu 6.: Wenn ich zweimal vector<int> verwende, ist das für mich ein und dieselbe Typparametrisierung. Okay, das war von mir vorher misverständlich formuliert. Der Compiler erzeugt aber für vector<a> und vector<b> mindestens dann zumindest teilweise unterschiedlichen Code, wenn a und b nicht dieselbe Größe haben - oder er schaut die Größe nach, dann ist der Code aber nicht mehr ganz so schnell. Spätestens, wenn eine Template-Klasse als Wert wiederverwendet wird, kommen wir in hakelige Bereiche. Schaut er die Größe nicht nach, und einige Compiler tun das meines Wissens nach eben nicht, führt das definitiv zu mehr Code, und mehr Code führt zwangsläufig zu mehr ProgCache-Misses und damit zu weniger Performance.

@Poldi zu 7.: Die Zahl der Klassen natürlich erstmal nicht primär, aber im Falle von C++-Templates vs. Java Generics eben schon. Während ich für ArrayList in Java immer nur eine Klasse und einen Code habe, egal wieviele verschiedenen Typparameter ich zur Parametrisierung der Klasse einsetze, entstehen in C++ für Typparameter mindestens bei unterschiedlicher Typparametergröße unterschiedliche Klassen und damit mehr Code. Ist schon beim g++ zu beobachten: int main() { vector<int> vec1; } ist bei mir 13159 Bytes groß, int main() { vector<int> vec1; vector<short> vec2; } ist bei mir 14500 Bytes groß. Der Nachteil der Java-Implementierung ist, dass erstmal kein Laufzeit-Check stattfindet. Zumindest für Collections kann man diesen aber mittels Collection.checked*() haben. All diese Vergleichsergebnisse sollten beschrieben werden, ich würde mich jedoch nie zu einer Pauschalaussage hinreißen lassen, die die Java- oder C++-Lösung von Typparametrisierung als die allgemein bessere bezeichnet. Ich persönlich finde die Java-Lösung zwar besser, bin mir jedoch dessen bewusst, dass das eine subjektive Meinung ist, und würde es deshalb nicht wagen, soetwas in einem Artikel zu behaupten.

@Poldi zu 8. siehe 4..

@Poldi Mehr zur Performance:

In iX 2005-10 gibt es einen Report: Webprogrammierung "Zieleinlauf mit Java" - Auslieferungsmethoden im Performancevergleich. Hier schlug Java soziemlich alles, mehr oder weniger auch FastCGI. Ist ein nicht grundsätzlich verallgemeinerbares Spezialgebiet, aber auf jeden Fall schonmal interessant.
Wie schon gesagt, da war mal ein Artikel über das Laufzeitverhalten von virtuellen Methodenaufrufen in einem Magazin vor ca. 1-2 Jahren. Ich hab' aber aufgehört, alte Magazine zu sammeln. Vielleicht habe ich den Artikel auf CD. Wenn ich ihn gefunden habe, werde eine Referenz sofort hier einfügen.
Das Buch "Einführung in die Informatik" (Gumm / Sommer, Oldenburg, 4. Auflage August 1999) enthält ebenfalls einen interessanten Vergleich, und zwar bezüglich Sortieralgorithmen. Aus dem Buch: Laufzeit mit N=4000000 bei zufällig sortierten Daten in Sekunden; ShellSort Java 13,2s, C++ 11,4s; DistributionSort Java 2,5s, C++ 2,5s. "Dabei zeigt sich, dass die Java-Version von DistributionSort nicht langsamer ist als die C++-Version." Die eingesetzte Java-Version ist mir unbekannt, ich vermute (1999) 1.3.x. C++-Compiler war laut Buch Microsoft Visual C++ 6, gleiche Maschine (Pentium II 450 MHz).
Außerdem empfehle ich, einfach mal selbst einen Vergleich C qsort() (meist original Quicksort) vs. Java Arrays.sort() / Java Collections.sort() (je nach Typ Introsort-ähnlich oder Mergesort) vs. STL's sort() (seit SGI's Änderungen ein Introsort) anzustellen, mal ohne, mal mit Optimierung im Compiler, mal mit primitiven, mal mit Objektreferenzen. Das Ergebnis ist wirklich interessant. Sollte ich meine Performance-Test-Suite mal in einen veröffentlichbaren Zustand bringen, gibt's hier natürlich einen Link.

@Poldi: Dass Du den Satz "Auch in Punkto Wiederverwertbarkeit einmal kodierter Algorithmen übertreffen generische Techniken nach Meinung vieler Fachleute die objektorientierte Programmierung." trotz der klaren und mit Leichtigkeit nachvollziehbaren Kritik mit wiederhergestellt hast, hat mich einerseits überrascht und andererseits gewisse Zweifel geweckt. Kannste bitte bitte eine Quelle zur Belegung dieser Aussage liefern? Ich glaub's nämlich nicht. Wirklich nicht. Wer sind die Fachleute? Was behaupten sie? Wo behaupten sie das? Womit wurde gemessen?

Für mich ist jedenfalls dank Poldi die Arbeit am Artikel gestorben. Ich diskutier' gern' noch ein bisschen, aber für Edit Wars bin ich nicht der Typ. Ohne dass jemand anderes als Poldi das Thema in der Diskussion kommentiert, damit ich mir losgelöst von meiner eigenen Meinung nochmal neu ein Bild machen kann, werde ich nichts mehr am C++-Artikel ändern. --ChristianHujer 02:20, 17. Mär 2006 (CET)

Revert der Rückstellung

Die Änderungen von ChristianHujer haben den Artikel stark verbessert, insbesondere in den Formulierungen auch neutraler und imho realistischer gestaltet. Ich kann die totale Rückstellung so überhaupt nicht nachvollziehen und empfinde sie stark als kontraproduktiv. Lieber Poldi, die Wikipedia lebt vom Konsens, und anstatt hier nur zu diskutieren könntest du dich auch an der Arbeit am Artikel konstruktiv beteiligen - wenn dir dafür die Zeit fehlt, wie mir momentan, steht es dir auch nicht zu die Arbeit anderer Nutzer so einfach vom Tisch zu wischen.

Zu deinen Anmerkungen vom 12:49, 4. Feb 2006 (CET):

Du hast recht, lass uns dies tun.
"Die Container der Standardbibliothek sind ein Beleg" - dem kann ich nicht zustimmen. Man kann die Standardbibliotheken nicht mit allen Programmarten gleichsetzen. In der Bibliothek geht es vor allem um Geschwindigkeitsoptimierung bei relativ geringer Komplexität der Softwarestruktur.
siehe deine Frage zu 2. im nächsten Abschnitt, dort antwortest du dir sie selbst
Polymorphismus ist nicht das Kernkonzept, sondern ein Merkmal von vielen.

Zu deinen Fragen an Christian vom 15:35, 5. Mär 2006 (CET):

siehe Wikipedia:NPOV
siehe 2. oben
Zustimmung - das kannst du in den Text auch einarbeiten
Also wenn dir das beim lesen des alten Textes nicht auffällt, ok -ich verstehe es so.
Kann ich dir belegen: Siehe [1] , wenn dir die c't fehlt, dann melde dich, ich kann dir die relevanten Aussagen zumailen.
Kein Streitpunkt, ihr sagt beide das selbe ;-)
Da hast du recht.
-

--Revvar %&§ 13:18, 17. Mär 2006 (CET)

@Revvar: Es ist üblich, nach einem Revert erst die unterschiedlichen Meinungen auszudiskutieren. Also lass uns erst einmal versuchen, hier zu einem Konsens zu kommen. --Poldi 11:10, 18. Mär 2006 (CET)

Besprechung der zur Diskussion stehenden Punkte folgt ...
... --Poldi 11:10, 18. Mär 2006 (CET)

Ohne im Detail auf diese verquere Diskussion eigehen zu wollen bin ich der Meinung, dass Christians Version durchaus eine saubere Basis ist mit der fortgefahren werden kann. Einzelne Änderungen können ja hier noch diskutiert und vorgenommen werden, aber auf eine alte Version zu reverten weder fair noch angebracht. Ausserdem bitte ich jeden hier entsprechende Behauptungen mit Quellen zu belegen. Es werden hier ja durchaus komplexe Themen auf einem Niveau diskutiert welches eher mit einem Religionskrieg gleichzusetzen ist. Bzgl. der Details: Ich würde Polymorphismus (ein Feature, kein Kernkonzept) nicht mit Templates vergleichen. In gewissen Situationen lässt sich vielleicht beides nutzen (mir fiele spontan keine ein), aber beides sind unterschiedliche Konzepte mit unterschiedlichen Anwendungen. Sonst würde sich auch nicht beides im Sprachumfang von C++ finden. Zu den Performance-Vergleichen: Diese sind allgemein sehr von der Anwendung abhängig und sollten wenn überhaupt, dann nur mit verschiedenen Beispielen (belegt) gezogen werden. Zuletzt bleibt noch zu erwähnen, dass der Umfang oder die Funktionsweise eine Standard-Bibliothek keine Rückschlüsse auf die Sprache selbst zulässt. Wie bei den Performance-Vergleichen gibt es verschiedene Anwendungen für diese die Bibliotheken besser oder schlechter passen. Nicht umsonst liefern verschiedene C++-Compiler Suites verschiedene Bibliotheken mit. --Manuel Schneider 12:10, 18. Mär 2006 (CET)

Ich stimme Revvar zu, die Änderungen von ChristianHujer haben den Artikel neutralisiert und verbessert. Punkte die mir an der jetztigen Version auffallen:

„Die Programmiersprachen Java und C# sind nicht mit C++ kompatibel.“ Hallo? Äpfel und Birnen?
„Ein wesentlicher Unterschied zwischen diesen Sprachen und C++ besteht darin, dass C++ über generische Sprachmittel (Templates) verfügt. Es gibt mittlerweile in Java und C# generische Typen.“ Java und C# haben keine generischen Sprachmittel (Satz 1). Java und C# haben generische Sprachmittel (Satz 2). Sind das Schrödinger-Sprachen?
Es wird nicht klar, weshalb die Sprachmittel in Java/C# nicht die Leistungsfähigkeit von C++ erreichen bzw diese nicht ersetzen können. Das einzige genannte Kriterium ist Compile time und das ist so ziemlich das irrelevanteste Kriterium, das man auftreiben kann.
„Gerade die generische Programmierung macht C++ zu einem mächtigen Programmierwerkzeug.“ Klar POV.
„So werden tiefe Klassenhierarchien vermieden, und zu Gunsten der Effizienz und der Minimierung des Ressourcenverbrauchs verzichtet man in vielen Fällen auf Polymorphie, den Kernmechanismus der objektorientierten Programmierung.“ a) Polymorphie ist lediglich ein Mechanismus unter vielen, b) sind das keine Sprach- sondern Compilereigenschaften und c) Worauf beziehen sich „Effizienz” und „Ressourcenverbrauch“? Runtime? Compiletime? Devtime? TLOC? Kaffeeverbrauch der Devs? (Is’ ja nun auch ’ne wichtige Ressource.)
„Auch in Punkto Wiederverwertbarkeit einmal kodierter Algorithmen übertreffen generische Techniken nach Meinung vieler Fachleute die objektorientierte Programmierung.“ Paper bitte.

Kurz: Bitte wieder auf Version von YurikBot reverten. —mnh · [∇] · [⇵] · 12:52, 18. Mär 2006 (CET)

Nein. Ein wildes Hin- und Herändern ist kontraproduktiv. Wir werden hier in dieser Diskussion auf eine Artikelverbesserung hinarbeiten, und zwar unter Berücksichtigung aller Beiträge, auch derer von Christian. Ich bin gar nicht der Meinung, der Artikel sei perfekt. Die Bemerkung ganz oben auf dieser Seite: "was der Artikel braucht: eine Generalüberholung" ist übrigens von mir. Es haben mehrere Autoren zu unterschiedlichen Zeitpunkten an dem Artikel geschrieben, was man ihm leider überdeutlich anmerkt. Ich werde im Laufe des Tages auf die Einzelheiten eingehen. --Poldi 13:42, 18. Mär 2006 (CET)

Ein wildes Hin- und Herändern ist kontraproduktiv. - Ja warum machst du es dann? Genau das wird dir ja gerade vorgeworfen. Anstatt du die Änderungen verbesserst, die du auch selbst nicht komplett abgelehnt hattest, revertierts du auf eine mehrheitlich kritisierte Version. --Revvar %&§ 14:01, 18. Mär 2006 (CET)

Zunächst einmal eine Sache vorweg: Hier ist mehrfach der Vorwurf gefallen, der Artikel sei nicht neutral geschrieben. Auch so ein Vorwurf muss aber begründet werden. Es reicht nicht aus, ihn einfach in den Raum zu stellen. Wir kennen doch gar nicht die Beweggründe, die den jeweiligen Autor zu einer bestimmten Darstellungen veranlasst hat, und da es hier nicht um weltanschauliche sondern um technische Dinge geht, die grundsätzlich belegbar sind, schlage ich vor, den pauschalen Vorwurf der fehlenden Neutralität fallen zu lassen. Er ergibt hier einfach keinen Sinn. Entweder, etwas ist richtig, oder es ist falsch. Alles andere ist irrelevant. --Poldi 18:40, 18. Mär 2006 (CET)

zu Christians Beiträgen:

Ich gehe zunächst auf technische Inhalte ein, später auf Aspekte der Artikelstruktur:

Wo brauche ich in Java denn eine tiefere Klassenhierarchie als in C++? Es ging doch um einen Vergleich C++ mit Java und / oder C#. Der Teil ist anscheinend vor der Einführung von Generik in Java verfasst worden und kann so, oder zumindest im Abschnitt mit dem Sprachenvergleich tatsächlich nicht stehen bleiben.

Na was stellste ihn dann wieder her? --ChristianHujer 18:29, 26. Mär 2006 (CEST)

Nicht zu vergessen, dass Polymorphie in C++ meist mehr Resourcen verbraucht als in Java oder C#, was aber nicht an der Sprache C++, sondern den Compilern liegt. Aha, es liegt gar nicht an der Sprache! Folglich ist es kein Sprachunterschied.

Das ist Meta-Diskussion und stand eh nicht im Artikel. Ich werde mich, um's kurz zu halten, auf die den Artikel betreffenden Aspekte beschränken. --ChristianHujer 18:29, 26. Mär 2006 (CEST)

"Die Spracherweiterung bei Java erreicht jedoch bei weitem nicht die Leistungsfähigkeit von C++-Templates." Das ist ist eine subjektive Ansicht. Nein, das ist eine fundierte Ansicht. Du kannst dir ja mal den Artikel zur C++-Metaprogrammierung durchlesen, dann dürfte dir klar werden, dass das in Java nicht einmal im Entferntesten möglich ist.

Gut, Metaprogrammierung ist mit Templates in Java nicht möglich. Dafür kann ich in Java Annotations zur Code-Erzeugung nutzen. Weil aber die meisten Leute unter Templates lediglich die normale Typparametrisierung verstehen, hätte man den Text auch erweitern können. Was wäre denn das Problem gewesen, zu schreiben, "C++-Templates ermöglich auch die Metaprogrammierung, während Generics in Java lediglich der Typparametrisierung dienen." --ChristianHujer 18:29, 26. Mär 2006 (CEST)

Nichtsdestotrotz klingt das so, als a) sei Programmierung mit Templates nicht objektorientiert, ... Den Einwand finde ich nicht ganz nachvollziehbar, aber wenn dir eine Formulierung einfällt, die das Missverständnis vermeidet, dann her damit. Dass es aber Fälle gibt, in denen generische Techniken die objektorientierten in der Tat ganz ersetzen (s. die Standardcontainer), sollte dennoch klar sein.

Wo ersetzen bei den Standardcontainern generische Techniken die objektorientierten? --ChristianHujer 18:29, 26. Mär 2006 (CEST)

Das stand mal in einem Magazin, schade dass ich es nicht aufgehoben habe. Falls es eine iX oder c't war, werde ich den Artikel schon wieder finden (Abo+). Vielleicht schaffe ich es aber auch, aus dem Kopf die Code-Demo-Beispiele zu rekonstruieren. Falls ja, poste ich's hier. Ja, am besten hier. Fände ich jedenfalls interessant. Ich glaube aber nicht dran :-)

"Auch in Punkto Wiederverwertbarkeit einmal kodierter Algorithmen übertreffen generische Techniken nach Meinung vieler Fachleute die objektorientierte Programmierung." Den Satz kann man so wirklich nicht stehen lassen. Ein pauschaler Verweis auf Fachleute, die aber nicht näher genannt werden, ist der Wikipedia nicht würdig.

Und wieso hast Du ihn dann wiederhergestellt?

... mehr dazu folgt ... --Poldi 18:40, 18. Mär 2006 (CET)

@Poldi: So, nachdem Du also auch einiger Kritik an der alten Fassung zugestimmt hast, würde ich doch wirklich gerne von Dir wissen, was Dir an der neuen Fassung so schlecht gefallen hat, dass Du sie mehrfach revertet hast. --ChristianHujer 23:20, 18. Mär 2006 (CET)

Hallo Christian, das will ich gerne tun. Meine Diskussionsbeiträge gehen zwar schon auf wichtige Punkte ein, aber ich will dir gerne eine detaillierte Aufstellung aller Kritikpunkte an deiner Fassung zusammenstellen. Ich melde mich morgen oder übermorgen hier zurück. Gruß, --Poldi 13:22, 19. Mär 2006 (CET)

Deine Diskussionsbeiträge sind bislang größtenteils Metadiskussion. Sie gehen auf meine Diskussionsbeiträge und meine Kritik an der ursprünglichen Fassung ein, aber weder auf meine Fassung des Absatzes noch auf direkt an Dich gerichtete Fragen. Ich würde mich jedoch sehr freuen, von Dir zu hören, was Dir an meiner Fassung so schlecht gefallen hat, dass Du sie schlechter findest als die vorherige.--ChristianHujer 00:21, 20. Mär 2006 (CET)

Hier meine Antwort: Du schreibst im Artikel

Die Programmiersprachen Java und C# ... werden compiliert. Beide lassen sich aber sowohl interpretieren als auch kompilieren.

Welche Sprache lässt sich nicht interpretieren... --ChristianHujer 18:29, 26. Mär 2006 (CEST)

C++ wird klassischerweise in Maschinensprache compiliert, während Java und C# in einen Byte Code compiliert werden, 1) Was heißt denn "klassischerweise" und was soll damit über die Programmiersprache C++ ausgesagt werden? 2) C++ muss ganz und gar nicht in Maschinensprache kompiliert werden. 3) Es stimmt nicht, dass C# in einen Byte-Code kompiliert wird. 4) Es ist auch möglich, Java in Maschinencode zu kompilieren.

Klassischerweise bedeutet, dass das die übliche Vorgehensweise ist. Java in Maschinencode zu compilieren, ist genaus unüblich wie C++ zu interpretieren, obwohl beides möglich ist. Wenn Dir "klassischerweise" nicht gefällt, hättest Du es mit Deinem guten Wissen doch leicht durch "üblicherweise" ersetzen können. Was entsteht dann bei der Compilierung von C#? --ChristianHujer 18:29, 26. Mär 2006 (CEST)

C++ unterstützt Mehrfachvererbung von Klassen, während in Java Mehrfachvererbung nur von Interfaces möglich ist - Java-Klassen mit konkreten Membern können nur einfachvererbt werden. 1) Der Leser wird mit dem Begriff Mehrfachvererbung erschlagen. 2) Ich bezweifle, dass das ein signifikanter Sprachunterschied ist; es ist ein Detail. 3) Was sind denn "konkrete Member"?

Ich finde schon, dass es ein wichtiger Unterschied ist. Mich überrascht jedoch, dass Du nicht weißt, was konkrete Member sind. Konkrete Member sind Felder außer Compiletime-Konstanten (public static final), Initialisierer, Konstruktoren, und nicht-abstrakte Methoden. --ChristianHujer 18:29, 26. Mär 2006 (CEST)

Während in C++ die Typparametrisierung durch Templates erreicht wird, die für jeden neuen Typparameter in eine neue, eigene Klasse compiliert werden Das stimmt eben nicht. Auch für Typparameter unterschiedlichen Typs kann der Compiler den entstehenden Code zusammenfassen. Jedenfalls in den Fällen, in denen Java das macht.

Das passiert aber meines Wissens nach zumindest beim g++ nicht. Welcher Compiler macht es denn? --ChristianHujer 18:29, 26. Mär 2006 (CEST)

verwendet Java lediglich eine Typprüfung zur Compilezeit heißt das, C++ verwendet auch eine Typprüfung zur Laufzeit?
Dies führt bei C++ im Vergleich zu Java [...] größerer Typsicherheit. Inwiefern soll das zu größerer Typsicherheit führen?

Na wenn Du meinst, hätts't das ja weglöschen können. --ChristianHujer 18:29, 26. Mär 2006 (CEST)

C++ ermöglicht das Überladen von Operatoren. In Java ist das Überladen von Operatoren nicht möglich. Das ist eine Einzelheit. Der Artikel soll sich aber nicht in Einzelheiten verlieren, sondern einen Überblick vermitteln.

Hättst' auch weglöschen können. --ChristianHujer 18:29, 26. Mär 2006 (CEST)

C++ erlaubt sowohl die Erzeugung von Objekten auf dem Stack als auch auf dem Heap, in Java können Objekte ausschließlich auf dem Heap erzeugt werden. Dabei wäre natürlich zu klären, was denn Objekte sind. In C++ sind beispielsweise auch Integer-Variablen Objekte, und die wiederum sind in Java auch auf dem Stack möglich.

In Java sind Primitive eindeutig keine Objekte. Damit bleibt die Aussage also korrekt. --ChristianHujer 18:29, 26. Mär 2006 (CEST)

C++ besitzt keine Garbage Collection. Auch C++ lässt sich mit Garbage-Collection betreiben.

Das ändert aber nichts daran, dass C++ keine Garbage Collection hat. Selbst in Assembler kann man Garbage-Collection betreiben. Trotzdem ist Garbage-Collection in Java ein von der Sprache und Umgebung zur Verfügung gestelltes Feature, in C++ nicht. --ChristianHujer 18:29, 26. Mär 2006 (CEST)

Das API von C++ beschränkt sich im Wesentlichen auf die Standard Template Library. Was ist denn "das API von C++"? Wenn damit eine Bibliothek gemeint sein soll, dann ist es jedenfalls nicht die Standard Template Library.

Gut, das könnte man genauer formulieren. --ChristianHujer 18:29, 26. Mär 2006 (CEST)

Diese bietet Klassen für Container und Ein-/Ausgabe an. Das, was sich Standard Template Library nennt, bietet nicht unbedingt Klassen für Ein-/Ausgabe an.

Okay, I/O ist nicht Teil der STL. --ChristianHujer 18:29, 26. Mär 2006 (CEST)

... weil bei der Übersetzung der Implementierung durch den Compiler diesem die Schnittstellen aller von der Implementierung verwendeten Klassen einschließlich der Implementierung selbst bekannt sein müssen, um die richtigen Linkersymbole im Objektcode zu erzeugen. Das ist wohl kaum der Grund dafür.

Dann formulier's halt wie's ist. Fehlt nur noch, dass er den für die referenzierten Klassen compilierten Code halt gleich ausspuckt, statt ihn nur im Speicher zu halten. Aber übersetzen muss er sie, wenn er sie nicht findet. Ansonsten gibt's einen Compiler-Fehler. --ChristianHujer 18:29, 26. Mär 2006 (CEST)

ist zu einer benötigten Klassenschnittstelle kein Objektcode vorhanden, wird diese Klasse ebenfalls übersetzt. Was ist denn damit gemeint?

In Java ist der Objektcode das Class-File. Jetzt klar? --ChristianHujer 18:29, 26. Mär 2006 (CEST)

Ich würde sagen, es geht doch ein wenig drunter und drüber in dem Beitrag. Häufig wird die Sprache mit speziellen Implementierungen verwechselt und insgesamt handelt es sich eher um ein Sammelsurium von weniger relevanten Einzelheiten, Halbwahrheiten und schlicht falschen Darstellungen. Insgesamt hat der Beitrag einfach zu viele Qualitätsmängel. --Poldi 19:52, 20. Mär 2006 (CET)

PS: Auf Diskussionspunkte, die nicht die Arbeit am Artikel betreffen, gehe ich ein, wenn der inhaltliche Teil geklärt ist. --Poldi 20:01, 20. Mär 2006 (CET)

Bisher habe ich euch ja schweigend zugeschaut, aber dies bedarf des Senfes meinerseits.

Selbstverständlich werden sowohl C++ als auch Java compiliert. Dass man sie auch interpretieren kann, gilt für jede Programmiersprache, braucht also nicht erwähnt zu werden.

Wenn dir das Wort „klassischerweise“ nicht gefällt, schreib halt „C++ wird normalerweise in Maschinensprache übersetzt.“ Dass es auch andere Möglichkeiten gibt, kann unter „ferner liefen“ erwähnt werden, ist aber m. E. für „Normalsterbliche“ vollkommen uninteressant. Ebenso wird Java normalerweise in Byte-Code übersetzt. Die seltenen und exotischen Ausnahmen können im Java-Artikel erwähnt werden, gehören aber nicht hierhin. (Über C# weiß ich nix.)

Dass C++ Mehrfachvererbung unterstützt und Java nicht, ist ein wesentlicher Unterschied zwischen den beiden Klassen. Der Begriff Mehrfachvererbung sollte in einem eigenen Artikel erklärt werden, aber nicht hier.

So, das soll erstmal genügen. Vielleicht schiebt's euch ein bisschen in Richtung Kompromiss. --jpp ?! 08:58, 21. Mär 2006 (CET)

Ich weiß nicht, warum du hier die Stimmung so anheizen musst. Mit Christian kann man ganz vernünftig reden. Es kommt auch nicht darauf an, hier irgendeine Meinung durchzudrücken, und das auch noch möglichst schnell. Wir brauchen vielmehr einen guten Artikel.

Willst du wirklich "C++ wird normalerweise in Maschinensprache übersetzt" in den Artikel schreiben? Welche Information wird denn dem Leser damit gegeben? Dass eine Programmiersprache kompiliert werden kann, ist doch nichts Ungewöhnliches. Es ist einfach nicht erwähnenswert. Und warum Mehrfachvererbung so einen wesentlichen Unterschied zwischen den Sprachen darstellen soll, dass er hier im Artikel Einzug findet, musst du bitte begründen. Man kann sich auch mit den vielen Einzelheiten verzetteln. Ich möchte nicht, dass dieser Artikel so chaotisch wird, wie der Java-Artikel. --Poldi 19:08, 21. Mär 2006 (CET)

Kann sein, dass ich dass Thema der Diskussion missverstanden habe. Ich dachte, es ginge um die Abgrenzung von C++ und Java. Und da sind zwei der wesentlichsten Unterschiede, dass C++ nicht nach Byte-Code übersetzt wird und dass C++ Mehrfachvererbung erlaubt. Warum siehst du dadurch die Stimmung aufgeheizt? Das war wirklich nicht meine Absicht. --jpp ?! 21:49, 21. Mär 2006 (CET)

Ich habe unter Benutzer:Kingruedi/Temp#Java und C# einen Anfang für die Überarbeitung des Abschnitts gestartet. Schaut euch den mal bitte an (editieren erlaubt) --Kingruedi 20:06, 21. Mär 2006 (CET)

Diesen Textentwurf finde ich sehr gelungen mit einer Ausnahme: Ich bin nicht davon überzeugt, dass die Auswirkungen der flacheren Klassenhierarchien die Laufzeit verringern. Lässt sich das belegen? Es ist schon ein paar Jahre her, seit ich mit C++ intensiv gearbeitet habe, aber damals gab es noch das Problem, dass die große Menge generierten Codes die Ladezeit des Programms stark vergrößert hat. Ist das heute nicht mehr so? --jpp ?! 22:00, 21. Mär 2006 (CET)

Wir haben bereits zwei Versionen, um deren Inhalt hier schon ausführlichst gerungen wurde. Ich werde deine Vorschläge hier in einen Kompromissvorschlag einarbeiten. --Revvar %&§ 14:02, 23. Mär 2006 (CET)

Zusammenfassung der Diskussion zum Abschnitt "Vergleich mit anderen Sprachen"

Letzter Kommentar: vor 18 Jahren6 Kommentare1 Person ist an der Diskussion beteiligt

Dies ist ein Versuch die bisherige Diskussion zusammenzufassen und einen Kompromiss zu erarbeiten. Vorschläge schreibt ihr bitte in die blauen Boxen unter dem Text. --Revvar %&§

Konsenz das es so falsch / unbelegt / nicht NPOV ist
von Poldi kritisiert
von Anderen kritisiert

Einleitung

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

Einführung der Vergleichssprachen

Variante-Alt
Die Programmiersprachen Java und C# sind nicht mit C++ kompatibel. Sie haben zwar eine ähnliche Syntax wie C++, trotz dieser Ähnlichkeit unterscheiden sie sich aber in ihrer Semantik, also in dem, wofür die Syntaxelemente stehen, von C++ teilweise beträchtlich.
Varinate-Neu-1
Die Programmiersprachen Java und C# haben eine ähnliche, ebenfalls an C angelehnte Syntax wie C++, sind auch objektorientiert, werden compiliert und unterstützen Typparameter, weshalb ein Vergleich mit ihnen besonders naheliegend ist.
C++ wird oft mit Java und C# verglichen. Die Syntax von Java und C# beruht ebenfalls auf der Syntax von C. Im Gegensatz zu C++ versuchen beide Programmiersprachen nicht kompatibel zu C zu bleiben. (von Benutzer:Kingruedi)

Vergleich

Variante-Alt

Generische Sprachmittel
Ein wesentlicher Unterschied zwischen diesen Sprachen und C++ besteht darin, dass C++ über generische Sprachmittel (Templates) verfügt. Es gibt mittlerweile in Java und C# generische Typen. Die Spracherweiterung bei Java erreicht jedoch bei weitem nicht die Leistungsfähigkeit von C++-Templates. Bei C# handelt es sich um eine Erweiterung für Generik zur Laufzeit, die die auf Kompilationszeit zugeschnittenen C++-Templates zwar sinnvoll ergänzen, aber nicht ersetzen können.

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

Variante-Neu-1

Byte-Code vs. Maschienencode
C++ wird klassischerweise in Maschinensprache compiliert, während Java und C# in einen Byte Code compiliert werden, der anschließend in einer Virtual Machine interpretiert oder just-in-time compiliert wird. Dadurch waren früher Programme in Sprachen wie Java teilweise erheblich langsamer als C++. Aufgrund moderner Just-in-Time Compiler haben die Sprachen Java und C# jedoch weitgehend zur Ausführungsgeschwindigkeit von C++ aufgeschlossen.
klassischerweise --> in der Regel \|\| hauptsächlich \|\| standardmäßig (von Benutzer:Revvar) Java und besonders C# wurden darauf ausgelegt Just-in-Time kompiliert zu werden. C++ dagegen wurde speziell auf die Kompilierung ausgelegt und benötigt nur für Ausnahmen und Laufzeittypinformationen Anpassungen an die Laufzeitumgebung. (von Benutzer:Kingruedi) ganz weglassen, da Compilerdetail und nicht Teil der Sprache. (von Benutzer:Poldi nachgetragen von Revvar %&§ 16:27, 27. Mär 2006 (CEST)) abgeändert drinlassen. Um einen Eindruck von der Sprache zu haben, sollte man auch wissen welches die typischte Implementation ist, z.B. wenn man auf der Suche nach schnellen Sprachen, oder nach Sprachen bei denen man die "binaries" überall einsetzen kann.Plasmahh 13:32, 15. Mai 2006 (CEST)Beantworten
Mehrfachvererbung
C++ unterstützt Mehrfachvererbung von Klassen, während in Java Mehrfachvererbung nur von Interfaces möglich ist - Java-Klassen mit konkreten Membern können nur einfachvererbt werden.
Java und C# erlauben im Gegensatz zu C++ keine Mehrfachvererbung. Dafür werden Schnittstellen angeboten, um es dennoch zu ermöglichen gemeinsame Signaturen zwischen Klassen zu vererben. (von Benutzer:Kingruedi) Java kann sehrwohl Mehrfachvererbung, nur eben keine mit konkreten Membern. --ChristianHujer 18:47, 26. Mär 2006 (CEST) Java kann so etwas wie Mehrfachvererbung nur von "Interfaces", welches quasi Klassen sind, die bestimmte Bedingungen erfüllen müssen. Doch diese Einschränkung haben sich die Java-Erfinder ja nicht grundlos ausgedacht. Sie vereinfacht den Interpreter/Compiler erheblich. Inwieweit diese Einschränkung für einen Programmierer von Relevanz sind, kommt ganz auf das Projekt an. Oftmals führt der - bei Java eben nötige - Weg über Interfaces zu umständlicheren, schwerer verständlichen Code. So oder so hat Java hier eine Einschränkung, die C++ nicht hat. Ob man das gut findet, oder inwieweit diese Einschränkung relevant ist, mag von Projekt zu Projekt variieren. --RokerHRO 12:17, 29. Mär 2006 (CEST) Dem stimme ich absolut zu. Man findet in der Literatur zu Architektur und Entwurf manchmal den Begriff "Trapez" zur Beschreibung von Problemen der Mehrfachvererbung. Ich habe noch nicht viele gute, also semantisch korrekte und bei zukünftigen Erweiterungen nicht gleich auf Probleme stoßende Beispiele für Mehrfachvererbung gefunden, wohl aber sehr viele schlechte. Mehrfachvererbung führt häufig zu unnatürlicher Kreuzung, die temporär als praktisch erscheint, bei Erweiterungen aber zerbricht. Beispiel: Auto extends Fahrzeug + hat Motor, Fahrrad extends Fahrzeug + hat 2 Räder, Motorrad extends Fahrrad und Auto. Die Probleme, die sich bei zulässigen Erweiterungen von Auto um 4 Räder oder Fahrrad um Dynamo ergeben, sind offensichtlich. Die Philosophie von Java besagt, dass man "gefährliche" Features lieber weglässt. Es gibt halt zwei Arten von Programmierern (Vorsicht Pauschalaussage): Cracks, die mit praktisch jeder Sprache ein Projekt durchführen können, und "Handwerker", die mit bestimmten Werkzeugen zwangsläufig Probleme bekommen. Nicht umsonst werden in C- und noch mehr in C++-Projekten bestimmte Sprachfeatures, z.B. Funktionspointer oder eben Mehrfachvererbung, vom zuständigen Architekten z.B. verboten. Ob man das gut oder schlecht findet, hängt von vielen Faktoren ab, wie z.B. persönlichem Geschmack, Interessen, Zeit, Wechselfreudigkeit und eben auch dem Umfeld, z.B. dem Know How der Kollegen. C++ ist definitiv mächtiger, Java definitiv einfacher. Das eine oder das andere als besser zu bezeichnen, ist ohne den Kontext gar nicht möglich, und den Kontext muss jeder für sich selbst herstellen und beurteilen. Zudem kann der Kontext auch noch variieren, sodass man z.B. privat C++, beruflich Java bevorzugt, oder umgekehrt, oder in beidem Java, oder in beidem C++, oder es vom Projekt abhängt, und dann ist da noch das API, das man verwenden will... --ChristianHujer 01:22, 30. Mär 2006 (CEST) Naja, dein Beispiel zeigt, wie man Vererbung generell - nicht nur Mehrfachvererbung - missbrauchen kann, und oft auch genau so missbraucht wird. Eine Ableitung modelliert immer eine "ist ein"-Beziehung, und keine "naja, hat ein paar gemeinsame Eigenschaften mit"-Beziehung. Bei deinem Beispiel ist ein Motorrad eben nur dann ein "Fahrrad", wenn es _alle_ Eigenschaften von Fahrrad besitzt und _alle_ Eigenschaften von Auto. Das ist aber nicht der Fall. Auto und Motorrad könnten von "Motorfahrzeug" erben, Fahrrad und Motorrad könnten von "Zweirad" erben. Das wäre dann IMHO eine korrekte Vererbungshierarchie. Ein viel zitiertes Musterbeispiel für Vererbung und die Fehler, die dabei oft gemacht werden, ist wohl Kreis und Ellipse. Egal ob man Kreis von Ellipse oder Ellipse von Kreis ableitet, man kommt immer irgendwann in Schwierigkeiten. Die "richtige" Hierarchie wäre, dass man beide Klassen von einer Basisklasse "Form" oder so ableitet. IMHO hat man bei Java Mehrfachvererbung nicht deswegen weggelassen, weil sich damit so viele Programmierer "ins Knie schießen" würden, sondern schlicht weil die Implementierung von Compiler und Laufzeitumgebung mit Mehrfachvererbung bedeutend komplizierter werden würde. Das Argument, "ohne Mehrfachvererbung ist das Programmieren einfacher" stimmt nämlich nicht, denn sobald man echte Mehrfachvererbung braucht, muss man in Java Umwege gehen, die weitaus komplizierter werden. Zudem gibt es in Java (in C++ aber auch g) noch etliche andere Stellen, wo man eindeutig sieht: Man wollte es dem Compilerbauer einfacher machen und nicht dem Programmierer. --RokerHRO 09:35, 30. Mär 2006 (CEST) Die Mehrfachvererbung bringt imho mehr Probleme als Nutzen, z.B. fehlerhaftes Upcasten, Eindeutigkeit von Methodennamen, Testen von Software: Änderungen einer Klasse erfordern immer ein Neutesten entlang der Vererbungshierarchie. Deshalb glaube ich nicht dass es nur aufgrund einer Vereinfachung der Implementierung weggelassen wurde - aber unsere Meinungen sind sowie irrelevant, gibt es dazu keine Aussagen der verantwortlichen Entwickler? --Revvar %&§ 11:50, 30. Mär 2006 (CEST) Abgesehen von der potenziellen Mehrdeutigkeit bei Methodennamen treten alle Probleme, die du genannt hast, nicht nur bei Mehrfachvererbung, sondern generell im Zusammenhang mit Vererbung auf. Ich habe schon einen Link zu diesem Thema angegeben (s.u.). Darin äußert sich Stroustrup u.a. zu dem Thema ([2]). Er bedauert, dass er die Mehrfachvererbung vor den Templates eingeführt hat, was zu einer übermäßigen Verwendung von (Mehrfach-)Vererbung geführt habe. --Poldi 21:32, 6. Apr 2006 (CEST) Achnee, wirklich? Ich dachte das wäre dem kompetenten Leser offensichtlich. Aber gut das du es nochmal klar gestellt hast. --Revvar %&§ 07:10, 7. Apr 2006 (CEST)
Templates - Typsicherheit- Codegröße
Während in C++ die Typparametrisierung durch Templates erreicht wird, die für jeden neuen Typparameter in eine neue, eigene Klasse compiliert werden, verwendet Java lediglich eine Typprüfung zur Compilezeit und erzeugt keine neuen Klassen. Dies führt bei C++ im Vergleich zu Java zu mehr Code, aber auch größerer Typsicherheit.

Überladen von Operatoren
C++ ermöglicht das Überladen von Operatoren. In Java ist das Überladen von Operatoren nicht möglich.
Abschnitt rauslassen (von Benutzer:Revvar) Ich find das schon relevant. Man muss das nicht weiter aufbauschen, aber erwähnen sollte man dies schon, denn viele Entwickler wünschen sich auch bei Java derartige Features, und Gerüchten zufolge will Sun das in nächsten Java-Versionen auch einbauen. --RokerHRO 12:17, 29. Mär 2006 (CEST) Stimme ich voll zu. Operator overloading ist etwas, was es vor allem denjenigen einfacher macht, die nicht wirklich pure Programmierer sind. z.B. hat die GMP Library (multi precision numbers) ein C++ interface, dass das einfache Benutzen von operatoren möglich macht. Dies hilft es z.B. Mathematikern in der Regel sehr Programmer damit zu schreiben. Plasmahh 13:36, 15. Mai 2006 (CEST)Beantworten
Objekte: Heap & Stack, Objektvariablen, Parameterübergabe
C++ erlaubt sowohl die Erzeugung von Objekten auf dem Stack als auch auf dem Heap, in Java können Objekte ausschließlich auf dem Heap erzeugt werden. In C++ können Objekte als Wert oder per Referenz angesprochen werden, in Java ausschließlich per Referenz. C++ unterstützt die Übergabe von Argumenten in Parametern sowohl als Wert als auch per Referenz, Java unterstützt ausschließlich die Übergabe als Wert (bei einem Objekt ist die Objektreferenz der übergebene Wert).
zuerst klare Definition von "Objekt" (von Benutzer:Poldi) Die gehört meiner Meinung nach mit Sicherheit nicht hierher. Dafür gibt es eigene Artikel. --ChristianHujer 18:47, 26. Mär 2006 (CEST) Ein Link zu Objekt sollte reichen. So wie es jetzt formuliert ist, liest es sich irgendwie umständlich, aber wie man es kürzer formulieren kann, ohne dass es falsch wird... hm... nicht so einfach --RokerHRO 12:17, 29. Mär 2006 (CEST) Übrigens sind die Begriffe die im C++ Standard verwendet werden "Freestore" und "Auto Storage" Plasmahh 13:36, 15. Mai 2006 (CEST)Beantworten
Garbage-Collection
C++ besitzt keine Garbage Collection. Auf dem Stack angelegte Objekte werden automatisch beim Verlassen einer Funktion mit Aufräumen des Stacks beseitigt. Auf dem Heap angelegte Objekte müssen explizit gelöscht werden. Wird die letzte Referenz auf ein C++-Objekt gelöscht, bleibt der Speicher trotzdem belegt. Im Gegensatz dazu besitzen Sprachen wie Java und C# eine Garbage Collection, die nicht länger referenzierte Objekte automatisch löschen kann.
C++ besitzt standardmäßig keine Garbage Collection. (von Benutzer:Revvar) Mein Vorschlag: "C++ besitzt keine Garbage Collection. Es existieren aber Bibliotheken, die eine automatische Speicherfreigabe für C++ nachrüsten." Dass diese Bibliotheken meist auch nicht das Gelbe vom Ei sind und mehr oder weniger Disziplin vom Programmierer verlangen, würde natürlich zu weit führen... --RokerHRO 12:17, 29. Mär 2006 (CEST) gcc 4.x kommt übrigens mit einem Boehm Garbage collector der wohl garnicht so schwer zu benutzen ist. C++0x wird wahrscheinlich mit einem in der Sprache integrierten optionalen GC kommen. Plasmahh 13:23, 15. Mai 2006 (CEST)Beantworten
Destruktoren
C++-Objekte können Destruktoren besitzen. Diese Destruktoren dienen als Gegenstück zum Konstruktor dazu, beim Löschen eines Objekts Aufräumarbeiten erledigen zu können. In Java gibt es Finalizer, die vom Garbage Collector aufgerufen werden können (dass sie nicht garantiert aufgerufen werden, ist Gegenstand einiger Diskussionen).
Es sollte evtl. darauf hingewiesen werden, dass Destruktoren nicht nur zur Speicherfreigabe dienen (was ja in Java nicht explitit gemacht werden muss, dank GC), sondern auch sonstige Betriebsmittel, die vom Objekt gehalten wurden, freigegeben werden. Dies ist in Java nicht möglich (außer man gibt die Ressourcen explizit durch Aufruf einer Methode frei), und dies stellt in vielen Bereichen ein ernstes Problem dar. (Bzw. macht das Programmieren in Java halt mühsamer und fehlerträchtiger, da man es "zu fuß" machen muss.) --RokerHRO 12:17, 29. Mär 2006 (CEST) Destruktoren machen soetwas wie RAII überhaupt erst sinnvoll möglich, da sie definierte Punkte der zerstörung von Objekten garantieren. So kann ein Objekt erzeugt werden, dass in seinem Konstruktor einen Mutex locked und im Destruktor unlocked. So braucht man sich keine gedanken machen wann der Scope verlassen wird, der destruktor "macht das schon". Je nach anwendung wird das in java schwierig, da man dies z.B. an den Exception handlern selbst machen muss und dort vergessen kann (wie RokerHRO gesagt hat, "zu Fuss"). Plasmahh 13:39, 15. Mai 2006 (CEST)Beantworten
Libraries
Das API von C++ beschränkt sich im Wesentlichen auf die Standard Template Library. Diese bietet Klassen für Container und Ein-/Ausgabe an. Die APIs von C# und Java sind wesentlich umfangreicher und umfassen auch den Zugriff auf Verzeichnisdienste, die Erstellung grafischer Benutzeroberflächen und Verwendung von XML-Parsern, um nur einige Beispiele zu nennen. Für C++ existieren entsprechende Zusatzbibliotheken, z.B. MFC, Qt oder GTK, die jedoch nicht Bestandteil des API von C++ sind.
Die Standard Template Library ist eine erfindung von HP und SGI von der aus ein gewisser Teil in die C++ Standard Library aufgenommen wurde. hashmaps, ropes und einige andere template klassen der STL wurden nie übernommen, und die bezeichnung der C++ Standard Library mit STL ist schlichtweg falsch. Die Teile die nie in der STL waren bzw. nie so in der STL waren wie sie jetzt in der C++ Standard Library sind, sind die verschiedenen streams, i/o streams, filestreams, stringstreams. Weiterhin ist natürlich auch die C Library in C++ enthalten, auch mit einigen Erweiterungen z.B. von den Signaturen der mathematischen funktionen für andere Datentypen. Es war im übrigen schon immer eine sehr umstrittene Frage, was in die Bibliothek einer Sprache gehört, und was nicht. Während die Ansichten in den 90ern (der standardisierungsphase des heutigen C++) wohl noch anders waren wie heute, wird es in C++0x wohl weit aus mehr geben. Im übrigen finde ich den Begriff API an dieser Stelle unglücklich gewählt, da er sich meistens eher auf eine Library bezieht, und nicht auf eine Sprache. Plasmahh 13:23, 15. Mai 2006 (CEST)Beantworten
Schnittstellen und Implementierung
In C++ ist es üblich und meist erforderlich, die Schnittstelle einer Klasse und ihre Implementierung voneinander zu trennen, weil bei der Übersetzung der Implementierung durch den Compiler diesem die Schnittstellen aller von der Implementierung verwendeten Klassen einschließlich der Implementierung selbst bekannt sein müssen, um die richtigen Linkersymbole im Objektcode zu erzeugen. In Java werden und müssen die Schnittstelle und die Implementierung einer Klasse zusammen vorgehalten werden. Der Java-Compiler sucht sich die Schnittstelle aus den zugehörigen Objektcodes (`.class`-Dateien); ist zu einer benötigten Klassenschnittstelle kein Objektcode vorhanden, wird diese Klasse ebenfalls übersetzt.

--Revvar %&§ 17:30, 23. Mär 2006 (CET)

Kommentare zur Zusammenfassung

Hallo Revvar, danke für deine Mühe, aber um uns auf einzelne Formulierungen festzulegen, ist es zu früh. Wir sollten uns erst einmal über die Gesamtstruktur des Artikels Gedanken manchen, sonst läuft der Artikel gefahr zu verwässern, wie es leider bei so vielen anderen Wikipedia-Artikel auch passiert.

Eine Frage, die sich stellt, ist zum Beispiel, ob man dem Thema Sprachvergleich nicht an dieser Stelle schon viel zu viel Platz einräumt. Wie schon Christian vorgeschlagen hat, könnte man dafür einen eigenen Artikel schaffen. Dafür spräche auch, dass es im Java-Artikel ebenfalls so einen Abschnitt gibt. Eine zusammenfassende Auskopplung der beiden Abschnitte zu einem gemeinsamen Artikel bietet sich also an.

Gruß, --Poldi 20:24, 23. Mär 2006 (CET)

Hallo Poldi, ich glaube wenn wir es nicht einmal schaffen uns über diesen kleinen Abschnitt einig zu werden, wird das mit dem ganzen Artikel erst recht nichts. Eine Auslagerung ist jederzeit möglich und sollte uns nicht von einer Einigung abhalten. Gruß --Revvar %&§ 20:54, 23. Mär 2006 (CET)

Wir können den Abschnitt hier lassen. Aber die Vorgehensweise, Feinstrukturen und sogar Formulierungen vor der Festlegung der Gesamtstruktur zu bearbeiten, halte ich für verfehlt. Ich möchte auch davon abraten, den Artikel mit weniger relevanten Bestandteilen zu verwässern. Da es beim Sprachvergleich ohnehin Überschneidungen mit anderen Themen gibt, besteht diese Gefahr grundsätzlich. --Poldi 14:15, 26. Mär 2006 (CEST)
Bin jetzt erst mal weg. Später mehr. --Poldi 14:18, 26. Mär 2006 (CEST)

Poldi, von Dir kam noch kein einziger konstruktiver Beitrag zum Thema . Du diskutierst nur rum, kritisierst die Texte der anderen und trägst aber sonst nichts bei. Mit welchem Recht greifst Du also so fundamental nicht nur in den Artikel, sondern sogar noch in die Diskussion ein? Wenn Du so viel zu kritisieren hast, dann mach's doch selbst. Dein Verhalten finde ich jedoch äußerst unhöflich. Statt etwas beizutragen, wirfst Du anderen bei ihren Bemühungen, den Artikel zu verbessern, Knüppel zwischen die Beine.

Ich jedenfalls finde, dass Revvar hier gute Arbeit gemacht hat. Allerdings finde ich, dass es absolut nicht der Natur der Wikipedia entspricht, Themen zu Tode zu diskutieren, bevor man einen ziemlich schlechten Textabschnitt ändert. Auf diese Weise geht nämlich garnichts vorwärts. Und das kann ja wohl wirklich nicht das Ziel sein. So weit, dass wir an mehreren Stellen erstmal Entwürfe bearbeiten, hätte es erst garnicht kommen dürfen. Artikel haben nicht umsonst eine Versionsverwaltung. --ChristianHujer 18:40, 26. Mär 2006 (CEST)

Christian, das Entfernen von schlechtem, fragwürdigem oder falschem Textmaterial gehört ebenso zur Artikelarbeit wie das Erstellen von Texten, und niemand hat ein Anrecht darauf, dass seine Beiträge erhalten bleiben, wenn sie in die eben genannte Kategorie fallen. Dass du dich darüber ärgerst, weil es in diesem Fall deinen Beitrag getroffen hat, kann ich verstehen. Dennoch muss es sein. Wir werden aber auch vor anderen Löschungen nicht halt machen, und über einige Punkte sind wir uns ja anscheinend einig.
Die Erstellung des unten stehenden Abschnittes Byte-Code, Zwischencode, Maschinencode hat sich anscheinend mit deinem Diskussionsbeitrag überschnitten, so dass du ihn wohl nicht gesehen hast. Ich habe dort begründet, warum ich etwas nicht im Artikel haben möchte, und hoffe, dass die Begründung nachvollziehbar ist.
Ich möchte dich übrigens bitten, darüber nachzudenken, ob es nicht vielleicht doch sinnvoll ist, sich vor der Ausformulierung von Texten ein paar konzeptionelle Gedanken zum Artikel zu machen. Eigentlich ist ein planerisches Vorgehen nämlich eine Grundlage jeder guten Zusammenarbeit und alles andere als verschwendete Zeit. Und damit muss ich auch den Vorwurf zurückweisen, meine Beiträge hier seien nicht konstruktiv. Es ist jedenfalls bestimmt konstruktiver als sich, so wie du, fast eine Woche lang gar nicht zu beteiligen.
Damit möchte ich jetzt wieder zur Artikelarbeit überleiten. --Poldi 22:27, 26. Mär 2006 (CEST)

Artikelarbeit? Du machst wohl Witze. Was hast Du denn schon groß beigetragen außer löschen und kritisieren. Sorry. Was Du machst, ist in meinen Augen wirklich wenig konstruktiv.

Ich habe nichts dagegen, wenn meine Texte korrigiert oder überflüssiges gelöscht wird. Ich habe auch nichts dagegen, wenn ein von mir verfasster Text gelöscht wird, weil er durch einen eindeutig insgesamt besseren ersetzt wird. Genau das ist aber eben nicht passiert. Stattdessen haben wir jetzt schon mehrere Wochen lang diesen alten Mist, der mehrheitlich kritisiert wurde. Mein Text hat sicher Schwächen. Ich hatte aber den Eindruck, dass die Mehrheit derer, die sich hier in der Diskussion zu Wort gemeldet hat, meinen Text zumindest besser als den alten fand.

Einen perfekten Artikel oder Absatz auf den ersten Wurf ist fast unmöglich. Artikel müssen sich verändern. Ich bin tatsächlich verärgert. Und zwar darüber, dass Du einerseits andere zeitlich unter Druck setzt, andererseits Dir selbst Ewigkeiten Zeit lässt, direkt an Dich gestellte Fragen zu beantworten. Und darüber, dass Du nur rummeckerst, statt am Artikel etwas zu verbessern. Wie wär's denn mal mit Konstruktivität deinerseits.

Dein Vorwurf, dass ich unter der Woche keine Zeit für Arbeit an der Wikipedia habe, hat mich ebenfalls sehr verärgert. Ich finde Deine gesamte Vorgehensweise äußerst destruktiv. Ich werde jetzt den betreffenden Absatz wieder ändern, diesmal etwas konservativer. Meine Bitte an Dich: Wenn Dir dann wieder etwas nicht passt, ändere bitte den Artikel, anstatt wieder die mehrheitlich kritisierte frühere Fassung herzustellen. Das kann doch nicht so schwer sein. Wenn Dir die Tabelle nicht passt, ersetze sie bitte durch neu formulierten Text, nicht die frühere Fassung. Es sei denn, Du kannst plausibel machen, dass sie falscher ist, als der von Dir mehrfach durch Revert wiederhergestellte Text. Dann solltest Du aber selbst hergehen, und zumindest die Fehler aus diesem alten Text korrigieren. Die Arbeit der anderen ständig rückgängig zu machen, ohne selbst etwas zur Verbesserung am Artikel beizutragen, finde ich einfach nur unfair. --ChristianHujer 00:56, 27. Mär 2006 (CEST)

Artikelarbeit? Du machst wohl Witze. Was hast Du denn schon groß beigetragen außer löschen und kritisieren. - Ich begleite den Artikel schon über einen längeren Zeitraum und habe mit Sicherheit schon mehr Substanzielles dazu beigetragen als du. Löschen gehört nun mal zur Artikelarbeit dazu. Ich kann keine sachlich falschen Teile stehen lassen, nur damit sich niemand auf den Schlips getreten fühlt. Es geht aber nicht nur um sachlich falsche Beiträge, denn ebensowenig darf ein Artikel durch das Hinzufügen von Belanglosigkeiten auswuchern. Um unpassendes Material zurückzuweisen, kann ich Änderungen sofort rückgängig machen, aber dann gibt es Geschrei, das dürfe man nicht, usw. usf. Also erläutert man die Änderungen in der Diskussion. Das ist die übliche Vorgehensweise, schon um Edit-Wars zu vermeiden. Dann kommt der Nächste und sagt, er wolle nicht diskutieren, sondern editieren. Was denn nun? Man kann es nicht jedem recht machen.

Ich hatte aber den Eindruck, dass die Mehrheit derer, die sich hier in der Diskussion zu Wort gemeldet hat, meinen Text zumindest besser als den alten fand. - Hier gelten keine Mehrheiten, sondern Argumente. Wir praktizieren hier keine Demokratie. Das offene System der Wikipedia macht dies unmöglich. Sonst könnte ja jemand auf die Idee kommen, seiner Meinung dadurch Nachdruck zu verleihen, dass er schnell eine Gruppe von Sympathisanten zusammentrommelt, die sich zwar sonst nie am Artikel beteiligen, und auch wenig Fachliches dazu beizutragen haben, aber in jedem Fall ihren Senf dazugeben. Entweder, jemand hat etwas zum Thema zu sagen, und kann seine Ansicht schlüssig begründen, oder er verliert seinen Anspruch auf eine Einflussnahme am Artikel.

Blindes Ändern schadet dem Artikel mehr als es ihm nützt. Eine Sache, die mich immer wieder erstaunt, ist die Selbstüberschätzung vieler "Autoren". Ich habe deine Beiträge auf der Diskussionsseite zur C++-Metaprogrammierung übrigens gelesen. Dort bezeichnest du das Thema als "Theoriefindung" und spricht gar von einem Löschgrund. Damit hast du dich als Fachautor zum Thema C++ klar disqualifiziert. --Poldi 22:32, 27. Mär 2006 (CEST)

@ChristianHujer & @Poldi: Was soll das denn jetzt werden, eine kleine persönliche Fehde? Gegenseitige Vorwürfe bringen uns hier nicht weiter, also Vergeben und Vergessen und zurück zu Sachthemen. --Revvar %&§ PS: Zur Klarstellung: Mehrheiten zählen sehr wohl, und zwar die Mehrheit der am Artikel beteiligten Autoren, damit ist ausgeschlossen das mal schnell ein paar Leute zusammengetrommelt werden. Niemand von uns ist ein Informatik-Universalgenie, also werft es auch niemanden vor. Gruß --Revvar %&§ 11:45, 28. Mär 2006 (CEST)

Revvar, ich behalte es mir vor, jemanden auf fachliche Defizite hinzuweisen. Das hat nichts mit persönlichen Differenzen zu tun. Wer sich an einem Thema beteiligen will, muss sich schon auskennen, anders ist ein sinnvolles Arbeiten leider nicht möglich.
Bezüglich der Mehrheiten muss ich dir widersprechen und empfehle die Lektüre dieser Seite. Was zählt, sind Argumente, und über richtig und falsch kann man nun mal nicht abstimmen. --Poldi 23:15, 28. Mär 2006 (CEST)

Poldi, dann weise ich dich mal auf deine Defizite hin: Fehlender konstruktiver Beitrag. Ich warte übrigens noch auf deine Argumente in dem obigen Zusammenfassung. Wenn du meinst das du mit der Eröffnung von zig neuen Diskussionfeldern, nachdem du Anfangs selbst nichts Diskussionswürdiges fandest, eine Einigung der Mehrheit verhindern kannst, dann irrst du. --Revvar %&§ 11:20, 29. Mär 2006 (CEST)

Revvar, wenn ich der Meinung bin, dass ein Punkt ganz weggelassen werden soll, werde ich logischerweise keine Alternative vorschlagen. Und auch auf die Gefahr, dass ich mich wiederhole: Auch konzeptionelle und planerische Arbeit ist wichtig, und ich betrachte das als konstruktive Arbeit. Konzeptionslosigkeit ist ein häufig anzutreffender Mangel von Wikipedia-Artikeln. Nur zu oft bestehen sie aus einer Sammlung spontan eingestreuter, zusammengewürfelter Einzelmeinungen fragwürdiger Relevanz oder Richtigkeit. Im Übrigen, und auch das habe ich schon angedeutet, zähle ich mich in diesem Themenkreis eher zu den Aktiveren, und ich habe vermutlich auch schon mehr Buchstaben dazu beigesteuert als du. Soll kein Vorwurf sein, sondern eine Feststellung. Aber da wir schon einmal dabei sind, uns gegenseitig auf Defizite hinzuweisen: Du steuerst auffallend wenig Fachliches zu dieser Diskussion bei. Es wäre schön, wenn du auch da mal etwas mehr Hintergrundwissen durchblicken ließest. Und den Vorwurf, ich wolle hier eine Einigung verhindern, finde ich ein starkes Stück. Halte dich mit sowas zurück. Ich sähe es, im Gegenteil, gerne, wenn wir hier zu einem Konsens fänden. Ich habe mit meiner Meinungsäußerung zum Thema "Maschinencode/Zwischencode" schon einen Anfang gemacht. Weitere Punkte folgen. --Poldi 20:38, 29. Mär 2006 (CEST)

Ach Poldi, das ist ja jetzt wirklich langsam unterste Schublade. Soll ich dir jetzt Lebenslauf, Zeugnisse und Bewertung meines Arbeitgebers zusenden? Meine Kritik an dir bezieht sich nur auf diese Diskussion hier, bei der ich außer Kritik noch keinen Gegenvorschlag von dir gehört habe. Eine konstruktive Kritik beinhaltet immer Verbesserungsvorschläge. Das Ergebnis nach wochenlanger Diskussion ist bisher die Rausnahme der POV-Abschnitte, also das was ich mal ganz am Anfang gefordert hatte und was du nicht erkennen konntest oder wolltest. Das wars von mir erst mal zum Thema persönliche Anpöbeleien. --Revvar %&§ 12:27, 30. Mär 2006 (CEST)

Du musst nicht jede Kritik an deinem Verhalten als Anpöbelei abtun. Meine Einwände sind sachlich vorgetragen, und Sachlichkeit erwarte ich auch von dir.
Die betreffenden Abschnitte habe ich deshalb nicht wieder eingefügt, weil sie im Moment hier zur Diskussion stehen, und nicht etwa um sie zu löschen. Dass du sie als POV bezeichnest (was immer du damit meinst) ist deine persönliche, subjektive Ansicht, die du nach wie vor nicht näher begründest. --Poldi 19:07, 2. Apr 2006 (CEST)

Und du solltest stärker über deine "Kritiken" nachdenken bevor du sie postest - du bist unsachlich und greifst andere Autoren persönlich an - indem du ihnen öffentlich die Kompetenz zum Thema absprichst. Damit hast du hier die Athmosphäre vergiftet, Autoren vergrault und verhinderst damit eine Fortführung der Arbeit am Artikel. Da du auch scheinbar immer noch nicht begriffen hast was POV==not NPOV==PPOV bedeutet: Wikipedia:NPOV gibt dir Auskunft darüber. Die Ansicht, das es in wesentlichen Abschnitten POV war, wurde dir schon von mehreren Diskutanten sachlich erläutert (siehe auch die Zusammenfassung oben). --Revvar %&§ 07:31, 7. Apr 2006 (CEST)

Im Gegenteil, ich bin in meinen Beiträgen sehr sachlich. Zu einer sinnvollen Artikelarbeit gehört es aber auch, Autoren ggf. auf fachliche Defizite hinzuweisen. Das muss man ja nicht gleich als Ehrabschneidung auffassen, und mit Streit hat das gar nichts zu tun, im Gegenteil, ich schätze die Mitarbeit von Christian Hujer in der Wikipedia. Hier ist nun mal alles öffentlich, und persönliche Einschätzungen, auch öffentlich vorgetragen, sind an der Tagesordnung. Denk nur mal an die Adminwahlen. Dort kann jeder Kritik äußern, und in der Regel nimmt dies der Kritisierte nicht persönlich.
Zum neutralen Standpunkt: Ich habe schon einmal erklärt, dass auch ein Vorwurf fehlender Neutralität begründet werden muss. Ein reiner Verweis auf den Wikipedia-Artikel Wikipedia:Neutraler Standpunkt reicht nicht.
Solche Beiträge wie dieser von dir, finde ich übrigens befremdlich und überhaupt nicht sachlich. So geht es nicht. Ich denke, ich werde mich für ein paar Tage von hier zurückziehen. --Poldi 20:30, 9. Apr 2006 (CEST)

Zum Thema: Byte-Code, Zwischencode, Maschinencode:

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

Annotations

Annotations werden doch zum Teil mittels #pragmas in C++ nachgebildet. Das sollte man vll anmerken --Kingruedi 14:50, 27. Mär 2006 (CEST)

Auch wenn was dran ist - nicht alles in den Artikel reinpacken, nur "weil es stimmt". --Poldi 22:37, 27. Mär 2006 (CEST)

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

Zum Punkt "Verwendung objektorientierter Techniken in C++", sowie deren Ersatz durch Generik

Hier eine Äußerung von B. Stroustrup zu diesem Thema. Darin äußert er sich zur übermäßigen Verwendung von Vererbung bedingt durch das Fehlen von Templates (das war also bevor Templates eingeführt wurden): [3] (darin übrigens auch eine Anmerkung zum Thema Mehrfachvererbung) --Poldi 19:19, 2. Apr 2006 (CEST)

Hinweis auf notwendiges return aus main in C

Hauptsächlich an Poldi: Ich bin eigentlich ziemlich sicher, dass ein return-Statement aus main in C erwartet wird. Zumindest in C90. Wenn mir irgendwer das Gegenteil belegen kann... ich lerne ja gerne dazu... --Florian Keßeler 18:16, 26. Mär 2006 (CEST)

Ich bin eigentlich ziemlich sicher, Das reicht nicht. Du musst dir ganz sicher sein.

Wenn mir irgendwer das Gegenteil belegen Nein, es funktioniert umgekehrt: Du musst die Richtigkeit deiner Beiträge belegen. -Gruß, --Poldi 18:25, 26. Mär 2006 (CEST)

"reaching the } that terminates the main function returns a value of 0.". Bei C99 braucht in main() also kein return stehen - wie gesagt C99, nicht C89.

"If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument;" Bei C99 sind also auch andere, mit int kompatible Rückgabetypen erlaubt.

"If the return type is not compatible with int, the termination status returned to the host environment is unspecified."

Quelle: [4] (ISO/IEC 9899:1999 S. 13 5.1.2.2.3 Program termination)

@Poldi: Wo steht, dass derjenige, der etwas ändert, die Richtigkeit beweisen muss? Warum nicht derjenige, der den Revert durchführt? Ich finde, man kann doch nicht einfach einen Revert durchführen und behaupten, etwas sei falsch, ohne es beweisen zu wollen oder zu können. Machst Du es Dir nicht ein bisschen einfach? --ChristianHujer 19:09, 26. Mär 2006 (CEST)

Er kann ja ruhig meine Änderungen zurücksetzen, ich lerne ja gerne was dazu, aber es wäre trotzdem nett, mir seine Quellen zu verraten, sonst hilft das keinem weiter. Zumindest der Artikel Varianten der Programmiersprache C#Beispiele für den Unterschied zwischen verschiedenen Fassungen der Sprache C sagt, dass erst bei C99 das return in main ausfallen darf. --Florian Keßeler 11:58, 27. Mär 2006 (CEST)

Nachtrag: Selbst im Hello-World-Beispiel steht als HTML-Kommentar, dass das return in C89 fehlen würde... Wenn muss es wenigstens eine gewisse Konsistenz geben. Also entweder da auch den Hinweis löschen oder meinen einen Satz wieder aufnehmen. Aber beide Meinungen gleichzeitig funktionieren nicht. Ich finde leider nrigends den älteren Standard. Das es in C99 erlaubt ist, sehe ich inzwischen ein 8auch wenn man C99 kaum als Grundlage für C++ betrachten kann). --Florian Keßeler 20:02, 27. Mär 2006 (CEST)

Florian, die Hinweise wurden eingefügt, weil leider immer wieder Änderungen am Programmbeispiel vorgenommen wurden, meist zum Schlechteren. Du kannst dich im Archiv zu dieser Diskussionsseite davon überzeugen, dass es mittlerweile zum Reizthema geworden ist. Dabei stecken hinter den Änderungen oft gar nicht einmal negative Absichten. Schon allein aufgrund der Menge der Änderungen kann aber nicht individuell auf der Diskussionsseite darauf eingegangen werden, und schließlich ist die Diskussion in erster Linie für die Artikelverbesserung da, weniger zur Beantwortung von Leserfragen.
Der HTML-Kommentar auf der Seite hat einzig den Sinn, die Änderungen einzudämmen, übrigens ebenso die m.E. schon etwas über das vertretbare Maß hinausgehende Erläuterung des Programms, deren Wirksamkeit sich offensichtlich in Grenzen hält. Überbewerte das Programmierbeispiel bitte nicht. Es ist kein übermäßig wichtiger Bestandteil des Artikels, sondern dient vorrangig der Illustration, aber vielleicht wäre ein Link auf den von dir angeführten Artikel sinnvoll.
Den "älteren Standard" findest du vor allem deshalb nicht, weil es keinen älteren gibt. Es gibt immer nur genau einen C-Standard, denn jede neu erscheinende Version ersetzt die jeweils vorige. Historisch gesehen basiert C++ aber auf dem Stand von 1990, da hast du Recht. --Poldi 21:38, 27. Mär 2006 (CEST)

So, jetzt hab ich doch noch mal genauer nachgeforscht und bin dabei auf folgendes gestoßen: link. Daraus Section 2.1.2.2: "A return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument. If the main function executes a return that specifies no value, the termination status returned to the host environment is undefined." und Section 3.6.6.4: "If a return statement without an expression is executed, and the value of the function call is used by the caller, the behavior is undefined. Reaching the } that terminates a function is equivalent to executing a return statement without an expression.". --Florian Keßeler 10:43, 28. Mär 2006 (CEST)

Über dem Text an dem von dir angegebenen Link steht doch deutlich "C89". --Poldi 23:18, 28. Mär 2006 (CEST)

Es ist hier Konsens, dass der Einsteller auf Nachfrage Quellen (also Belege) liefern muss, da andersrum Vandalismusbekämpfung praktisch unmöglich wird. Gruß --Revvar %&§ 16:39, 27. Mär 2006 (CEST)

Diskussion bis Einigung

Wie Ihr sicher schon bemerkt habt, habe ich statt eines Textes mal eine Tabelle eingefügt. Bei einer Tabelle gibt es weniger Möglichkeiten, sich über Formulierungen zu streiten. Andererseits bietet sie nicht die schönen sprachlichen Möglichkeiten der Formulierung von Zusammenhängen. Von mir aus kann die Tabelle auch wieder rausfliegen, aber bitte bitte nicht mehr den alten Text, dann schon lieber garkeinen. --ChristianHujer 01:26, 28. Mär 2006 (CEST)

Ich habe die Tabelle wieder herausgenommen. Ebenso andere Punkte, die momentan noch diskutiert werden. Bitte erst das Diskussionsergebnis abwarten. Das ist so üblich. --Poldi 23:44, 28. Mär 2006 (CEST)

Titel des zu bearbeitenden Abschnitts

Einen guten und angemessenen Vergleich der Programmiersprachen halte ich für ein schwieriges und komplexes Thema, das im Rahmen des Artikels C++ entweder inhaltlich zu kurz kommt, oder das eigentliche Thema, nämlich C++, weit überschreitet. Ich möchte deshalb den Abschnitt umbenennen in "Bezug zu anderen Sprachen" und dadurch einen etwas anderen Schwerpunkt setzen, bei dem der Überblickscharakter, den ein Enzyklopädie-Artikel ja haben soll, wieder stärker in den Vordergrund gerückt wird. --Poldi 00:05, 29. Mär 2006 (CEST)

Guter Plan. Ich finde es sowieso merkwürdig, mit welch "religiösem Eifer" hier einige für oder gegen C++ wettern. Der Artikel soll über C++ möglichst neutral informieren und nicht versuchen, den Leser auf die Seite des Schreibers (der C++ entweder liebt oder hasst) zu ziehen. :-/ --RokerHRO 07:44, 29. Mär 2006 (CEST)

@RokerHRO: Könntest du bitte deine Behauptung des religiösen Eifers der Beteiligten hier belegen? Danke. --Revvar %&§ 11:29, 29. Mär 2006 (CEST)

Wenn ich mir die Versionsgeschichte des Artikels so anschaue, so sind da einige Änderungen incl. Reverts und Revert-Reverts drin, insbesondere bei dem Abschnitt über den Vergleich mit anderen Programmiersprachen, aber auch an anderen Stellen. :-/ --RokerHRO 11:40, 29. Mär 2006 (CEST)

@poldi: Könntest du bitte den Unterschied zwischen den aktuellen und den von dir gewünschten Schwerpunkt genauer ausführen. Ich erkenne im Moment nicht worauf du hinaus willst. --Revvar %&§ 11:29, 29. Mär 2006 (CEST)

Ich würde bei "Bezug zu anderen Sprachen" schwerpunktmäßig auf die historische Entwicklung eingehen, also auf die Entstehung der Sprachen, und wo an welcher Stelle abgeschaut wurde, was ja auch zum Teil schon im bisherigen Text erwähnt wurde (C -> C++; Simula -> C++; Smalltalk -> Java). Die Gefahr, dass wir uns dann mit dem Thema verheben, sehe ich als geringer an. Das soll einen Vergleich der Sprachen nicht völlig ersetzen, aber eben weniger im Sinne eines Leistungsvergleichs. --Poldi 20:49, 29. Mär 2006 (CEST)

Sprachenvergleich: Tabelle statt Fließtext

Ich finde, die relevanten Features von C++ und "anderen Sprachen" könnten in einer Tabelle gut und übersichtlich, und vor allem viel neutraler als in Fließtext dargestellt werden. Was haltet ihr davon? --RokerHRO 12:20, 29. Mär 2006 (CEST)

Finde ich gut, gerade für technische Kleinigkeiten. Man kann den Text dann auf die wichtigsten Unterschiede beschränken. Was hältst du von Christians Tabelle (siehe History ;-))--Revvar %&§ 13:50, 29. Mär 2006 (CEST)

Ich schieb sie hier mal rein:

Feature	C++	C	Java	C#
explizite Zeigerdatentypen	ja	ja	nein	?
Argumentübergabe	Wert oder Referenz¹		Wert	?
Objekterzeugung	Stack oder Heap Wertobjekte möglich	Stack oder Heap	nur Heap (Primitive auch Stack) Referenz auf dem Stack	?
Objektzerstörung	Wertobjekt (Stack oder eingebettet): automatisch, ansonsten manuell²		Automatische Garbage Collection	?
Typparametrisierung	Templates (Metaprogrammierung)	keine	Generics (keine Metaprogrammierung)	Templates und Generics
Metaprogrammierung	ja (Templates)	nein	nein	?
Polymorphie	explizit (`virtual`)	keine	implizit	?
Mehrfachvererbung	ja	nein	nein (nur von Interfaces)	?
Überladen von Methoden	ja	nein	ja	ja
Überladen von Operatoren	ja	nein	nein	?
Metadaten	nein	nein	ja (Annotations)	?
Dokumentationssystem	nein³		ja (javadoc)
Präprozessor	ja	ja	nein
Linken	Compilezeit⁴		Laufzeit	?

Anmerkungen:

¹: Referenzvariablen werden bei C als Zeiger übergeben, bei C++ existieren zusätzlich separate Referenz-Typen
²: GC kann über Bibliotheken nachgerüstet werden
³: Es existiert zahlreiche Zusatzsoftware, die dieses Feature nachrüstet
⁴: Es existieren betriebssystemspezifische Funktionen zum dynamischen Linken zur Laufzeit

An der Auswahl der aufgezählten Eigenschaften und Sprachen, sowie an den Formulierungen der Fußnoten kann man ja gerne noch arbeiten, es ist nur als Entwurf zu verstehen. :-) --RokerHRO 14:37, 29. Mär 2006 (CEST)

Vorschlag:
Eventuell könnte man die Tabelle auch noch weiter ausbauen. Dann sollte sie aber in einen separaten Artikel verlegt werden und von C++ (und den anderen in der Tabelle aufgeführten Sprachen aus) wird diese dann verlinkt. Dann würden auch die Schreiber der anderen Sprach-Artikel an der Tabelle mitwirken und sie wird dann vielleicht etwas ausgewogener werden. --RokerHRO 14:41, 29. Mär 2006 (CEST)

Ich muss sagen, die Idee finde ich sympathisch. Aufzählungen und ellenlange Listen innerhalb von Artikeln werden nicht gerne gesehen, und sie sagen meiner Meinung nach auch nicht viel aus. Der Leser wird mit dem Material allein gelassen. Nicht vergessen: Der Artikel ist auch für Laien gedacht. Also: Fakten, Fakten, Fakten. Und immer an den Leser denken. --Poldi 20:55, 29. Mär 2006 (CEST)

Finde ich auch gut. Zum Punkt "was noch" würde ich Objective-C übernehmen, weil es auch direkt von C erbt und ähnlich wie Java Smalltalk-Konzepte übernimmt, aber direkter umsetzt. Außerdem würde ich bei C unter den Punkten "Polymorphie" und "Mehrfachvererbung" eher ein "nicht anwendbar" oder ähnliches setzen, weil C nicht objektorientiert ist und diese Punkte nur bei OOP eine bedeutung haben. --Florian Keßeler 23:04, 29. Mär 2006 (CEST)

Wie konservativ einige bezüglich Änderungen am Artikel gerne vorgehen, halte ich für äußerst fragwürdig und habe ich in den vielen Jahren, die ich mittlerweile an der Wikipedia arbeite, noch nicht erlebt. Ob das zu Tode diskutieren wirklich hilfreich ist, bezweifle ich stark. (Ja, das ist wieder einmal an Dich gerichtet, Poldi). Es ist verwunderlich, dass es trotz dessen so ruhig bleibt. Zumindest ist der viel-besagte Abschnitt jetzt endlich inhaltlich korrekt, nachdem Poldi endlich mal von einem Total-Revert abgesehen hat.

Ich möchte dabei auch darauf hinweisen, dass eine Vielzahl von Lesern sehrwohl Bestandteile in Artikeln ändert, die sie für Verbesserungswürdig halten, aber kaum die Diskussion verfolgt. Das Potential dieser Leser wird durch die Vorgehensweise, die Diskussion zur Artikelerstellung zu ge-, ich möchte schon fast sagen misbrauchen, völlig vergeudet. Ich glaube nicht, dass es weh getan hätte, die Tabelle erstmal im Artikel zu belassen, dort reifen zu lassen und dann in einen eigenen Artikel zu verschieben. Das sollte auch so früh wie möglich geschehen.

Ständig hatte ich das ungute Gefühl, dass die Vorgehensweise von Poldi falsch ist. Ich habe mich heute mal gefragt, warum. Neben meinem Argument über das vergeudete Potential von Leseränderungen fällt mir zusätzlich noch ein Vergleich mit Die Kathedrale und der Basar ein. Die Wikipedia ist eine Basar-Natur, und Poldi versucht gerade, ihr eine Kathedrale-Natur aufzuzwingen. Aber das ist natürlich nur meine subjektive Ansicht und Meinung.

Von einer Macher-Mentalität bewegen wir uns hin zu einer Politikermentalität, in der Änderungen erst zu Tode diskutiert werden. Ich kann bislang nicht erkennen, wie dies in irgendeiner Weise zur Qualitätssteigerung beitragen soll. Vor allem, wenn man vergleicht, wieviel Zeit wir in die Diskussion stecken, ist das eine unheimliche Resourcenverschwendung. Eigentlich habe ich besseres zu tun.

Nun aber zum wichtigen, der Tabelle. Ich habe dazu folgende Anmerkungen:

Objekterzeugung: Dies klingt so, als wären in Java Referenzen immer auf dem Stack. Änderungsvorschlag: "nur Heap (Primitive und Referenzen auch Stack)".
Objektzerstörung: Hier sollte man anmerken, dass das Nicht-Aufrufen von Finalizern bei Java Gegenstand einiger Diskussion ist.
Bei Java könnte man anmerken, dass es einen De-facto-Standard-Präprozessor gibt, nämlich Apache Velocity.
Bei C# weiß ich, dass es ein Dokumentationssystem gibt, und glaube, dass es "xmldoc" heißt.

Und weil ich eigentlich besseres zu tun habe, als mich mit Poldi's Kathedrale-Verhalten (und warum hält er sich für den C++-Artikel-Papst? Was befähigt ihn dazu, seine Meinung über die aller anderen zu stellen?) herumzuschlagen, ist dies der letzte Kommentar, den ich in Sachen C++ abgebe. Da widme ich mich doch lieber anderen Artikeln, wo nicht lange gefackelt wird. Wo einzelne Fehler, die durch neue längere Absätze eingebracht werden, korrigiert werden, statt die ganzen Texte wieder zu löschen. Wo Leute, wenn ihnen etwas am Artikel nicht passt, selbst richtig anpacken, statt mit Reverts und ewigen Diskussionen dringend notwendige Verbesserungen hinauszuzögern. An einem Vergleich objektorientierter Programmiersprachen arbeite ich solange mit, solange Poldi nicht durch ständige Reverts den notwendigen Fortschritt blockiert - was nicht heißt, dass Du nicht mitarbeiten sollst, im Gegenteil, Dein Fachwissen zu objektorientierten Programmiersprachen schätze ich sehr und konstruktive Mitarbeit am Vergleich objektorientierter Programmiersprachen-Artikel wäre mir auch von Dir sehr willkommen. Reverts dort aber bitte nur, wenn eine Änderung den Zustand hundertprozentig eindeutig verschlechtert. Wir sind hier nicht in der Politik, und ich habe nicht ewig Zeit. --ChristianHujer 23:55, 30. Mär 2006 (CEST)

Ja, es geht hier manchmal zu wie im Basar, da muss ich dir allerdings zustimmen. :-) Wenn nun die Wikipedia-Artikel in ihrer Qualität insgesamt sehr überzeugend wären, dann würde es die bisherige Vorgehensweise rechtfertigen. Wikipedia-Artikel stehen aber i. Allg. nicht in einem besonders guten Ruf, was deren Quälität und Verlässlichkeit angeht. Also muss man etwas ändern.
Sicher sind wir auch durch die bestehenden technischen Möglichkeiten eingeschränkt; so gibt es beispielsweise keinen Entwurfsmodus. Aber dass deshalb die Artikelseite für den Entwurf herhalten soll, also das, was dem Leser präsentiert wird, halte ich für den falschen Weg. Vielleicht bekommen wir ja bald einige der erhofften technischen Erweiterungen und das Problem und viele Diskussionen, die sich darum ranken, erübrigen sich von selbst. --Poldi 19:36, 2. Apr 2006 (CEST)

Das deutschsprachige Wikibook

Es gab in letzter Zeit Unstimmigkeiten, ob das deutsche Wikibook

Wikibooks: C++ Programmierung bei Wikibooks (deutsch) – Lern- und Lehrmaterialien

gut genug ist, um hier erwähnt zu werden. Außer einer Reihe von kurzen Kommentaren habe ich noch hier nicht gelesen, ab welchen Entwicklungsstand ein Link akzeptabel wäre.

Meine Ansicht: Da ich in Wikibooks ein Schwesterprojekt sehe, das es zu unterstützen gilt (Vermittlung potentieller Mitautoren ;-), meine ich das das zwar noch unvollständige und ausbaufähige (ist halt auch nur ein Wiki) Buch einen Link verdient hätte. Für Anfänger und Umsteiger ist es bereits gut geeignet, größere Fehler sind mir beim "durchblättern" noch nicht aufgefallen. --Revvar %&§ 09:20, 29. Apr 2006 (CEST)

Verlinken sollten wir es schon, dann hat es auch bessere Chancen, von einem Sachkundigen entdeckt und verbessert zu werden. Wir können ja zusätzlich noch das englische Wikibook zu C++ verlinken:

Wikibooks: C++ Programming – Lern- und Lehrmaterialien

Das ist schon weiter ausgebaut und für echte PC-Kenner wahrscheinlich auch gut verständlich. Am Computer ist man doch sowieso ständig mit Englisch konfrontiert.

Fazit: deutsches und englisches Wikibook verlinken --Thomaswm 11:32, 30. Apr 2006 (CEST)

Die Empfehlung in Wikipedia:Weblinks drückt sich da eigentlich sehr klar aus: Die goldene Regel der Wikipedia zum Thema Weblinks ist: Bitte vom Feinsten. Nimm nicht irgendwelche Links zum Thema, sondern wähle das Beste und Ausführlichste aus, was im Netz zu finden ist. Davon ist das Wikibooks-Projekt weit entfernt. Ich finde auch, ein reines "Durchblättern" einer Informationsquelle im Internet reicht nicht, um einen Weblink in die Linkliste mitaufzunehmen. Etwas mehr Sorgfalt sind wir unseren Lesern schon schuldig. --Kadeck 21:57, 30. Apr 2006 (CEST)

Verschlimmbesserungen

Letzter Kommentar: vor 18 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt

Ich folgendes revertiert:

* C++ enthält C, erweitert um objektoriertierte Programmierung, generische Programmierung, Exceptions und die STL

steht bereits besser in der Einleitung

* Die aktuellen Compiler produzieren nicht immer optimalen Code, sowohl in Bezug auf Übersetzungsgeschwindigkeit,
Laufzeitgeschwindigkeit als auch auf Code-Größe.

Der vorherige Text ist besser, Übersetzungsgeschwindigkeit, passt auch nicht in den Satz:

* Die aktuellen Compiler produzieren nicht immer optimalen Code, sowohl in Bezug auf Geschwindigkeit als auch auf Code-Größe.

* Templatelibraries werden bei jeder Übersetzungseinheit jeweils für jede Templateinstanz meist neu kompiliert,
was zu langen Übersetzungszeiten und großen Maschinencodedateien. Diese Spracheigenheit hat zur spöttischen 
Bezeichnung von C++ als objektorientiertem Makroassembler geführt.

Das hatte ich schon vorher in einer ähnlichen Version rückgängig gemacht, die Diskussion lief auf meiner Benutzerseite, hier die Kopie:

Ich habe eine relativ kleine Ergänzung zu C++ gemacht, die Du praktisch sofort wieder rückgängig gemacht hast. Ich gebe seit 1990 C++-Kurse an der Uni Regensburg. Ich halte meine Bemerkung für relevant; ich kann sie an Hand mehrerer Compiler belegen. C++ mit den Template Libs hat lange Übersetzungszeiten und erzeugt riesige .exe-Files. Übersetze nur einmal ein Hallo-Programm mit C++ und dann mit C! Es ist frustrierend, wenn man überlegte Ergänzungen zu Artikeln macht, die sofort wieder verschwinden. Dasselbe ist mit mit einer größerer Änderung dei Gleitpunktzahlen passiert. Ihr vergrault mit dieser Methode Leute, die sich bei Euch engagiert beteiligen! brf Hallo brf, ich gebe keine C++-Kurse. Aber wenn du soetwas ohne Quellen in den Artikel schreibst, musst du damit rechnen das Andere das nicht nachvollziehen können. Was du beschreibst ist imho ein Problem des Make-Prozeses, und nicht der Sprache. Außerdem finde ich es viel zu unspezifisch: Warum sind sie "schwer zu kompilieren" und was verstehst du darunter? In welchen Fällen tritt das Problem des "Template Induced Code Bloat" denn auf? - vieleicht wenn man Templates zu unüberlegt einsetzt? Das ein "Hallo Welt" Programm bei dir riesige Dateien erzeugt kann ich auch nicht nachvollziehen - C++ : 6 KiB , C : 4,5 KiB. Gruß --Revvar %&§ 12:49, 3. Mai 2006 (CEST)Beantworten Hallo Revvar, C++ ist ein Enzyklpädischer Artikel, der ja sowieso schon sehr lang ist. Die im Artikel aufgezählten Stärken und Schwächen sind _alle_ ohne Quellen aufgeführt; als kurze Stichpunkte eben. Hier einen Absatz als wissenschaftlichen Aufsatz einzuflechten mit vollständigen Quellenangaben, halte ich für stark übertrieben. Allgemein gilt für Programmiersprachen, dass sie Liebhaber und Gegner haben, jeweils zwei Lager die sich oft befehden. Natürlich schreiben die Befürworter jeweils die Lehrbücher. Die Nachteile werden darin oft gar nicht aufgezählt oder bestenfalls gestreift. Deshalb sind gerade für die Schwächen Quellenangaben meist unmöglich. Ein Anfänger probiert dann die Sachen aus und wundert sich warum das so zäh geht. Anwort auf diese Frage findet er meist nicht, bevor er nicht die Sprache gut beherrscht und verstanden hat was eigentlich genau passiert. Beispiel: Auf meinem HP Vectra übersetzt ein C-Hallo-Programm in 4:50 s, das äquivalente C++-Hallo-Programm braucht 12:29 s. Beides mit gcc 4.0.1; DJGPP. D:\C_KURS\HALLO>type HALLO.C #include <stdio.h> int main (void) { printf ("Hallo\n"); printf ("Hallo" " altes Haus " "\n" ); printf ("\101\\\??\"\101\\\10" "1\n"); return 0; } D:\C_KURS\HALLO>type HALLO.CPP // Datei /c_kurs/hallo/hallo.cpp #include <iostream> using namespace std; int main () { cout << "C++: Hallo\n"; return 0; } D:\C_KURS\HALLO>gcc -x c HALLO.C D:\C_KURS\HALLO>gxx -x c++ HALLO.CPP D:\C_KURS\HALLO>gcc -v Using built-in specs. Target: djgpp Configured with: /gnu/gcc-4.01/configure djgpp --prefix=/dev/env/DJDIR --disable -nls --disable-werror --disable-checking --enable-languages=c,ada,c++,f95,objc Thread model: single gcc version 4.0.1 D:\C_KURS\HALLO> Zum Problem selbst: Templates bedeuten, dass die Inlude-files nicht wie in C nur Deklarationen enthalten und der eigentliche Code einer Library übersetzt vorliegt, sondern dass der gesamte Code im Include-File steht. Er wird vom Compiler beim Lesen _jedes_ Includefiles lexikalisch und syntaktisch analysiert und beiseite gelegt. Erst wenn Template-Instanzen im Usercode notwendig werden, wird der C++-Code erzeugt und übersetzt. Das bedeutet beim Übersetzen einen ungeheueren Geschwindigkeitsnachteil. Man kann sich überlegen, ob man die Information anders formuliert und besser "rüberbringt". brf Hallo brf, die Quellen für solche Kleinigkeiten gibst du im Feld Zusammenfassung an, oder, wenn dir das zu klein ist, schreibst du sie in Diskussion. Da wir hier im Gegensatz zu Büchern kein Platzproblem haben, kann der Artikel auch lang und gut sein. Wenn du begründete Zweifel an Abschnitten des Artikels hast, kannst du sie zur Diskussion stellen, und ggf. rausnehmen. Inhaltlich: Du beschreibst einen Unterschied zwischen Templates und Libraries, bleibst aber die Erklärung schuldig, warum du das als Schwäche der Sprache betrachtest. Hier wird sich ein Geschwindigkeitsvorteil bei der Programmausführung auf Kosten der Compilezeit und ggf. der Programmgröße erkauft - du gehst aber nur auf die Compilezeit und vermeintliche Größe ein. Auf die "riesigen Dateien" bist du auch nicht mehr eingegangen. Ich denke man kann jedes Element der Sprache auch falsch einsetzen, das würde ich aber der Sprache nicht als Nachteil zuschreiben. Wenn du mich übrigens für einen C++-Fan hälts liegst du falsch - für mich ist sie eine Sprache wie jede andere auch, mit ihren speziellen Einsatzgebieten. Gruß --Revvar %&§ 15:25, 5. Mai 2006 (CEST) (PS: Bitte unterschreibe mit --~~~~ . Diese Zeichenfolge wird dann automatisch durch deinen Benutzernamen, sowie Datum und Uhrzeit ersetzt.)Beantworten

--Revvar %&§ 16:37, 5. Mai 2006 (CEST)Beantworten

Nun ja, zu Deiner letzten Bemerkung (entschuldige, wenn ich nicht immer sofort antworte; ich schaue nicht jeden Tag vorbei.), ich bin davon ausgegangen, dass der Unterschied zwischen Template-Includes und echten Libraries jedem (der schon einmal programmiert hat) klar ist. Falls nicht: Libraries haben (im C-Fall) ein kurzes Header-File, das vom Client-Programm eingebunden und mitübersetzt wird. Wegen seiner Kürze spielt das in der Compilerperformance praktisch keine Rolle. Der eigentlich Code steht in der Implementierung und ist vorübersetzt, wird also in einem zweiten Schritt nach der Übersetzung einfach an das Clientprogramm anmontiert (engl: gelinkt, gelinkage editet, gebunden...) Dabei werden vom Rechner nur noch Referenzen aufgelöst, d.h. die entgültigen Adressen eingetragen. Kostet auch wenig Zeit. Bei C++ gibt es diese klare Aufgabentrennung schon ohne Templates nicht mehr. Denn das Headerfile (x.hpp) enthält die gesamte Klassendefinition (In C sind nur Deklarationen erlaubt). Schon jede inline-Funktion wird bei _jeder_ Clientübersetzung jeweils neu übersetzt. Das eigentliche Code-File (x.cpp) ist oft nur noch sehr klein und fehlt manchmal komplett, weil alles im Header steht. Es ist etwa so, als wenn man in C statt der Headerfiles bei jeder Übersetzung den kompletten Librarycode jeweils neu übersetzen müsste. Bei Templates verschärft sich dieses Problem noch: Templates können prinzipiell nicht vorübersetzt werden, weil die Parameter des Templatecodes erst bei Aufruf einer Funktion oder bei Verwendung der Templateklasse bekannt sind und eingesetzt werden können. Genau in diesem Fall wird der Templatecode mit den jetzt bekannten Parametern übersetzt. Das kann in einem Clientprogramm dann sogar mehrfach passieren.

Es gibt technische Lösungen für dieses ganz spezielle C++-Problem. Sie sind alle jedoch komplett inkompatibel zum klassischen Ablauf einer Compilation (getrennt ind Übersetzung und Montage) und können deshalb die existierenden Linker nicht benutzen. Neben dem Compiler muss also für C++ noch ein eigener Linker entwickelt werden, der wiederum nicht für andere Sprachen tauglich ist. Ein weiterer Grund, warum es so wenige standardtreue C++-Implementierungen gibt und warum es so viele versteckte Kompatibilitätsprobleme in C++ gibt, die erst spät in der Entwicklungsphase eines Systems auftauchen.

--Brf 09:46, 12. Mai 2006 (CEST) (Ich probier das hier mal mit der Unterschrift; ich habe das noch nicht gewusst)

Zu einigen anderen Fragen von Dir ein paar Stichpunkte:

...ich gebe keine C++-Kurse. Ok; Ich kenne sie Sprache seit 1988 gut, ich habe alle Entwicklungen verfolgt und denke, dass ich hier etwas beitragen kann. Ich würde den Artikel sowieso zum Neuschreiben vorschlagen, denn er enthält Informationen aus den letzten etwa 15 Jahren, die nicht immer den aktuellen Stand reflektieren und auch etwas zusammengestückelt wirken. Ich habe im Moment keine wirkliche Zeit dazu und bräuchte auch die Gewissheit, wenn ich den Artikel (mit dann einiger Arbeit) neu formulieren, dass er nicht einfach wieder revertiert wird.

Ich habe bei anderen EDV-Themen in Kursen auf Wikipedia verwiesen, tue das jedoch nur, wenn das was ich für relevant halte, auch wirklich drin steht. Das war einer der Gründe, warum mir ein paar Ergänzungen wichtig waren (und sind). Natürlich sind solche Ergänzungen dann genauso hineingestückelt wie das in diesem Artikel wahrscheinlich schon mehrmals passiert ist.

Aber wenn du soetwas ohne Quellen in den Artikel schreibst, musst du damit rechnen das Andere das nicht nachvollziehen können. Ein solches Nachvollziehen würde aber dann keinen Lexikon-Artikel mehr bedeuten, sondern mindestens einen Fachaufsatz. Was ich eine Stelle weiter oben beschrieben habe, ist ja auch noch verkürzt und kann von jemandem, der nichts vom Compilerinnenleben versteht, auch nicht nachvollzogen werden. Solche Fachartikel gibt es; z.B. http://atlas.web.cern.ch/Atlas/GROUPS/SOFTWARE/OO/tools/java/misc/ACritiqueOfC++.pdf Hier sind etwa 60 engbeschriebene Seiten durchzuarbeiten. Auch in Lehrbüchern wird das Problem diskutiert. Beispiel: Breymann, ISBN 3-446-22330-4, 7. Auflage, S 257)

Was du beschreibst ist imho ein Problem des Make-Prozeses Nein, das hat nichts mit dem Make zu tun, sondern mit der Montage (ld)

und nicht der Sprache. und sehr wohl mit der Sprache. Ich kenne nicht alle Sprachen, aber viele und von diesen (C, C++, Pascal, Algolm Fortran, Ada, Java, Pl/I, Eiffel...)ist C++ die einzige.

Warum sind sie "schwer zu kompilieren s.o.

In welchen Fällen tritt das Problem des "Template Induced Code Bloat" denn auf? Nun wenn Du den Fachbegriff selbst verwendest, warum tust du dann so als hättest du von dem Problem überhaupt kein Ahnung? Denn ich habe diesen Fachbegriff hier nicht eingebracht.

vielleicht wenn man Templates zu unüberlegt einsetzt? Nein, es ist wirklich ein Template-Problem

--Brf 10:10, 12. Mai 2006 (CEST)

Hallo Brf, danke für deine gutgemeinte Ausführungen, die sind aber nicht nötig, wenn du meinst eine Wissenlücke bei mir schließen zu müssen, reicht ein Link. Das ich von dem Problem keine Ahnung hätte, unterstellst du mir leider [1]- und scheinst deshalb meine Argumente nicht richtig durchzulesen. Also, verstehe ich dich richtig: du hältst die Templates an sich für das Problem, also das pure Vorhandensein - oder siehst du eine falsche Umsetzung dieses Konzeptes in der Sprache C++? [2]

Könntest du die Behauptungen „Denn das Headerfile (x.hpp) enthält die gesamte Klassendefinition (In C sind nur Deklarationen erlaubt).“ - bitte belegen, steht das so irgendwo im Standard und keiner hält sich dran ([5]) ? [3]

Wie auch immer, bitte in Zukunft kurze Antworten, ohne Lehrausführungen, aber mit Begründung. Antworten wie Nein, es ist wirklich ein Template-Problem enthalten keine Argumente. Wenn es dir lieber ist können wir auch im Wikipedia:Chat privat diskutieren, ich habe nämlich das Gefühl das wir aneinander vorbeireden.--Revvar %&§ 10:58, 12. Mai 2006 (CEST) [4]Beantworten

weiterer Senf

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

Vielleicht noch ein kleiner Zusatz zu den "riesigen hello world programmen" in C++: die executables werden auch nur 4k gross, wenn man nicht statisch gegen die libstdc++ linkt. Und wenn ich ein C programm statisch linke, wird es auch 500k gross, das c++ hello world ist dann zwar 900k gross, es beinhaltet aber auch das ganze locales geraffel, was relativ komplex werden kann. Plasmahh 13:01, 15. Mai 2006 (CEST)Beantworten

Senf zurück

Und wenn ich ein C programm statisch linke, wird es auch 500k gross, ist nun wirklich falsch: Wenn hallo.c statisch gelinkt wird, ist die .exe-Größe mit MinGW 15 kB. Beweis: G:\ckurs>gcc -x c hallo.c -static

G:\ckurs>dir 15.05.2006 18:35 15.663 a.exe 24.11.2005 16:39 83 hallo.c G:\ckurs>gcc -v Reading specs from c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host= mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable -languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --e nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-ja va-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchroniz ation --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special)

Und im Senf von Plasma ist noch mehr falsch. Aber das haarklein zu beweisen, fehlt mir die Lust. Ich glaube ich ziehe mich von diesem Artikel zurück. Sei mutig und verbessere, diese Devise von Wiki wird hier ad absurdum geführt.

Schonmal gesehen dass die datei nicht wirklich statisch ist, sondern geschummelt wird und gegen die 340kB grosse msvcrt.dll gelinkt wird?

Es gibt halt keine Perfekte Programmiersprache, und wem C++ nicht gefällt soll etwas anderes benutzen, und nicht haltlos darüber herziehen. Denn die wirklich sachlichen diskussionen über fehler der sprache finden woanders statt. Traurig! Wenn ich mich in einem Artikel über etwas informieren will, erwarte ich auch Informationen. Wenn alles kritische rausfliegt mit dem Argument, wer (egal wie begründet) kritisiert, soll doch was anderes benutzen, bleibt bestenfalls Reklame für C++ übrig. --Brf 18:44, 15. Mai 2006 (CEST)

Auwei, da habe ich dich mit meinen "Belege"-Forderungen hoffentlich nicht verschreckt. Auf Aussagen die der Autor selbst nicht vorher verifiziert, musst du auch keine Gegenbelege bringen (der Einsteller ist immer in der Beweispflicht), bei offensichtlichen Unsinn - kurze knappe Antworten (nicht vergessen es ist ein Wiki und wir haben kein Türsteher ;-)). Gruß --Revvar %&§ 20:47, 15. Mai 2006 (CEST)Beantworten

Es geht hier doch offensichtlich nicht darum, dass keine kritische Information vorhanden sein soll, sondern darum dass diese nicht wertend dargestellt werden soll. In den Diskussionen oben kriegt man schnell den Eindruck, die Leute schreiben "C++ ist schlechter als XYZ weil..." wenn mit anderen Sprachen verglichen wird, weil C++ das nicht so macht wie XYZ. Aber deswegen ist es doch auch C++ und nicht XYZ, oder ;) ?

Templates-Kritik 2

Letzter Kommentar: vor 18 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt

[1] Nein, das unterstelle ich nicht; Schließlich schreibst du an einem Artikel über C++ mit.

[2] Ja Templates halte ich für die Ursache eines Problems. Und dieses Problem will ich auch in einem Artikel über C++ unterbringen. Java ohne Templates hat das Problem nicht. Ada mit einem anderen generischen Ansatz hat das Problem auch nicht. Eiffel hat das Problem nicht. Es ist C++-spezifisch und gehört in diesen Artikel.

[3] Nun das muss doch nicht belegt werde, sondern steht in jedem Lehrbuch, das Programme enthält, die aus mehr als einer Datei bestehen. Und das steht auch im Standard, aber nur indirekt; Kapitel 16; S. 319, wo der gesamte C-Präprozessormechanismus für C++ übernommen wurde, und über den Rest des Standards verstreut, wo einzeln definiert ist, was in Header-dateien stehen darf (Namespaces, Klassen, klassische C-Deklarationen...) (Das doxygen-Link kapieren ich nicht. Sein Inhalt hat mit unserer Diskussion überhaupt nichts zu tun???)

[4] Wenn ich wenig schreib, ist es Dir zu wenig; wenn ichs ausführlich versuche, unterstellst Du mir Lehrausführungen. Ein wenig reden wir wirklich aneiander vorbei. Ich weiss immer noch nicht genau, wie weit Du C++ kennst. Schreib das mal. Ich kenne den Standard, Stroustrup, Die wichtigsten de-Lehrbücher Ellis (ARM)... und habe C++/Java/C-Erfahrung.

Und die Frage: Sollen Probleme wie Template code bloat im Artikel auftauchen? Meiner Meinung ja! In welcher Form? Das sollten wir diskutieren. Ich habe jetzt einen Termin und kann erst am Montag wieder antworten.

--Brf 11:16, 12. Mai 2006 (CEST)

zu [2] - ACritiqueOfC++ sieht das interessanterweise anders, vieleicht solltest du dir den Absatz über Templates dort noch mal durchlesen. Wie auch immer, das Problem "code bloat" tritt dann auf, wenn man Templates unüberlegt einsetzt, sich dem "code bloat" Problem nicht bewußt ist. Es gibt genug Anwendungsfälle für Templates, wo du das Problem überhaupt nicht hast. Es gibt auch gute Techniken einen "code bloat" zu vermeiden (ein Buch was ich gerade zur Hand habe: C++ , André Willms, Addison-Wesley, 2005, ISBN 3-8273-2182-4, Kapitel 8).

zu [3] - Es geht um den C++-Teil: Lehrbücher dazu, die ich bisher gelesen habe, enthalten nicht die Aussage, das in C++ die Definitionen im Header stehen müssen. Das führt die ganze Zwangstrennung Deklarationen in den Header und Definitionen in das cpp-File ad absurdum.

zu [4] - Damit meine ich das du bei der Sache bleibst und nicht anfängst mir irgendwas zu erklären müssen, Fakt+Quelle reicht mir. Ich lese dann selbst dort nach, wenn es mir neu ist. Wie ich bereits in früheren Diskussionen mit anderen Nutzern gesagt habe, werde ich hier öffentlich kein Profil von mir einstellen. Erstens kann hier sowieso jeder behaupten was er will, ohne das es nachprüfbar wäre, und Zweitens beurteile ich andere Nutzer nach ihren Argumenten und was ich da erwarte habe ich bereits in meinen vorherigen Beitrag angemerkt.

Zu deiner Frage, gerne können wir das Thema aufgreifen, nur sollten es ausgewogen und neutral geschrieben sein, und passt vieleicht auch besser in den Artikel Template (Programmierung).

Gruß --Revvar %&§ 11:50, 12. Mai 2006 (CEST)Beantworten

[2] Ich kenne den Artikel gut; ich finde ihn hervorragend; ich teile aber die Meinung von Mr. Joyner bez. Templates nicht. Ich weiss, dass er schreibt, es wäre kein Problem, wenn man Templates vermeidet, denn dann <zitat-übersetzung> muss man nicht bezahlen, was man nicht bestellt hat </zitat>. Nur dass man dann natürlich die STL komplett vermeiden muss. Und das kanns wohl nicht sein. Und das TCB (Template Code Bloat) - Problem diskutiert er wehr wohl auh mit den negativen Nebenwirkungen.

[3] Nicht alle Definitionen, aber natürlich die Klassendefinitionen. Und dass in C++ die scharfe Trennung zwischen Deklaration und Definition ad absurdum geführt wird, war Stroustrup sehr wohl bewusst. Ich finde dieses Zitat nicht auf die Schnelle, aber Stroustrup hat ca 1990 mal diskutiert, of eine Klasse im C-Sinn etwas definiert oder deklariert. Sein Ergebnis: beides! und deshalb wäre es wurst, ob man Def. oder Dekl. dazu sagt. Die Folgeprobleme in Headerfiles hat er geflissentlich ignoriert.

[4] Habe ich jetzt genug Quellen angegeben? [4] Aber man verwendet nicht dieselben Argumente, wenn das Gegenüber nicht dieselben Vorkenntnisse hat. Einem Compilerbauer gegenüber reicht der Satz, dass ein Template instanziiert wird, wenn ein Objekt der Klasse definiert wird. Einem Studenten, der C++ lernt, kann ich dasselbe nach einem C++-Kurs in etwa 1/4 Stunde erklären. Und Dir gegenüber habe ich zunächst sehr knapp formuliert, weil ich davon ausgegangen bin, dass jemand, der einen C++-Artikel betreut, ähnliche Voraussetzungen hat wie ich. Dann bin ich viel ausführlicher geworden, weil ich plötzlich vermutet habe, dass Du nur den Wiki-technischen Teil betreust (und natürlich, weil Du die Begründung angefordert hast). Das ist wieder gekippt, als ich bei Dir den Begriff TCB gelesen habe, den ich bewusst nicht verwendet habe (wie heisst das bei Wiki?, Oma-Test?). Nachprüfen kann es übrigens jeder der einen Normal-C++-Compiler einmal anschmeisst. (Ich meine damit einen billigen oder kostenfreien, z.B. gcc; es gibt hochgezüchtete teuere (pg), die mit dem Problem wesentlich besser umgehen. - Das gehört übrigens so nicht in den Artikel, denn dann müsste ich das wirklich genau recherchieren, und dazu habe ich derzeit die Zeit nicht. Und das Geld nicht, denn ich bräuchte wahrscheinlich 3-4 Referenzinstallationen.

Und nichts für ungut; Schöne Grüße; Bis Montag; --Brf 15:42, 12. Mai 2006 (CEST)

Hallo Brf, ich würde gerne das wir uns mal an einen Textvorschlag wagen, der die positiven und negativen Seiten der Templates unter C++ beleuchtet. Unschlüssig bin ich mir noch, ob es besser hier oder unter Template (Programmierung) passen würde (oder beides?). Gruß --Revvar %&§ 20:57, 15. Mai 2006 (CEST) (PS: Textänderungen sind hier übrigens nicht immer so anstrengend)Beantworten

C99

Letzter Kommentar: vor 18 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt

Compiler, die C99 unterstützen:

gcc
Comeau
Intel
...

Welche weiteren gibt es? --Kadeck 20:29, 13. Mai 2006 (CEST)Beantworten

Comeau definitiv (siehe z.b. cpp.sf.net ein sehr schöner pastebin mit eingebautem comeau) und der intel scheint es auch zu können (haben ja beide das gleiche frontend). Übrigens für die Compilerliste allgemein vielleicht noch ein zusatz, dass der intel compiler nur mit einer gcc installation ordentlich läuft (erst ab 9.1 wird gcc 4.x unterstützt) und dass er zwar keine eigene ide hat, aber mit eclipser kommt. Plasmahh 13:04, 15. Mai 2006 (CEST)Beantworten

C99 gehört in diesen Artikel doch eigentlich nur in Bezug auf C++. Eine Sammlung von C99-kompatiblen C-Compilern ist hier eigentlich fehl am Platz--Brf 10:29, 16. Mai 2006 (CEST)

Es geht mir nicht um die Liste selbst. Durch die Auflistung von C99-Compilern hier in der Diskussion möchte ich die im Artikel gemachte Aussage Mittlerweile unterstützen viele Compiler diesen neuen Stand C99 besser untermauern. --Kadeck 18:51, 16. Mai 2006 (CEST)Beantworten

Ich habe vor etwa einem Jahr einmal versucht, mir einen Überblick darüber zu verschaffen, wieviele C99-Compiler es gibt. Damals waren es etwa 10, also nicht gerade viele. Vollständig unterstützte davon überhaupt kein Compiler C99. Ich rechne damit, dass eine etwas breitere Unterstützung zumindest von Teilen des C99-Standards stattfinden wird, nachdem diese Sprachmerkmale in C++ Einzug gefunden haben. Die Abhängigkeiten sind heute nämlich eher umgekehrt. --Poldi 15:03, 11. Jun 2006 (CEST)

Template

Ich habe bisher den Artikel über Templates ignoriert, weil das TCB-Problem C++-spezifisch ist und auch nicht durch intelligente Programmierung vermieden werden kann. Nur durch "Unterlassung von Templates" seitens des Programmierers oder durch extrem spezialisierte Compiler seitens des Compilerherstellers.

Und ich dachte das gehört nicht in einen Template-Artikel. Jetzt habe ich den mal überflogen un denke, er hat den falschen Titel. Templates sind ein in mehreren Sprachen (C++, Ada) verfügbares Programmierhilfsmittel. Genau darüber steht da nichts drin. Er enthält lediglich C++-Templates und sollte auch so heißen. Dann müsste es einen weiteren Artikel Ada-Templates geben und einen übergeordneten Templates (allgemein) --Brf+

Die Tatsache, dass Compiler die Codeaufblähung unterbinden können, zeigt doch, dass es kein Problem der Sprachdefinition ist. --Poldi 15:47, 5. Jun 2006 (CEST)

Doch, ganz einfach weil ein mit den Compilerstandardtechniken geschriebener Compiler (flex, bison, ld...) das eben nicht unterbinden kann. Ein C++-Compiler der das tut ist immer eine absolute Sonderentwicklung. Und hat damit ganz eigene Probleme, z.B. ganz banal, dass er nicht so gut getestet wurde wie ein Compiler, bei dem einzelne Module auch für andere Sprachen einsetzbar sind und damit auch in ganz anderem Kontext verwendet werden. Und jede Verwendung von Software ist auch ein Test dieser Software. Deshalb ist Gnu ja auch so fehlerarm.--Brf 09:51, 6. Jun 2006 (CEST)

Die C++-Sprachdefinition schreibt aber nicht vor, dass man einen Linker verwenden muss, der für andere Programmiersprachen entwickelt wurde. Das Eliminieren von Mehrfachinstanzierungen ist auch eigentlich nicht kompliziert. Ein Template X, das in zwei cpp-Dateien mit dem gleichen Typ T instanziert wird (Beispiel: X<int> x;), sollte der Linker für das resultierende Programm zusammenfassen können. Ich kann mir nicht vorstellen, dass der g++ dazu nicht in der Lage sein soll. Bist du dir ganz sicher, dass das mit g++ nicht funktioniert? --Poldi 20:53, 6. Jun 2006 (CEST)

PS: Ich habe mir sagen lassen, man müsse beim g++ einen Schalter -frepo setzen, um ihn zum Eliminieren der überzähligen Instanzierungen zu veranlassen. Vielleicht ist das ja schon des Rätsels Lösung. Zum Testen würde ich empfehlen, statt umfangreicher Bibliotheken kleine, selbstgeschriebene Klassentemplates zu verwenden, um andere Effekte, die evtl. die Größe des erzeugten Programmes beeinflussen, möglichst ausschließen zu können. --Poldi 22:39, 9. Jun 2006 (CEST)

Polymorphie ist das Kernkonzept der OOP

Das stand einmal im Artikel, wurde aber entfernt. Zu dem Thema äußert sich Stanley B. Lippman, ein Mitarbeiter von B. Stroustrup, in seinem Einführungswerk zu C++ im Kapitel 15.1: "The key idea behind OOP is polymorphism." Ich denke das ist inhaltlich fast deckungsgleich, deshalb bin ich dafür, das wieder in den Artikel aufzunehmen. Eventuell könnte man die Formulierung Kernkonzept durch Schlüsselkonzept ersetzen. --Poldi 20:59, 11. Jun 2006 (CEST)

Hier ein paar OO-Grundkonzepte: Objekt, Klasse, Attribut, Operation, Botschaft, Vererbung und Polymorphismus. (Helmut Balzert, Lehrbuch der Software-Technik, Band 1, 1995) - Polymorphismus ist eines der wichtigen, aber nicht das Kernkonzept der OO. Ich vermute mal, dass das ein Denkansatz war, von Polymorphie auf die anderen Konzepte zu schließen. Kapselung nach außen durch Objekte und die Erzeugung der vielen Erscheinungsformen wird dann durch Vererbung erledigt. Aber dieser Denkansatz macht die anderen Konzepte zu Hilfsmittel. Das ist aber falsch, weil jedes dieser Konzepte eine eigene Daseinsberechtigung innerhalb der OO besitzt (Alan Kay: „Zwar entstand OOP aus vielen Gründen... Der wichtigere Grund war der Bedarf für ein besseres Modulsystem ..., das auch das Verbergen von Einzelheiten beinhaltete.“ {Ryan Stansifer, Theorie und Entwicklung von Programmiersprachen, Prentice Hall, 1995}- daher sicher auch der Name: OO). --Revvar (D RT) 09:06, 12. Jun 2006 (CEST) (PS: Polymorphie (Programmierung))

Was meinst du mit dem Satz „Ich vermute mal, dass das ein Denkansatz war, von Polymorphie auf die anderen Konzepte zu schließen.“? --Poldi 18:57, 12. Jun 2006 (CEST)

Hallo Poldi, das bezieht sich auf die Aussage von Lippman "The key idea behind OOP is polymorphism." - die ich mir nur so erklären kann, dass er die anderen Konzepte lediglich als Hilfsmittel zur Umsetzung des Polymorphismus sieht. Gruß --Revvar (D RT) 08:19, 13. Jun 2006 (CEST) (PS: schön das du hier wieder mitarbeitest :))

Es geht nicht darum, was wichtig ist, sondern was die objektorientierte Programmierung ausmacht, und es ist die Polymorphie (genauer gesagt Laufzeitpolymorphie), die dieses Programmierparadigma von anderen abhebt, das Schlüsselkonzept eben. Das, was in dem Zitat von Alan Kay beschrieben ist, nennt sich übrigens Datenabstraktion und wurde viele Jahre vor der objektorientierten Programmierung erfunden. Zu diesem Thema empfehle ich insbesondere die Lektüre von Stroustrups Die C++-Programmiersprache (wie ich es schon weiter oben in dieser Diskussion angegeben habe). --Poldi 17:41, 14. Jun 2006 (CEST)

Das ist doch Haarspalterei. Du betrachtest dies, wie Stroustrups Mitarbeiter vermutlich auch, zu sehr aus der Perspektive des Programmierers - der Implementation der Konzepte. Gehe mal gedanklich ein paar Ebenen höher und du wirst sehen, das die OO sich durch den gesamten Entwicklungsprozeß ziehen kann (OOA, OOD, OOP...), von der Analyse an, mit einer teilweise direkten Abbildung zum modellierten System. Sich in Sachen Verständnis der OO ständig auf Stroustrup zu beziehen ist nicht wirklich eine gute Idee, wie man z.B. an den friends sehen kann. Die objektorientierte Programmierung wird durch alle oben aufgeführten Grundkonzepte geprägt, da sie teilweise voneinander abhängen bzw. bedingen. Das Zitat sollte nur klarmachen, wie der Erfinder von Smalltalk die Sache damals angegangen ist. Ich habe nicht behauptet alle verwendeten Konzepte wären von ihm neu erfunden worden. Wenn es überhaupt das Schlüsselkonzept oder Grundkonzept, oder was auch immer, gibt, dann ist es die Modellierung als und mit Objekten. Ein Zitat von Bob Barton verdeutlicht dies ebenfalls: „Zum ersten Mal stellte ich mir das Ganze als den ganzen Computer vor und fragte mich, warum jemand diesen in schwächere Teile aufteilen wollte, die als Datenstrukturen und Prozeduren bezeichnet wurden. Warum sollte man ihn nicht in kleine Computer aufteilen, wie dies beim Time-Sharing begann?“ ([Kay, Alan C., The early history of Smalltalk., SIGPLAN Notices, Jahrgang 28, Nummer 3, März 1993, S. 69-96] zit. in [Ryan Stansifer,Theorie und Entwicklung von Programmiersprachen, Prentice Hall, 1995]). Lies einfach mal andere Literatur dazu, kostenlos und online sind auch viele Vorlesungsskripte zum Thema. Gruß --Revvar (D RT) 13:01, 15. Jun 2006 (CEST)

... wie man z.B. an den friends sehen kann. Was genau kann man daran sehen? Gruß --Poldi 15:01, 15. Jun 2006 (CEST)

Ist das nicht offensichtlich? Schon mal drüber nachgedacht, warum andere OO-Sprachen etwas Ähnliches nicht anbieten? Siehe auch meine Empfehlung im letzten Satz davor. Gruß --Revvar (D RT) 07:17, 16. Jun 2006 (CEST)

Tja, du musst mir schon auf die Sprünge helfen. Was kann man an friends sehen? --Poldi 11:50, 16. Jun 2006 (CEST)

Mach ich doch gerne: mit friends wird die aufgebaute Sichtbarkeitsbeschränkung (private & protected) durchbrochen und führt es im Prinzip ad absurdum. Dadurch erzeugt man genau die Abhängigkeiten von den Interna, die eigentlich, aus guten Grund, vermieden werden sollten. Mir ist persönlich kein Einsatz bekannt, der sich nicht auch ohne friends hätte elegant lösen lassen. Schlimmer noch, werden solche Features von den "Künstlern" unter den Programmierern gern verwendet, erfordern also in der Praxis noch mehr Diziplin und Regeln, beim Umgang mit der Sprache. Ich selbst hatte schon das Vergnügen, mich durch ein paar MLOC C++-Code, verfeinert mit friends und Mehrfachvererbung, durchzuarbeiten, die schlicht ein Produkt fehlender OO-Methoden und -Verständnis waren. Sofern es beim Entwurf der Sprache schon vorhanden war, sehe ich darin ein damaliges fehlendes Verständis der OO bei Stroustrup. Gruß --Revvar (D RT) 21:32, 26. Jun 2006 (CEST)

OO und Friends

Sicher lassen sich Friends missbrauchen, und was man missbrauchen kann, wird auch missbraucht, keine Frage. Dennoch sind Friend-Funktionen bisweilen nützlich und wurden deswegen auch in die Sprache aufgenommen. Frieds führen die Sichtbarkeitsbeschränkungen nicht ad absurdum. Friends sind - wie public Elementfunktionen - Teil der öffentlichen Schnittstelle der Klasse. Generell sollte die Anzahl der Funktionen, die auf die interne Repräsentation einer Klasse zugreifen können, möglichst gering halten. Ein klassisches Beispiel für friend-Funktionen sind z.B. überladene Operatoren, welche Zugriff auf die interne Repräsentation der Klasse benötigen. Wenn es symmetrische Operatoren sind, ist es gut und sinnvoll, dafür friend-Funktionen zu nehmen.
Beispiel: Hat man eine Klasse Number, so braucht man nur einen Konstruktor Number::Number(int) und eine friend-Funktion friend Number operator+(const Number&, const Number&) und kann nun sowohl Number+Number, Number+int als auch int+Number benutzen, was doch sehr angenehm ist und mit einer Elementfunktion so nicht zu erreichen ist. --RokerHRO 22:51, 26. Jun 2006 (CEST)

Friends erlauben bei Klassen nur einen undifferenzierten Vollzugriff. Alle privaten Methode und Attribute würden dadurch abhängig von den Friends-Klassen. Richtig ist es aber, nur die benötigten Elemente zu veröffentlichen, was z.B. über ein seperates Interface möglich wäre.

Zu deinem Beispiel: Du beschreibst hier ein allgemeines Dilemma der Verwendung von Operatoren, Klassen und Datenkapselung. Deine Lösung ist in der Anwendung zwar die flexibelste, erzeugt aber eine Abhänggkeit der Operator-Funktion von den Klassen-Interna. Eine zweite Möglichkeit mit einer externe Op-Funktion wäre eine Erweiterung der öffentlichen Schnittstelle um die benötigten Elemente, was aber unerwünscht sein könnte. Die dritte Lösung den Op als Methode zu implementieren ist nicht sonderlich felxibel. Man könnte aber auch ganz auf die Kurzschreibweise mit Operatoren verzichten, und das Ganze mit normalen überladenen Methoden realisieren, also Number Number::add(Number) und Number Number::add(int). Gruß --Revvar (D RT) 09:02, 27. Jun 2006 (CEST)

Friends gehören zur öffentlichen Schnittstelle einer Klasse, genauso wie public Methoden, welche ja auch einen "undifferenzierten Vollzugriff" auf die Klasse haben.

Um das zu verdeutlichen, wie Friends einzuordnen sind, gibt z.B. Stroustrup folgende Erklärung:

„Eine gewöhnliche Elementfunktion spezifiert drei logisch unterschiedliche Dinge:

Die Funktion darf auf private Teile der Klassendeklaration zugreifen.
Die Funktion ist im Sichtbarkeitsbereich der Klasse.
Die Funktiom muss über ein Objekt aufgerufen werden (das heißt, sie hat einen this-Zeiger).

static-Elementfunktionen besitzen nur die ersten beiden Eigenschaften, eine friend-Funktion nur die erste Eigenschaft.“

[nach: B. Stroustrup, "Die C++ Programmiersprache" dt. Fassung, Auflage 3, Seite 295]

Das Beispiel mit der bequemeren Verwendung von (überladenen) Operatoren ist nur ein Beispiel, wo friend-Funktionen sinnvoll sind. Und ich sehe kein Problem darin, sie zu verwenden. Natürlich immer unter der Maßgabe, dass man nur die (Element- oder friend-)Funktionen in die Schnittstelle aufnimmt, die nötig sind und keine weiteren. --RokerHRO 11:10, 27. Jun 2006 (CEST)

Damit erscheint die Einführung von friends logisch, doch ist das genau die Implementierungs-Sicht die ich ein paar Beiträge weiter oben geschrieben habe. Aus Sicht der OO erlaubt man Code außerhalb der Klasse auf privat deklarierte Elemente zuzugreifen, obwohl es doch eigentlich der Zweck von privat ist, selbst innerhalb der Vererbungslinie verborgen zu bleiben. Das Argument "bequemere Verwendung" ist meiner Meinung nach ein Künstlerargument (bitte nicht persönlich nehmen ;-)), der Ausweg wäre lediglich ein wenig mehr Schreibaufwand oder eine Erweiterung der Schnittstelle. Gruß --Revvar (D RT) 11:35, 27. Jun 2006 (CEST)

Deine Friend-Funktion gehört zur Klasse in dem Sinne, dass sie zu ihrer Schnittstelle gehört. Sie liegt halt nur nicht im Namensraum/Sichtbarkeitsbereich der Klasse, sondern außerhalb. Aus reiner OO-Sicht braucht man sowas natürlich nicht, denn da wäre ja auch ein Integer ein Objekt, was Methoden haben kann, und man dann 2.add(x) schreiben könnte. C++ erlaubt das - leider - nicht. So gesehen sind Friends ein "Hack", aber C++ ist im Ganzen ja ein Hack, oder freundlicher gesagt: ein Kompromiss. :-) --RokerHRO 13:29, 27. Jun 2006 (CEST)

und man dann 2.add(x) schreiben könnte - Das könnte man nicht. Denn 2 ist ein R-Wert. --Poldi 21:14, 28. Jun 2006 (CEST)

Na und? die 2 wird dadurch ja nicht geändert. 2.add(x) soll in meinem Falle 2+x und nicht 2+=x heißen. Es geht auch nicht um die Semantik von add, sondern darum, dass bei C++ halt ein integer kein Objekt ist und keine Methoden hat. Nicht einmal konstante Methoden. --RokerHRO 22:51, 28. Jun 2006 (CEST)

Ich würde die Funktion wahrscheinlich anders nennen. :-) Aber angenommen, die von dir vorgeschlagene Notation wäre möglich. Welcher Vorteil ergäbe sich denn deiner Meinung nach daraus? --Poldi 15:02, 30. Jun 2006 (CEST)

Es war nur ein Beispiel, um zu zeigen, warum bei C++ friend-Funktionen durchaus sinnvoll sind. Da man bei C++ keine Elementfunktionen von eingebauten Datentypen definieren kann, muss man eben zu friends greifen, um etwa symmetrische arithmetische Operationen zu definieren. --RokerHRO 17:09, 30. Jun 2006 (CEST)

Bei nicht-eingebauten Typen stehst du aber vor dem gleichen Problem, außer wenn du z.B. den Typ selbst definierst. Das Problem liegt also woanders. --Poldi 20:31, 30. Jun 2006 (CEST)

Es war nur ein Beispiel, wo friends sehr sinnvoll sind. Es war keine vollständige Auflistung, wo friends überall sinnvoll sind. --RokerHRO 20:44, 30. Jun 2006 (CEST)

Ok. :-) --Poldi 10:17, 1. Jul 2006 (CEST)

Aus Sicht der OO erlaubt man Code außerhalb der Klasse auf privat deklarierte Elemente zuzugreifen, - Nein, das tut man nicht. Durch die Friend-Deklaration wird der Code der Klasse zugeordnet. Vielleicht wird es durch ein Beispiel deutlicher:

class A {

// ...

static void m1(A&);

friend void m2(A&);

};

void f() {

A a;

A::m1(a);

m2(a);

}

Der Unterschied zwischen m1 und m2 besteht lediglich in der Angabe des Gültigkeitsbereichs durch den Bereichsoperator A::. --Poldi 21:14, 28. Jun 2006 (CEST)

Mal ein Gegenbeispiel:

class A {
  ...
  friend class B;
}

Ein Objekt der Klasse B hat dann immer Vollzugriff auf Objekte der Klasse A. Beide bleiben aber eingeständige Objekte, nur das für B die Zugriffsbeschränkung auf A nicht mehr gelten. Wie würdest du hier dies als Zuordnung beschreiben? Gruß --Revvar (D RT) 21:20, 29. Jun 2006 (CEST)

Angenommen, B sieht so aus:

class B {

// ...

void f1();

void f2();

};

Dann ist obige Deklaration mit friend class B nur eine abkürzende Schreibweise für

class A {

// ...

friend void B::f1();

friend void B::f2();

};

Die erste Form spart Tipparbeit, ist aber ansonsten äquivalent. --Poldi 15:02, 30. Jun 2006 (CEST)

Ergänzende Hinweise zum Thema "Friends"

Anders als behauptet ändern Zugriffsmodifikatoren wie friends, public, protected ... in C++ nicht die Sichtbarkeit.
Anders als behauptet bieten die Sprachen Java, C# und Object-Pascal sehr wohl Mechanismen an, die Ähnlichkeit mit friends in C++ haben.

--Poldi 21:12, 12. Jul 2006 (CEST)

zur Sichtbarkeitsbeschränkung: [6] Abschnitt Zugriffskontrolle; allgemeine Verwendung dieses Begriffes zur Beschreibung der Wirkung dieser Schlüsselwörter: "Die Schlüsselwörter public, protected, private, internal, protected internal, die im Wesentlichen ihren Pendants in Java und C++ entsprechen, legen die Sichtbarkeit von Typdefinitionen fest" aus [7]. Zum zweiten Punkt: Ähnlichkeit ist wohl relativ. Das es Umgehungsmöglichkeiten zu friends gibt, habe ich selbst oben ausgeführt. Deine Wikipedia:Quellen ? --Revvar (D RT) 12:02, 13. Jul 2006 (CEST)

Da der Artikel davon nicht betroffen ist, möchte ich dieses Thema nicht weiter ausdiskutieren. Dann hätten wir also folgenden Stand: Die Seite auf der Uni Münster behauptet, die Zugriffsmodifikatoren ändern die Sichtbarkeit, und ich behaupte das Gegenteil. Das kann man doch einfach mal so stehen lassen. Gruß --Poldi 15:09, 16. Jul 2006 (CEST)

Wozu das dann? - du verschwendest meine Zeit. Meinungsäußerungen, ohne Artikelbezug, haben hier keinen Platz. Aber darauf scheint es bei dir ja rauszulaufen, wie man an der ganzen unseligen Friends-Diskussion sehen kann. Diskutieren der Diskussion willen, und wenn du Quellen bringen sollst, hast du keine Lust mehr. ~~Ich werde dies hier, ab deiner Anfrage an mich, deshalb alles in meinen Benutzerraum verschieben.~~ --Revvar (D RT) 18:32, 16. Jul 2006 (CEST)

Nein, dort gehört es nicht hin. Aber du kannst dir ja eine Kopie machen. --Poldi 21:13, 16. Jul 2006 (CEST)

Merkmale der Sprache

(kopiert von der Qualitätssicherungsseite:)

Vorschlag

Ich mach mal einen Vorschlag, wie der inkriminierte Teil aussehen könnte:

Merkmale

Ausgangspunkt

C++ wurde mit C als Grundlage entwickelt, um die folgenden Eigenschaften von C auch in C++ zu erhalten:

C ist vielseitig, prägnant und maschinennah
C ist geeignet für fast alle Programmierprobleme
C existiert auf allen Platformen
C ist geeignet für Unix-Programmierung

(zitiert nach Stroustrup, C++ Programming Language, 3. edition)

Ziele

C++ folgt den nachstehenden Paradigmen der Programmierung:

Siehe auch: Programmierparadigma, Entwurfsmuster, RAII, Metaprogrammierung

Eigenschaften

Viele der Eigenschaften von C++ erklären sich mit dem Ausgangspunkt und den erklärten Zielen.

C++ gestattet maschinennahe und abstrakte Programmierung.
C++ wird für große Programmierprojekte empfohlen (Design Patterns demonstriert die Beispiele in C++)
C++ kann auf fast allen Platformen kompiliert werden und ist somit fast überall verfügbar.
C++ wurde bei AT&T entwickelt, ist aber trotzdem kein proprietäres Produkt.
Für C++ existiert eine Norm (ISO/IEC 9899:1990 ), die weiterentwickelt wird.
C++-Compiler können C übersetzen und anbinden. C-Code kann weiterverwendet werden.
Auch für C++ existieren gute freeware und kommerzielle Libraries zu verschiedenen Problemen.
Wegen der geforderten Kompatibilität zu C enthält C++ historischen Ballast, der in neuentwickelten Sprachen heute nicht mehr existiert (Präprozessor, Zeiger). Stroustrup empfiehlt ausdrücklich diese Sprachteile nur sehr vorsichtig zu verwenden.
Die aktuellen Compiler (Stand: 2006) implementieren oft nicht den kompletten Standard. Vor allem in der Library existieren oft Lücken. (Beispiel: Gnu-C++ [[8]] dort unter TODO)
C++ kennt keinen garbage collector, keine Threads, keine GUI-Programmierung und keine Netzprogrammierung. Für diese Probleme müssen externe Libraries benutzt werden.

Kontroversen

Manche Eigenheiten von C++ werden sehr kontrovers diskutiert. Siehe [[9]], [[10]] und [[11]]

Der historische Ballast zwingt zu veralteten Programmiertechniken (Headerfiles, Zeiger, Makros)
So wird die Komplexität der Sprache als zu hoch bewertet. Insbesondere die Operatorfunktionen sind eine Ursache vieler Probleme ind großen C++-Programen
Viele C++-Compiler benötigen deutlich mehr Übersetzungszeit als bei vergleichbaren C-Programmen und erzeugen deutlich größere ausführbare Programme. (Benchmarklinks unter [[12]], Benchmarkergebnisse für GCC u.a. bei [[13]], siehe summarized results)
Für effiziente Compiler reichen die Standardtechniken des Compilerbaus nicht mehr aus.
C++ ist schwerer zu erlernen und benötigt viel Prgrammiererfahrung, um gute Programme zu produzieren.

Vorschlag Ende

--Brf 17:04, 8. Aug 2006 (CEST)

(Anm.: Habe zum Zwecke der besseren Darstellung auf dieser Seite die Überschriftenebenen geändert) --Dtk 21:53, 8. Aug 2006 (CEST)

@Brf, ich finde deinen Vorschlag gut. Ich bin beeindruckt. Vor allem gefällt mir die strukturelle Verbesserung, die du damit einbringst. Ein paar Anmerkungen:

Auch die Effizienz der resultierenden Programme (hocheffizienter Code, s.o.) ist ein erklärtes Designziel von C++.
ISO/IEC 9899:1990 beschreibt nicht C++, sondern C (wohl ein Versehen; C++ wird unter ISO/IEC 14882:1998 geführt).
Ausdrucksstärke (s.o.) ist an das englische Wort expressiveness angelehnt. Dazu findet Google in Kombination mit "C++" 156.000 Stellen.
Weitreichende Möglichkeiten für die Metaprogrammierung. Für sich genommen ist das schwer zu verstehen, dennoch ein wichtiger Aspekt. Die Metaprogrammierung schlägt die Brücke zwischen hoher Abstraktion und Maschinnennähe (bzw. Effizienz).
Die aktuellen Compiler (Stand: 2005) sind rückständig bezüglich der Umsetzung der ISO-Norm. Etwas ungeschickt und auch überzogen formuliert, dennoch ist was dran. Ich halte es für erwähnenswert. (Auf der C++-Diskussionsseite hat es eine längere Diskussion zu diesem Thema gegeben, siehe Archiv). Dass die aktuellen Compiler nicht immer optimalen Code produzieren, sowohl in Bezug auf Geschwindigkeit als auch auf Code-Größe, liegt in einigen Fällen auch daran, dass die Hersteller immer noch mit der Erfüllung der ISO-Norm beschäftigt sind, anstatt sich schon auf die Optimierungen ihrer Produkte konzentrieren zu können.

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

Compiler

Letzter Kommentar: vor 17 Jahren28 Kommentare6 Personen sind an der Diskussion beteiligt

Habe mal die Compiler-Liste mit den von mir bekannten Compilern erweitert. Weiterhin die Liste mal alphabetisch umsortiert, damit es keine indirekte Wertung gibt. So sind alle Compiler neutral aufgelistet und haben teilweise ihre Besonderheiten und Spezialgebiete aufgeführt. Amin K 16:10, 7. Dez. 2006 (CET)Beantworten

Ich möchte doch darum bitten, sich vorher genauer zu informieren, bevor man einerm Compiler eine "Einschränkung" anlastet. Der MSVC8.0 (2005) Compiler der Express Edition hat keine Einschränkungen! Ganz im Gegenteil, er kann sogar Optimierten Code erzeugen. Die Express Edition ist nur deshalb kostenlos, weil keine MFC/ATL dabei ist und die IDE sich nicht mit AddOns/Plugins erweitern lässt. Ansonst kann man mit der Express Edition alles machen, was man zum C++ Programmieren benötigt. Amin K 16:42, 7. Dez. 2006 (CET)Beantworten

Seit wann ist MSVC kein Compiler? Die IDE ist ein Programm zur Projekt-Unterstützung und bedient sich einer cl.exe (der MSVC Compiler auf Commandozeilen-Basis) die auch nur von der IDE aufgerufen wird. Man kann den MSVC Compiler sogar von jeder anderen IDE (CodeBlocks u.a.) benutzen, ohne VisualC++-IDE. Wer die Plugin-Unfähigkeit der IDE auf den Compiler bezieht, hat die Trennung von IDE und Compiler nicht verstanden. Also bitte in Zukunft nicht sinnlos von eingeschränkter Compiler-Funktionalität reden! Amin K 17:10, 7. Dez. 2006 (CET)Beantworten

Hey, hier geht's ja gut zur Sache! Mein Tip: WP:AGF (oder wie immer das auf deutsch heißt).

Die Tabelle war schlicht uneinheitlich: Wenn der Eintrag auf die IDE lautet, ist die beschränkte Version sehr wohl beschränkt. (Daß der Eintrag in diesem Fall garnicht in die Tabelle der Compiler gehört, hatte ich schon andernorts erwähnt.)

Vom Compiler war vorher nicht die Rede, ich habe also niemals Aussagen darüber gemacht, ich verstehe also Deine Aufregung nicht. (Oder vielmehr: Ich habe so meinen Verdacht, der ist aber nicht schmeichelhaft für Dich.)

In der Tabelle geht es um verfügbare Compiler. Richtig! Die IDEs sind doch zweitrangig, für das Kompilieren eines C++ Programms. Das es eine Spalte "IDE" als Zusatzinformation gibt, macht die Tabelle noch lange nicht zu einer IDE-Übersicht. Deshalb verstehe ich nicht, wie man sich so auf die IDE-Funktionen verbeissen kann? Da eine IDE irrelavant in dem Kontext ist. Amin K 17:49, 7. Dez. 2006 (CET)Beantworten

Festbeißen? In dem Eintrag (der nicht von mir stammt) war der Compiler nichtmal erwähnt, sondern nur die IDE. Deine Aussage, daß es keine Einschränkungen gibt, ist für die IDE aber falsch!!!111elf!! --62.225.37.69

Turbo C++, Sun Studio, IBM XL C/C++

Worin unterscheidet sich dieser Compiler vom Borland C++? Muss man wirklich beide erwähnen?

Borland C++ Compiler sollte eher bald raus aus der Liste! Denn Borland Entwicklertools wird es zukünftig nicht mehr geben, da sie ausgegliedert wurden. Ich habe Turbo C++ eingefügt, weil darin der zukünftige Compiler enthalten ist. Soll heißen, die Tools heißen zukünftig "Turbo Sowieso" von einer anderen Firma. Amin K 13:02, 11. Dez. 2006 (CET)Beantworten

Mit "zukünftigen" Dingen sollten wir in der Wikipedia immer vorsichtig sein. Wenn es soweit ist, können wir ja immer noch reagieren. --Poldi 17:53, 12. Dez. 2006 (CET)Beantworten

Ich nehme Turbo C++, Sun Studio und IBM XL C/C++ erst einmal heraus, da sie mir für den Artikel nicht relevant erscheinen. --Poldi 16:02, 26. Dez. 2006 (CET)Beantworten

Ohne eine vernünftige Definition von Relevanz, finde ich das vorgehen eher fragwürdig. Ob die Tabelle nun 2 Zeilen mehr oder weniger hat, ist für den Artikel völlig irrelevant. Aber ob man Implementierungen streicht, weil sie einem irgend wie "erscheinen", ist nicht richtig. Also entweder vernünftige Kriterien aufstellen oder alle aufnehmen. --Kingruedi 17:34, 26. Dez. 2006 (CET)Beantworten

Ich würde sagen, eher einige weglassen, als zu viele Aufnehmen. Es sollten nur solche Compiler aufgenommen werden, die für die Entwicklung der Sprache C++ von besonderer Bedeutung sind oder waren, und das sind im Großen und Ganzen diejenigen, die ich übrig gelassen habe. Den Watcom könnte man vielleicht auch weglassen. Es gibt Richtwerte für die Aufnahme von Weblinks, und da habe ich eine Anzahl von etwa 5 im Hinterkopf. Daran würde ich mich auch hier in etwa orientieren. --Poldi 13:56, 27. Dez. 2006 (CET)Beantworten

Also ich versteh das nicht. Warum wird der Borland Conmpiler drin gelassen, obwohl er nicht mehr weiter verkauft wird? Ich habe doch schon weiter oben gesagt, das Borland keine Compiler und IDEs mehr entwickelt und verkauft. Deshalb hatte ich den Turbo C++ aufgenommen, weil das der offizielle Nachfolger ist. Denn Borland hat seine Developer Tools nach Codegear ausgegliedert (neue eigenständige Firma). Wenn dann müsste der Borland C++ raus, und der neue Turbo C++ muß drin bleiben. Amin K 12:23, 28. Dez. 2006 (CET)Beantworten

Warum wird der Borland Conmpiler drin gelassen, obwohl er nicht mehr weiter verkauft wird? - Weil die Compiler-Liste kein Einkaufsführer sein soll, sondern, wie gesagt, Compiler aufführen soll, die für die Entwicklung der Sprache C++ von besonderer Bedeutung sind oder waren. (s.o.) --Poldi 17:22, 28. Dez. 2006 (CET)Beantworten

Ich sehe jetzt keinen Grund dafür, die Liste irgend wie zu filtern. Ansonsten fehlt ja noch der CFront-Compiler. Die IBM-Compiler sind dann für die Entwicklung auch wichtig, weil sie die einzigen Compiler sind, die Header nicht als Datei-Konzept benutzen etc. --Kingruedi 18:45, 28. Dez. 2006 (CET)Beantworten

Wir müssen es nicht übers Knie brechen. Aber "Filtern" gehört zu den wichtigsten Aufgaben eines Wikipedia-Autors. Der cfront-Compiler ist im Artikel erwähnt. Die Nichtverwendung der Header als Datei-Konzept ist ja eigentlich nur ein Detail. Ich sehe nicht, inwiefern das für die Entwicklung der Programmiersprache von besonderer Bedeutung sein soll. Das Hauptproblem ist meiner Meinung nach auch hier die Listenform. --Poldi 12:44, 31. Dez. 2006 (CET)Beantworten

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

Alphabetische Reihenfolge

Ich halte die alphabetische Reihenfolge für ungeeignet. Eine Enzyklopädie soll Wissen vermitteln, nicht Informationen. Compiler in eine alphabetische Reihenfolge bringen, kann jeder. Eine Einschätzung der Verbreitung eines Compilers geht schon darüber hinaus. Und eine Beurteilung der Konformität ist etwas, womit der Leser in der Regel überfordert sein dürfte. Deshalb gehört es in eine Enzyklopädie, und sei es nur in Form einer Reihenfolgenvorgabe. --Poldi 16:23, 9. Dez. 2006 (CET)Beantworten

Ich kann vage erkennen, daß Du einen Vorschlag machen willst, aber leider nicht, wie dieser aussieht. Kannst Du bitte mal konkret werden? --217.235.243.108

Woran willst du die Reihenfolge rechtfertigen? Z.B. unterstützt der MSVC8.0 heute schon ein erst kommendes C++0x Feature. vector<vector<int>> ints; Die beiden schliessenden Klammern erzeugen auf einem C++ konformen Compiler einen Error. Unter C++0x wurde dieser Fehler behoben und MSVC8 kann diesen heute schon. Wieso steht der MSVC weiter unten, als z.B. ein ICC (dem auch ein export und C++0x-Features fehlen)? Eine Wertung durch eine Reihenfolge halte ich für falsch, da sie auch durch pers. Vorlieben geprägt sein KANN. Man kann Fakten aufzählen (Defizite am ISO-C++-Spec), aber eine Hitparade ist schlecht. Amin K 12:58, 11. Dez. 2006 (CET)Beantworten

Die beiden schliessenden Klammern erzeugen auf einem C++ konformen Compiler einen Error Das ist nicht ganz richtig. Ein komformer Compiler kann eine Fehlerausgabe machen, muss aber nicht. Aber das nur nebenbei.

Zur Tabelle. Man könnte die Tabelle ganz löschen. Dagegen wäre ich nicht völlig abgeneigt. Allerdings enthält sie ein paar interessante Informationen, die nur richtig aufbereitet werden müssten. Das Hauptmanko ist wohl die Tabellenform. Mein Vorschlag: Tabelle raus, und statt dessen einen vernünftigen Text zu den wichtigsten Compilern verfassen. --Poldi 17:53, 12. Dez. 2006 (CET)Beantworten

Ich wäre sogar dafür einen C++ Compiler Artikel zu öffnen. Dann würde der C++ Artikel endlich das sein was er ist: die Sprache bzw. ISO-C++ Spec beschreiben. Und die Compiler bzw. die Implementierungen davon zu separieren. Die Vermischung von C++ und Compiler in einem Artikel birgt großes Konflicktpotential, da die meisten Schreiber hier leider C++ nicht als Sprache ansehen, sondern z.B. MSVC, G++ u.s.w. als C++ sehen. Amin K 12:55, 16. Dez. 2006 (CET)Beantworten

Die Tabelle ist doch sinnvoll. Sie verschafft einen Überblick über Implementierungen. Wenn man mehr machen will, kann man dafür gerne einen eigenen Artikel schreiben. Eine alphabetische Sortierung ist doch auch in Ordnung, da dies ein einfaches Kriterium ist, was man Diskriminierungs frei und ohne Quellen-Problematik anwenden kann. --Kingruedi 17:39, 26. Dez. 2006 (CET)Beantworten

So wie viele andere Teile dieses Artikels würde ich auch die Tabelle nur als Anriss einer Idee zur Verfassung eines Wikipedia-Artikels sehen. Entscheidende Bestandteile, die den Artikel bereichern würden, wie etwa Hintergrundinformationen zur Bedeutung der Compiler, fehlen eigentlich. --Poldi 14:03, 27. Dez. 2006 (CET)Beantworten

>> vs. > >

Die (bisherigen) Syntaxregeln von C++ fassen >> als ein Token auf. Es ist nicht vorgesehen, dass diese beiden Zeichen optional oder falls es einen Syntaxerror geben sollte als zwei Token interpretiert werden sollen. Zumindest habe ich im Standard nichts dazu gefunden. Wenn ein Compiler das tut, okay, dann ist er benutzerfreundlich und fehlertolerant. Denn eigentlich ist obiges Beispiel schlicht fehlerhaft und ein Compiler hat den Code zurückzuweisen. In C++0x soll das evtl. geändert werden, schaunmermal. Noch gilt jedenfalls C++89 mit den kleinen Änderungen von 2003 (ISO-IEC 14882:2003). --RokerHRO 19:20, 16. Dez. 2006 (CET)Beantworten

Ein Compiler hat den Code nicht unbedingt zurückzuweisen. Ein Compiler darf die Sprache erweitern, ohne den Rahmen der Konformität zu verlassen, wenn vorhandene Programme dadurch nicht a) ungültig werden, oder b) deren Bedeutung dadurch verändert wird. Für den beschriebenen Fall mit den spitzen Klammern bei Templates ist das zwar kompliziert, aber möglich. --Poldi 18:55, 17. Dez. 2006 (CET)Beantworten

Hm, okay. Ein Compiler hat ein korrektes Programm korrekt zu übersetzen. Bei fehlerhaften Programmen kann er ... alles mögliche machen. Er kann einen Fehler ausgeben, er kann auch versuchen zu raten, was der Programmierer gemeint hat und in seinem Sinne das Programm dann parsen. Stimmt. Mein Fehler. :-/ --RokerHRO 21:34, 17. Dez. 2006 (CET)Beantworten

Der Zweck dieser Regelung ist wohl ein anderer. Vermutlich soll dadurch die Möglichkeit für Spracherweiterungen offen gehalten werden. Nicht zuletzt lebt C++ davon, dass Erweiterungen, bevor sie in die offizielle Sprache einfließen, möglichst ausgiebig in der Praxis getestet wurden. --Poldi 19:49, 20. Dez. 2006 (CET)Beantworten

>> als Template-Beender und nicht als Shift-Operator aufzufassen ist keine Spracherweiterung sondern eine Sprachveränderung.--87.165.75.203 14:19, 2. Jul. 2007 (CEST)Beantworten

Jain. Wenn es nur dort gemacht wird, wo sich sonst ein Syntaxfehler ergäbe, der Quellcode also vorher gar kein gültiges C++-Programm war, ist es eine Spracherweiterung. So wie ein (fiktiver) operator^^ auch eine Spracherweiterung wäre. --RokerHRO 15:04, 2. Jul. 2007 (CEST)Beantworten

Es würde die Max-Munch Regel außer Kraft setzen und die ist Teil der Sprache (bzw. des Standards). --87.165.75.203 15:52, 2. Jul. 2007 (CEST)Beantworten

Nein, die Max-Munch-Regel gilt ja nur für (normgerechte) C++-Programme. Wer aber std::set<std::pair<int,int>> s; schreibt, hat kein gültiges C++-Programm. Einem Compiler ist es nun freigestellt was er mit nicht der C++-Norm entsprechendem Quelltext macht. Er kann z.B. einfach mit exit(1) die Übersetzung kommentarlos abzubrechen, eine mehr oder weniger sinnvolle Fehlermeldung auszugeben oder ... versuchen, den Quelltext als nicht-normgerechtes C++-Programm zu parsen und so vielleicht doch noch etwas aus dem Quelltext herauszuholen, was der menschliche Schreiber damit gedacht haben könnte. --RokerHRO 16:07, 2. Jul. 2007 (CEST)Beantworten

Vorschlag Ende

--Brf 17:04, 8. Aug 2006 (CEST)

(Anm.: Habe zum Zwecke der besseren Darstellung auf dieser Seite die Überschriftenebenen geändert) --Dtk 21:53, 8. Aug 2006 (CEST)

@Brf, ich finde deinen Vorschlag gut. Ich bin beeindruckt. Vor allem gefällt mir die strukturelle Verbesserung, die du damit einbringst. Ein paar Anmerkungen:

Auch die Effizienz der resultierenden Programme (hocheffizienter Code, s.o.) ist ein erklärtes Designziel von C++.
ISO/IEC 9899:1990 beschreibt nicht C++, sondern C (wohl ein Versehen; C++ wird unter ISO/IEC 14882:1998 geführt).
Ausdrucksstärke (s.o.) ist an das englische Wort expressiveness angelehnt. Dazu findet Google in Kombination mit "C++" 156.000 Stellen.
Weitreichende Möglichkeiten für die Metaprogrammierung. Für sich genommen ist das schwer zu verstehen, dennoch ein wichtiger Aspekt. Die Metaprogrammierung schlägt die Brücke zwischen hoher Abstraktion und Maschinnennähe (bzw. Effizienz).
Die aktuellen Compiler (Stand: 2005) sind rückständig bezüglich der Umsetzung der ISO-Norm. Etwas ungeschickt und auch überzogen formuliert, dennoch ist was dran. Ich halte es für erwähnenswert. (Auf der C++-Diskussionsseite hat es eine längere Diskussion zu diesem Thema gegeben, siehe Archiv). Dass die aktuellen Compiler nicht immer optimalen Code produzieren, sowohl in Bezug auf Geschwindigkeit als auch auf Code-Größe, liegt in einigen Fällen auch daran, dass die Hersteller immer noch mit der Erfüllung der ISO-Norm beschäftigt sind, anstatt sich schon auf die Optimierungen ihrer Produkte konzentrieren zu können.

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

Kommentare dazu

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

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

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

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

Tabellarische Sprachvergleiche sind in

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

http://www.adahome.com/History/Steelman/steeltab.htm

Vor allem in der Library existieren oft Lücken. (Beispiel: Gnu-C++ 1 dort unter TODO)

Das stimmt nicht und wird auch nicht durch die Quelle belegt. Bei der ToDo-Liste geht es ja nicht um Standard-Kompatibilitätsprobleme. Es geht ja eher um Probleme mit Sprachfeatures, wobei sich das ja mittlerweile zum größten Teil auf export bezieht.

Der historische Ballast zwingt zu veralteten Programmiertechniken (Headerfiles, Zeiger, Makros)

Das kann man ja so nicht sagen. Zeiger und Makros sind ja nicht zwingend.

Insbesondere die Operatorfunktionen sind eine Ursache vieler Probleme ind großen C++-Programen

Bitte Beweise für die Aussage vorlegen. Das halte ich für Blödsinn

Für effiziente Compiler reichen die Standardtechniken des Compilerbaus nicht mehr aus.

Das trifft doch im Grunde auf alle modernen Sprachen zu.

--Kingruedi 15:56, 9. Aug 2006 (CEST)

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

http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Template-Instantiation.html#Template-Instantiation

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

http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/CHECKLIST

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

http://gcc.gnu.org/bugs.html#known --Brf 10:28, 10. Aug 2006 (CEST)

Der erste Link ist kein Beleg für folgenden Satz: Für effiziente Compiler reichen die Standardtechniken des Compilerbaus nicht mehr aus. In dem Artikel geht es eben darum, dass der normale UNIX-Linker zu dumm für Templates ist. Aber der UNIX-Linker ist nicht die ultimative Standard-Technik, sondern ein Relikt aus den 70ern. Keine moderne Programmiersprache greift noch auf derartige Konzepte zurück.

Die anderen beiden Links sagen ja auch nichts anderes, als das was fehlt in export, sonst ist alles mehr oder weniger in Ordnung. --Kingruedi 11:53, 10. Aug 2006 (CEST)

Nur mal so in den Raum gestellt: Braucht der Artikel überhaupt einen derartigen Absatz? Andere Programmiersprachen-Artikel kommen ja auch wunderbar ohne so eine Liste aus. Außerdem glaube ich kaum, dass man so etwas neutral formulieren kann. Was der eine als Vorteil sieht, ist für den anderen ein Nachteil. Man sollte so etwas lieber versuchen in ganzen Sätzen zu formulieren, so dass man auch die Folgen und den Zusammenhang der einzelnen Punkte beschreiben kann. --Kingruedi 22:54, 13. Aug 2006 (CEST)

Es gab dazu bereits eine ausführliche Diskussion auf der Qualtitässicherungs-Seite, siehe Link oben. Das von dir beschriebenen Problem lässt sich einfach dadurch lösen, das konsequent nur noch mit Quellen gearbeitet wird, und keine unbegelegten Einschätzungen mehr in den Artikel fließen. Gibt es in der Wissenschaft unterschiedliche publizierte Ansichten zu einem Punkt, so passt es unter "Kontroversen" ganz gut, denke ich. --Revvar (D RT) 09:39, 14. Aug 2006 (CEST)

Das man Quellen benutzt ändert ja nichts daran, dass eine Listenform vollkommen unausgereift ist um dieses Thema zu behandeln. Außerdem sind Quellen entweder auch unbelegbare Einschätzungen oder die Quellen werden zu stark interpretiert. Der aktuelle Vorschlag ist doch ein ideales Beispiel. So wird in einer Quelle gesagt, dass man Templates auch auf Linker-Ebene berücksichtigen muss und schon heißt es, dass aktuelle Compilertechniken nicht mehr für C++ ausreichen würden. Ich finde das Vorgehen sehr sehr fragwürdig und kaum hilfreich. Warum löschen wir die Liste nicht einfach raus und wenn jemand es für nötig hält, die Stärken und Schwächen von C++ aufzuführen, soll er einen zusammenhängenden Text schreiben (wobei dieser natürlich auch mit Quellen belegt sein sollte). --Kingruedi 14:47, 14. Aug 2006 (CEST)

Ich sehe das auch so. Lieber ein Loch als so eine halbwahre Sammlung. igel +- 15:06, 14. Aug 2006 (CEST)

Wenn es nach mir geht, wäre der Abschnitt seit langem raus. Dannach können wir die Punkte die klar belegt - natürlich nicht interpretiert - sind, einzeln wieder reinnehmen. Nur würde dies an der Diskussion hier nichts ändern. Wie ich Brf verstanden habe, ist die Liste oben nur ein Arbeitsvorschlag, bei dem er selbst zugibt das er für eine Reihe der Punkte noch keine Quellen hat. Auf der QS war ich ziemlich alleine für Löschen und dann Belegen, wenn sich hier eine Mehrheit findet - gerne. --Revvar (D RT) 18:45, 14. Aug 2006 (CEST)

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

Warum sollten wir dann eine neue Liste reinsetzen, wenn alle dies als schlecht ansehen? --Kingruedi 20:03, 14. Aug 2006 (CEST)

Ich weiß nicht, wie du darauf kommst, dass wir eine neue Liste da reinsetzen sollen. Natürlich nicht. Vielmehr die jetzige Listenform in Fließtext umwandeln. --Poldi 20:17, 14. Aug 2006 (CEST)

Nur wer setzt sich da dran? Sollten wir die aktuelle Liste nicht rausnehmen, auch wenn noch kein Ersatz vorhanden ist? (Genauso wie die Infobox) --Kingruedi 17:50, 15. Aug 2006 (CEST)

Wer hat denn bisher immer daran gearbeitet? :-) Ich glaube, außer von dir oder mir geht hier keine substanzielle Mitarbeit aus. ... Ich schau mal in den nächsten Tagen, was man daraus machen kann. Gebe dir noch bescheid. Schwere sachliche Fehler sind nicht drin, deswegen besteht kein akuter Handlungsbedarf. Bis bald. --Poldi 21:16, 15. Aug 2006 (CEST)

Was auch immer ihr vorhabt, Liste oder Fließtext - das ist das letzte Problem was es so lösen gilt. Es geht erstmal um Quellenbelege für all die aufgestellten Behauptungen - auch wenn ihr sie für trivial haltet. Das hat Brf als Einziger bisher in Angriff genommen, während alle anderen nur diskutiert haben. Leider ist er momentan aber im Urlaub. Also wenn ihr Zeit habt und was machen wollt, dann versucht die Punkte oben zu belegen, korrigieren oder als unbelegt zu markieren. --Revvar (D RT) 08:06, 16. Aug 2006 (CEST)

Überarbeitung

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

Weblinks

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

toter Link: Oft gestellte Fragen und Antworten, englisch
keine Diskussionsforen: C++-Diskussionsgruppe, deutsch
keine Unterbegriffe: Die C++-Bibliothek von Boost
keine Unterbegriffe: Hans Boehms Garbage-Collector für C++, englisch
Qualtiät - der Artikel ist bereits ausführlicher als dieser: C++ im Deutschen Software Entwickler Wiki
zu schlechte Qualität, da veraltet und unvollständig: Gegenüberstellung der bekanntesten Compiler, englisch
keine Foren: Größte Community-Seite in Deutschland zu C++

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

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

Einrichtung einer Meta-Seite

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

Hello World

Letzter Kommentar: vor 17 Jahren9 Kommentare6 Personen sind an der Diskussion beteiligt

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

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

gcc 4.1.0 gibt auch mit -W -Wall keine Warnungen aus.--Gunther 18:46, 4. Sep 2006 (CEST)

Und was ist mit dem undefinierten Verhalten des Programmes? Oder macht der Compiler dann "nix" und nimmt dann als Rückgabewert den zufällig zuletzt in eax geschobenen Wert? Warum wurde nicht einfach ein stinknormales HelloWorld-Programm genommen, so wie man es in Büchern findet?

Ob du es gutfindest oder nicht, dass man bei main() die return-Anweisung weglassen kann, ist nicht Gegenstand dieses Artikels. Der Standard erlaubt es, aus welchen Gründen auch immer. Und wenn dein Compiler eine fehlende return-Anweisung anprangert, ist er kaputt und du solltest einen anderen Compiler nehmen. --RokerHRO 19:24, 4. Sep 2006 (CEST)

Quetsch* - muss ja nicht kaputt sein, ich wage zu vermuten, es ist ein C90-Compiler, der motzt da ganz zurecht. igel +- 09:42, 16. Feb. 2007 (CET)Beantworten

Naja, einen C-Compiler auf ein C++-Programm loszulassen, ist keine gute Idee. Veraltet ist er eh. --RokerHRO 12:35, 16. Feb. 2007 (CET)Beantworten

Was du denkst, ist nicht Sinn dieser Diskussionsseite. Wo steht das denn mit dem Standard? Ich finde im Internet nur vage Definitionen vonwegen "eigentlich gehört das so, aber es hat sich soundso eingebürgert". Und selbst wenn, ist es didaktisch äußerst fragwürdig (s.o. "Und was ist mit dem undefinierten Verhalten des Programmes?")

Nix undefiniert. Wenn da nichts steht, macht der Compiler automatisch das Äquivalent von "return 0", siehe z.B. hier.--Gunther 19:37, 4. Sep 2006 (CEST)

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

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

Während man noch darüber diskutieren mag, ob man einen kompletten Namespace importieren sollte (bei großen Projekten würde ich davon dringend abraten), ist "\n" schlichtweg falsch. Zeilenende ist plattformabhängig, und kann "\r" oder "\n" oder "\r\n" oder "\n\r" oder "\nfoobar\n" sein. Darum gibt es std::endl. Meines Wissens ist nicht einmal definiert, ob cout überhaupt zeilengepuffert oder evtl. auch vollgepuffert ist... DevSolar 16:06, 15. Feb. 2007 (CET)Beantworten

std:endl ist laut Standard genau dadurch definiert, dass es ein "\n" (genauer: std::basic_ios<...>::widen('\n')) auf dem Ausgabestrom ausgibt und danach einen flush() ausführt (BS ISO/IEC 14882: 2003, 27.6.2.7). Eine konkrete Implementierung eines Ausgabestroms soll dieses Zeichen bei der Ausgabe geeignet umsetzen. Die Verwendung von "\n" ist schon so richtig. (Der Standard definiert übrigens keinerlei Zuordnung von Character-Literalen zu ASCII-Zeichen, d.h. es ist implementierungsabhängig, ob '\n' tatsächlich den Wert des "Line Feed"-Steuerzeichens in ASCII kodiert. Es kann aber sein, dass das z.B. im POSIX-Standard explizit gefordert wird.) —Tobias Bergemann 16:46, 15. Feb. 2007 (CET)Beantworten

Man lernt nie aus. Danke! DevSolar 16:07, 16. Feb. 2007 (CET)Beantworten

Vor allem gibt es ja nicht nur ASCII-Kodierung. Auf EBCDIC-Maschinen wird man die Kodierung des Zeilenvorschubs mit hoher Wahrscheinlichkeit als 0x15 vorfinden. --Poldi 17:18, 15. Feb. 2007 (CET)Beantworten

Ganz richtig. (Wobei EBCDIC im Gegensatz zu ASCII tatsächlich ein "echtes" Newline-Steuerzeichen enthält, ASCII aber eben nur ein "Line Feed"- und ein "Carriage Return"-Steuerzeichen.) Der Vollständikeit halber möchte ich meine obige Bemerkung noch dahingehend ergänzen/abschwächen, dass die Umsetzung von "\n" in einen Zeilenumbruch (oder eventuell bei exotischeren Systemen in einen Record-Abschluss) durch die Implementierung natürlich nur im Textmodus durchgeführt werden sollte, nicht aber im Binärmodus. Aber dann ist sowieso (fast) alles implementierungsabhängig. — Tobias Bergemann 09:10, 16. Feb. 2007 (CET)Beantworten

iostream

iostream oder iostrem.h ? Ichrag, weil jemand ohne zufragen geändert hat.--A-4-E 17:14, 21. Mai 2007 (CEST)Beantworten

iostream. Wie alle Header der Standardlibrary ohne .h. --RokerHRO 19:02, 21. Mai 2007 (CEST)Beantworten

Vorteile/Nachteile

Letzter Kommentar: vor 18 Jahren12 Kommentare6 Personen sind an der Diskussion beteiligt

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

Einerseits ist die Listenform nicht ideal, da aber inhaltlich bislang keine Bedenken geäußert wurden, halte ich ein Entfernen für übertrieben. Bei der inhaltlich ohnehin schwachen Beteiligung an diesem Artikel wäre das eher kontraproduktiv. Eine Überarbeitung war ja auch für Ende des Jahres angekündigt. Ich schlage vor, so lange warten wir noch.

Inhaltlich sollte bei den Nachteilen und dort bei den C-Altlasten der Präprozessor rausgenommen werden. Es gibt zwar in manchen Bereichen einige Möglichkeiten, auf den Präprozessor zu verzichten, aber bei #include wird es schon eng. Insofern keine Altlast, sondern notwendig. Auch die Auswertungsreihenfolge von Teilausdrücken ist keine Altlast, hätte ja in C++ festgelegt werden können. --Nid

Gerade für #include gäbe es hervorragenden Ersatz. Ich rechne damit, dass eine der nächsten Revisionen von C++ über einen Ersatz für #include verfügen wird. Wenn du die Auswertungsreihenfolge änderst, änderst du leider u.U. auch die Bedeutung bestehender Programme. --Poldi 16:38, 1. Nov. 2006 (CET)Beantworten

Da es bisher keine Verarbeitungsreihenfolge gibt, konnte sie auch niemand in einem Programm ausnutzen, sprich: Man musste darauf achten, dass die Reihenfolge keine Rolle spielt. Diese Programme laufen dann auch bei einem Compiler mit festgelegter Reihenfolge. Insofern wäre da keine Abwärtskompatibilität verloren gegangen, wenn C++ da "verbessert" worden wäre. Zu include: Natürlich gäbe es andere Möglichkeiten, die vielleicht auch irgendwann in die Sprache einfließen, aber bisher ist #include die einzige Möglichkeit und daher keine Altlast. Es gäbe ja auch für syntaktisch explizite Zeiger andere Möglichkeiten, die in die Sprache eingebaut werden könnten (siehe Java), demnach wären die auch eine Altlast von C. --Nid

Doch, es gibt eine Verarbeitungsreihenfolge. Sie ist nur eben abhängig vom Compiler, und die Compilerhersteller haben angedroht, sie wollen nicht mitziehen, wenn das Standardisierungskomitee an ihnen vorbei beschließen sollte, die Verarbeitungsreihenfolge vorzuschreiben. Dabei berufen sie sich darauf, dass ihnen bei der Entstehung von Inkompatibilitäten (und die entstehen tatsächlich, wenn man die Verarbeitungsreihenfolge ändert) die Kunden abspringen würden.

Zu include: Selbst wenn man heute einen Ersatz einführen würde, hätte man noch über jahrzehnte mit Quelltexten zu tun, die #include verwenden. Dass es diesen Ersatz noch nicht gibt, macht es nicht besser. Und #include ist ja nur ein Teil des Präprozessors. --Poldi 19:22, 18. Nov. 2006 (CET)Beantworten

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

Bei dem Buch scheint es sich dann ja eher um eine Urheberrechtsverletzung zu handeln. Ich kenne das Buch nicht. Aber kontaktiere doch mal den Autor, das er sein Werk auch unter die GFDL stellen muss, wenn er von hier kopiert. In etwa wie http://www.gpl-violations.org/

Aber eine zirkuläre Quelle bringt natürlich nichts. Sonst kann ich in die Wikipedia ja auch jeden Blödsinn schreiben, warten bis einer der zahlreichen Wikipedia-Kopierer den Artikel auch in der Form Online hat und das als Quelle angeben. Aber gut, warten wir mal bis zum Ende des Jahres. --Kingruedi 18:27, 22. Okt. 2006 (CEST)Beantworten

Ja, mit den zirkulären Quellen müssen wir aufpassen. Einzig die erwähnte Prüfung durch den "Fachgutachter" bringt uns hier weiter. Und damit ist dieser Artikel der erste geprüfte Artikel der Wikipedia, und das wurde erst durch eine (mutmaßliche!) Urheberrechtsverletzung an unserem Material ermöglicht. ;-)

Es ist übrigens nicht das erste Mal, dass andere Werke sich aus diesem Artikel bedienen. Vor etwa ein oder zwei Monaten standen Teile daraus in einer sehr renommierten deutschen Fachzeitschrift, ebenfalls ohne Quellenangabe. Immerhin scheint sich mittlerweile herumgesprochen zu haben, wo im Internet man sich mit brauchbaren Informationen eindecken kann. --Poldi 19:44, 22. Okt. 2006 (CEST)Beantworten

Wenn niemand was dagegen hat, würde ich folgende Punkte entfernen:

Die aktuellen Compiler (Stand: 2005) sind rückständig bezüglich der Umsetzung der ISO-Norm.
Die aktuellen Compiler produzieren nicht immer optimalen Code, sowohl in Bezug auf Geschwindigkeit als auch auf Code-Größe.

Grund: Das hat eigentlich nichts mit der Programmiersprache zu tun, sondern mit ihrer derzeitigen Umsetzung in der Praxis --GiordanoBruno 18:49, 13. Nov. 2006 (CET)Beantworten

Die Umsetzung der Sprache stellt den Bezug zur Nutzung und der eigentlichen sprachlichen Realität her. Was nutzt die ISO-Norm, wenn sich keiner dran hält? Dieser kleine Abschnitt erwähnt wenigstens, dass es eben nicht ganz so einfach in der Umsetzung ist. Deshalb würde ich diesen Abschnitt vorerst beibehalten.
--Freak1.5 11:41, 15. Nov. 2006 (CET)Beantworten

Sorry, aber es geht hier im die Sprache C++ und nicht um Compiler. Am liebsten würde ich die Compiler-Aufzählungen und somit die Vor-/Nachteile entfernen. Wenn Du diese Dinge aber trotzdem drin haben willst, mußt du trotzdem fair bleiben und zumindest die schlechten Compiler benennen. Sonst kann jeder kommen und sagen das ist schlecht, aber welcher Compiler sage ich nicht. Mir ist so auch kein Compiler mehr bekannt, der sich nicht mehr 99% an den ISO-C++ hält. GCC, Intel und MSVC sind die meistgenutzten Compiler. Diese sind durchweg sehr gut, in allen Belangen. Wenn es ein paar Ausreisser gibt (Digital Mars C/C++ Compiler?) muß man diese beim Namen nennen. Aber prinzipiell die C++ Compiler als schlecht darzustellen (was in dem Artikel so rüber kommt, für jemand der C++ nicht kennt) ist nicht richtig.Amin K 14:50, 4. Dez. 2006 (CET)Beantworten

Ich stimme dir zwar nicht zu, lasse den Artikel so wie er ist. --GiordanoBruno 13:13, 15. Nov. 2006 (CET)Beantworten

Bezüglich Die aktuellen Compiler (Stand: 2005) sind rückständig bezüglich der Umsetzung der ISO-Norm. und Die aktuellen Compiler produzieren nicht immer optimalen Code, sowohl in Bezug auf Geschwindigkeit als auch auf Code-Größe.: Beides ist richtig, deshalb nehme ich es zunächst wieder rein. Sicher könnte man dazu aber noch mehr Details anführen. --Poldi 15:57, 9. Dez. 2006 (CET)Beantworten

Habe die Nachteile wieder entfernt. Warum? Weil sich zweiter angeblicher Nachteil mit dem Vorteil "Die Erzeugung hocheffizienten Codes ist möglich. " beisst. Was nun? Kann man nun guten Runtimecode erzeugen? Oder sind die meisten schlecht? Dann muß der Vorteil raus! Std-Konformität: Welche der vielen Compiler sind denn so stark ISO-Unkonform? Nur weil praktisch kein Compiler export unterstützt? Dann wird dieser Nachteil für das Rest der Menschheitsgeschichte ein Nachteil sein, weil KEIN Compiler-Hersteller laut C++ Komitee dieses Feature aus Kostengründen implementieren wird. Es ist sozusagen de-fakto-Standard das export nicht unterstützt wird. Comenue ist ein Frontend-Compiler, d.h. er arbeitet nicht mal ohne Backend-Compiler (Intel, G++, MSVC usw.), deshalb ist es schon fast unfair Comenue als vollwertigen Compiler zu bezeichnen. Hier gibt es sehr viel Unstimmigkeiten. Wenn man das fehlende export als Nachteil aufführt, kann man ISO-C++ gleich als Bankrotterklärung nennen. 62.226.198.114 19:01, 10. Dez. 2006 (CET)Beantworten

Edit-War: Deutsches Wikibook zu C++

Letzter Kommentar: vor 18 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt

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

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

Ich kann da nur die Kontrastimme von Kadeck finden. Unter einer ausführlichen Diskussion mit Abwägen von Für und Wider stelle ich mir ein wenig mehr vor. z.B. konkrete Beispiele, wo das dt. Wikibook schlechter als das engl. ist. Doch anstatt diese hier aufzuzählen, wärs vielleicht sinnvoller, sie einfach an Ort und Stelle zu fixen, meinst du nicht? --RokerHRO 11:29, 30. Nov. 2006 (CET)Beantworten

Inklusive der Diskussion damals sind gegen den Link:

dafür sind:

Die Argumente der Gegener waren: Buch ist noch zu schlecht und widerspricht damit WP:WEB, der Befürworter: Buch ist bereits gut genug, und verdient als Schwesterprojekt unsere Unterstützung, insbesondere die Vermittlung von Autoren. 60% dafür sind eine gute Mehrheit, also rein den Link. --Revvar (D RT) 13:16, 30. Nov. 2006 (CET)Beantworten

Hallo RokerHRO, die im Artikel angegebenen Links sollen erstklassig sein. Davon können wir auch bei Wikibooks keine Ausnahme machen. Das gleiche gilt für "Werbung für ein Projekt". Grundsätzlich gilt, dass Qualität erst vorhanden sein muss, bevor darauf verlinkt wird, nicht umgekehrt. Um dennoch auf das Schwesterprojekt aufmerksam zu machen, könnte man einen Hinweis in der Fachredaktion hinterlassen, oder auch an prominenter Stelle hier auf der Diskussionsseite. Gruß Poldi 19:32, 2. Dez. 2006 (CET)Beantworten

Diskussion:C++/Archiv/1

- 2004 -

Fehler im Artikel?

Stärken und Schwächen

Unauffindbar unter "C++"

Weblinks

"Sehr Vollständigkeit" und Kompetenzen...

Ich zweifle über ...

- 2005 -

g++ (directory.fsf.org) vs. g++ (gcc.gnu.org)

Buchliste

"Schrott-Entfernung"

Geplante Erweiterungen der Programmiersprache C++

Stärken und Schwächen von C++

Hallo-Welt-Programm

Literatur (Wollenschein)

Programmierkurs

Änderungen vom 22.4.2005

Änderungen vom 29.4.2005

Stärken und Schwächen

Schwächen/Fehlende Bibliotheken

Falscher Titel. In fr-Wikipedia klappt es!

Templates

weiteres Vorgehen

Was der Artikel braucht ...

Was der Artikel nicht braucht ...

Templates vs. generische Datentypen

Rechtschreibung

const

Unglückliche Formulierung

Metatexte im Artikel

Mehr Sorgfalt bei der Recherche

- 2006 -

Metaprogrammierung?

Compiler: Dev-C++ oder MinGW noch in die Liste?

Ähnliche Syntax

Abschnitt: Vergleich mit anderen Sprachen

Revert der Rückstellung

Zusammenfassung der Diskussion zum Abschnitt "Vergleich mit anderen Sprachen"

Einleitung

Einführung der Vergleichssprachen

Vergleich

Variante-Alt

Variante-Neu-1

Kommentare zur Zusammenfassung

Zum Thema: Byte-Code, Zwischencode, Maschinencode:

Annotations

Zum Punkt "Verwendung objektorientierter Techniken in C++", sowie deren Ersatz durch Generik

Hinweis auf notwendiges return aus main in C

Diskussion bis Einigung

Titel des zu bearbeitenden Abschnitts

Sprachenvergleich: Tabelle statt Fließtext

Das deutschsprachige Wikibook

Verschlimmbesserungen

weiterer Senf

Senf zurück

Templates-Kritik 2

C99

Template

Polymorphie ist das Kernkonzept der OOP

OO und Friends

Ergänzende Hinweise zum Thema "Friends"

Merkmale der Sprache

Vorschlag

Merkmale

Ausgangspunkt

Ziele

Eigenschaften

Kontroversen

Vorschlag Ende

Compiler

Turbo C++, Sun Studio, IBM XL C/C++

Alphabetische Reihenfolge

>> vs. > >

Vorschlag Ende

Kommentare dazu

Überarbeitung

Weblinks

Einrichtung einer Meta-Seite

Hello World