Zum Inhalt springen

Diskussion:C++

Seiteninhalte werden in anderen Sprachen nicht unterstützt.
aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 14. April 2007 um 21:15 Uhr durch Revvar (Diskussion | Beiträge) (Revert auf Version von Benutzer:Kingruedi (2007-04-14T20:38:56). Grund: lol, na da bin ich mal gespannt.). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Letzter Kommentar: vor 18 Jahren von Kingruedi in Abschnitt Konformität von MSVC++

Vorlage:Keine Auskunft

Archiv

Wie wird ein Archiv angelegt?

weiteres Vorgehen

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

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

Was der Artikel braucht ...

Was der Artikel nicht braucht ...

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

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

Merkmale der Sprache

(kopiert von der Qualitätssicherungsseite:)

Vorschlag

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

Merkmale

Ausgangspunkt

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

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

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

Ziele

C++ folgt den nachstehenden Paradigmen der Programmierung:

Siehe auch: Programmierparadigma, Entwurfsmuster, RAII, Metaprogrammierung

Eigenschaften

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

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

  • 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 [[5]], Benchmarkergebnisse für GCC u.a. bei [[6]], siehe summarized results)
  • Für effiziente Compiler reichen die Standardtechniken des Compilerbaus nicht mehr aus.
  • C++ ist schwerer zu erlernen und benötigt viel Prgrammiererfahrung, um gute Programme zu produzieren.
Vorschlag Ende

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

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

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

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

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

Belege

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

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

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

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

Kommentare dazu

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

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

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

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

Tabellarische Sprachvergleiche sind in

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

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

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

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

http://gcc.gnu.org/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)

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

--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 18 Jahren7 Kommentare5 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)
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

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: [7]. --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:
  1. Benutzer:Poldi
  2. Benutzer:Blakeks
  3. Benutzer:Kadeck
  4. Benutzer:DocSnyder
dafür sind:
  1. Benutzer:Jonathan Hornung
  2. Benutzer:Thomaswm
  3. Benutzer:SehLax
  4. Benutzer:Jwnabd
  5. Benutzer:RokerHRO
  6. Benutzer:Revvar
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

Compiler

Letzter Kommentar: vor 18 Jahren23 Kommentare4 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

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

Gelöschter Absatz?

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

Was ist mit diesem Absatz, der hier von einer IP kommentarlos entfernt wurde und - nachdem die anderen Verschlimmbesserungen dieser IP wieder revertiert wurden, nicht wieder eingefügt worden ist?

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

--RokerHRO 07:52, 5. Jan. 2007 (CET)Beantworten

der Absatz ist noch drinnen, nur weiter unten --217.232.75.179 21:08, 5. Jan. 2007 (CET)Beantworten

>> und > > (Fortsetzung)

Letzter Kommentar: vor 18 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Zur Erläuterung ein Zitat aus dem Abschnitt "Implementation Conformance" des Standards (ISO/IEC 14882:2003, 1.4.8): A conforming implementation may have extensions [...] provided they do not alter the behavior of any well-formed program. --Poldi 19:02, 16. Jan. 2007 (CET)Beantworten

Merkmale der Sprache (Fortsetzung)

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

Ich greife noch mal meinen Vorschlag "http://de.wikipedia.org/wiki/Diskussion:C%2B%2B#Merkmale_der_Sprache" von oben auf. Ich halte ihn nach wie vor für bedenkenswert.

Die pov/npov-Diskussion in der de Wikipedia allgemein, auch auch in diesem Artikel läuft oft darauf hinaus, dass auch korrekte Wertungen einfach unterdrückt werden, bloß weil es Wertungen sind. Das finde ich nicht wirklich in Ordnung. In diesem Artikel betrifft das die Mängel der Sprache, die vorhanden sind.

Die Pflicht zu Belegen sehe ich ein. Ich fand es im August 2006 überraschend schwer, wirklich gute Compilervergleiche im Netz zu finden. Leider wurden ad hoc angestellte Messungen abgelehnt.

Mittlerweile (damals gab es das noch nicht) habe ich ein wirklich unverdächtiges Dokument gefunden: ISO/IEC TR 18015:2006-09-01, Technical Report on C++ Performance. Hier werden vor allem in Kapitel 5 alle vorhandenen Probleme in C++ auf Zeit- und Speicherprobleme zusammengestellt und auch Lösungen diskutiert.

Siehe speziell: 5.3 Classes and Inheritance (vitual function, multiple inheritance...), 5.5. Templates, 5.6 Programmer Directed Optimizations

Soweit ich weiß, ist C++ die einzige Sprache, bei der ein solches Dokument überhaupt existiert.

Ich zitiere aus der Intorduction:

“Performance” has many aspects – execution speed, code size, data size, and memory footprint at run-time, or time and space consumed by the edit/compile/link process. It could even refer to the time necessary to find and fix code defects. Most people are primarily concerned with execution speed, although program footprint and memory usage can be critical for small embedded systems where the program is stored in ROM, or where ROM and RAM are combined on a single chip. Efficiency has been a major design goal for C++ from the beginning, as has the principle of “zero overhead” for any feature that is not used in a program. It has been a guiding principle from the earliest days of C++ that “you don’t pay for what you don’t use”. Language features that are never used in a program should not have a cost in extra code size, memory size, or run-time. If there are places where C++ cannot guarantee zero overhead for unused features, this Technical Report will attempt to document them. It will also discuss ways in which compiler writers, library vendors, and programmers can minimize or eliminate performance penalties, and will discuss the trade-offs among different methods of implementation.

Etwas verklausuliert steht da natürlich, dass c++ solche Stellen enthält. --Brf 10:24, 9. Feb. 2007 (CET)

  • Die pov/npov-Diskussion in der de Wikipedia allgemein, auch auch in diesem Artikel läuft oft darauf hinaus, dass auch korrekte Wertungen einfach unterdrückt werden, bloß weil es Wertungen sind. Das finde ich nicht wirklich in Ordnung. In diesem Artikel betrifft das die Mängel der Sprache, die vorhanden sind. — Dem stimme ich zu. Dass man keine Wertungen abgeben dürfe, ist ein auf diesen Servern verbreitetes Missverständnis, und selbstverständlich darf man auch Vergleiche anstellen. Es soll nur eben nachvollziehbar und von Fakten getragen sein, was aber bei technischen Themen eher unproblematisch ist. Schwieriger ist es hingegen bei weltanschaulichen oder politischen Themen, vor deren Hintergrund wohl die Wikipedia-Neutralitäts-Diskussionen entstanden sind.
  • Ich kenne den Performance-Report und halte ihn für eine gute Grundlage. Das meiste davon ist aber nicht wirklich überraschend. Was davon findest du denn bemerkenswert und eventuell interessant für diesen Artikel?

--Poldi 21:21, 9. Feb. 2007 (CET)Beantworten

Kurzer Einwurf, da ich mich irgendwie angesprochen fühle ;-) : Wertungen sind kein Problem, solange diese durch akzeptable und unabhängige Quellen belegt sind, eigene Experimente hingegen sind hier verständlicherweise wertlos. --Revvar (D Tools) 00:33, 10. Feb. 2007 (CET)Beantworten

Ich kenne die Sprache seit etwa 1987 und habe alle ihre Entwicklungswindungen relativ genau verfolgt. Für mich ist der Inhalt überhaupt nicht bemerkenswert oder überraschend. Aber wenn man die C++-Diskussionen hier verfolgt, gilt das für die C++-Fans, die jede für c++ negativ ausgehende Wertung als not political correct bewerten. Überraschenderweise nicht bei Deschner, sondern bei einem technischen Thema. Um Zitate war ich im Sommer (das war für mich eher überraschend) plötzlich verlegen, was an den neuesten Entwicklungen im Internet liegt. Wo früher jemand, der Sprachvergleiche angestellt hat, die Ergebnisse im Internet veröffentlich hätte, sind die heut weggesperrt, kostenpflichtig oder wie ganz früher nur durch Bibliotheksrecherchen zu finden. Das ist das Resultat der Kommerzialisierung des Internet, aber auch der Universitäten. Wer was macht will dafür Geld sehen.

Mit nicht großzügigem Zeitpolster ausgestattet, kann ich eine wirklich aufwendige Recherche nicht leisten. Vor allem nicht, wenn eigentlich eher Sachen zu beweisen sind, die jeder Kenner des Themas weiß. Und naja - ich seh diesen Punkt ja ein, aber auch eine eigene Messung zählt nicht als Beweis. Eine aufwendige Messung mit Veröffentlichung ist aber nicht meine Aufgabe. --Brf 08:27, 12. Feb. 2007 (CET)

Ich halte die Recherche zwar für sinnvoll, würde sie aber auch nicht überbewerten. Es gibt Redaktionen, die dabei arbeitsteilig vorgehen, beispielsweise in der Form, dass einer Artikel schreibt, und ein anderer anschließend die Stichhaltigkeit überprüft. Vielleicht können wir hier ähnlich vorgehen. --Poldi 22:44, 12. Feb. 2007 (CET)Beantworten

Werter Zweitaccount (von wem auch immer), dass bisher die Recherche "nicht überbewertet" wurde, ist leider deutlich am Artikel zu erkennen. Der Artikel verstößt mindestens zu 50% gegen den NPOV-Grundsatz - es ist ein Fanartikel, nicht mehr nicht weniger. Für mich hatte es bisher wenig Priorität deshalb Zeit zu investieren, aber ich möchte die Warnung aussprechen bevor sich Nutzer beschweren: Ich werde in Zukunft mal Zeit finden, und hier alles rauswerfen was wertend und unbelegt ist. Genug Warnungen, Diskussionen und Vorankündigungen dazu gab es ja schon. Brf hat die Situation schon richtig dargestellt. --Revvar (D Tools) 23:02, 12. Feb. 2007 (CET)Beantworten

Sinn oder Unsinn von Sprachvergleichen

Vergleiche von Programmiersprachen halte ich generell für wenig sinnvoll, wenn sie versuchen, irgend eine Sprache als "Sieger" zu küren oder für Aussagen "X ist besser als Y" herangezogen werden sollen. Es ist IMHO sinnvoller, die einzelnen Sprachen möglichst wertfrei gegenüberzustellen und dann dem Leser die Antwort zu überlassen, welche Programmiersprache für sein Problem und unter den für ihn geltenden Randbedingungen (Plattform, Ressourcen, Lernaufwand usw.) am geeignetsten ist.
Solche Vergleiche sollten ganz einfach so neutral wie irgend möglich und am besten von Leuten, die weder Fan noch Gegner der Sprache sind, geschrieben oder zumindest korrekturgelesen werden. Sonst ist die Gefahr einfach zu groß, dass der "Vergleich" wieder in Werbung oder Antiwerbung für die eine oder andere Sprache ausfällt. --RokerHRO 11:17, 13. Feb. 2007 (CET)Beantworten

Konformität von MSVC++

Letzter Kommentar: vor 18 Jahren21 Kommentare4 Personen sind an der Diskussion beteiligt

Der letzte Satz des folgenden Absatz irritiert mich:

"Microsoft Visual C++ von Microsoft ist der verbreitetste Compiler unter dem Betriebssystem Windows und damit einer der bekanntesten und einflussreichsten Compiler überhaupt. Seit der Version 7.1 gilt er als besonders sprachkonform."

Wer behauptet, dass er "besonders sprachkonform" sei? Dieser Ausdruck ist undeutlich und irreführend. Mit meinem Verständnis von "besonders konform" ist der Satz sogar falsch. Ich habe letztens versucht, ein Projekt auf die Version 8.1 des Compilers zu portieren und wurde von einigen Dingen geplagt, in denen er einfach nicht konform ist. Beispiele wären:

  • using-Deklaration für Typen aus Basisklassen und Nutzung derer funktioniert nicht,
  • Funktionsblöcke können nicht durch try/catch-Blöcke ersetzt werden,
  • kaputtes SFINAE mit boost::enable_if_c und Trennung von Templatedeklaration und -definition,
  • einfache Deklarationen von statischen, konstanten, integralen Elementen in Klassen generieren ein Symbol und eine Definition derer generiert einen Fehler.

Ich schlage vor, die Konformität des Compilers anders zu umschreiben, wie in etwa: "in weitesten Teilen konform". Es soll weder der Eindruck enstehen, dieser Compiler sei sehr konform, noch dass er schlecht brauchbar wäre. Die oben genannten Fehler tangieren sicherlich nur die wenigsten Programmierer. Sefi 21:00, 25. Mär. 2007 (CEST)Beantworten

Was meinst du mit einfache Deklarationen von statischen, konstanten, integralen Elementen in Klassen generieren ein Symbol und eine Definition derer generiert einen Fehler? Könntest du ein Programmierbeispiel dazu geben? --Poldi 19:06, 26. Mär. 2007 (CEST)Beantworten
Gerne: "struct test { static const int i = 42; };" taucht in mehreren Übersetzungseinheiten auf und "const int test::i;" taucht nur in einer Übersetzungeinheit auf und generiert einen Mehrfachdefinitionsfehler. Bei gcc ist genau das Gegenteil der Fall, was standardkonform wäre. Sefi 19:52, 27. Mär. 2007 (CEST)Beantworten
Ok, so ist es klar. Die anderen Beschreibungen sind eigentlich auch nicht ganz klar. Ich bitte ebenfalls um Beispiele.
Besonders sprachkonform ist der VC++ im Vergleich zu seinen Vorgängern, außerdem im Vergleich zu Compilern anderer Hersteller. Vielleicht könnte sich die Formulierung daran orientieren, z.B. "seit Version 7.1 gilt er als einer der sprachkonformsten Compiler". --Poldi 18:57, 28. Mär. 2007 (CEST)Beantworten
Der Abschnitt über den MSVC wirkt imho nicht sehr NPOV. Ich habe bisher noch nicht gehört, dass der MSVC als "einer der sprachkonformsten Compiler" gilt. Für den Satz "und einflussreichsten Compiler überhaupt" hätte ich auch gerne einen Beleg. Ob er der "verbreitetste" ist weiß ich auch nicht. Das hört sich nach Spekulation an. --Kingruedi 21:02, 29. Mär. 2007 (CEST)Beantworten
Ts, ts, ihr immer mit eurem "NPOV" ;-) Ich sehe nicht, wo da die Neutralität berührt sein soll. Entweder es stimmt, oder es stimmt nicht. Ich glaube, dass du da einem Missverständnis bezüglich der Bedeutung von "Neutralität" erliegst. Es geht doch nicht um Politik oder Religion. Der Absatz ist möglicherweise falsch, aber er leidet nicht unter einem Neutralitätsproblem.
Der MSVC ist in der Tat mittlerweile ziemlich konform, und dafür gibt es auch handfeste Gründe. Das war nicht immer so, und anscheinend hat es sich einfach noch nicht überall rumgesprochen. Zwischen Version 7 und 8 hat sich aber noch einiges getan, sodass wir uns wohl besser auf Version 8 berufen. Ein paar Bugs sind aber noch drin. Die gibt es aber in jedem C++-Compiler. Im Vergleich dazu ist beispielsweise der Borland-Compiler relativ "unkonform". Dabei waren die Verhältnisse jahrelang umgekehrt. --Poldi 18:25, 30. Mär. 2007 (CEST)Beantworten
Neutralität wird zB da verletzt, wo man unhaltbare Aussagen benutzt. Was im Grunde auf fast alles zutrifft, was zum MSVC in dem Artikel steht. --Kingruedi 20:13, 30. Mär. 2007 (CEST)Beantworten
Das ist eben nicht die Definition für Neutralität. Aber gehen wir die Punkte einzeln durch. Ich fange mit dem letzten an:
  • Seit der Version 7.1 gilt er als besonders sprachkonform. --> Das ist richtig, wenn man es auf die Vorgängerversionen bezieht, ohne nähere Erläuterungen dazu aber wohl missverständlich. Sollten wir ändern.
  • und damit einer der bekanntesten und einflussreichsten Compiler überhaupt. --> Bekanntheit und Einfluss des Compilers werden also auf die Verbreitung zurückgeführt. Das ist zunächst einmal schlüssig. Ein stark verbreiteter Compiler ist selbstverständlich bekannt, und durch eine hohe Verbreitung hat ein Compiler ebenso selbstverständlich einen starken Einfluss auf die Realität der unterstützten Programmiersprache. Den Einfluss des MSVC kannst du beispielsweise an den Boost- und Loki-Bibliotheken ablesen, die schon seit der Version 6 spezielle Anpassungen nur zur Unterstützung dieses Compilers anbieten, oder am Borland-Compiler, der spezielle Spracherweiterungen nur zur Verbesserung der Kompatibilität mit MSVC bietet. Das nenne ich einen starken Einfluss. Ich würde den starken Einfluss nicht allein auf die Verbreitung zurückführen, unstrittig ist aber wohl der Einfluss an sich.
  • ist der verbreitetste Compiler unter dem Betriebssystem Windows --> Es wäre schön, das zu belegen. Die Abwandlung ist einer der verbreitetsten Compiler unter dem Betriebssystem Windows ist aber wohl vertretbar, und damit wäre die Gesamtaussage nicht gefährdet. --Poldi 23:02, 30. Mär. 2007 (CEST)Beantworten
Das war ja auch keine Definition.
Seit der Version 7.1 gilt er als besonders sprachkonform.
Nein, hier wird nicht der Unterschied zur Vorherigen Versionen betont, sondern eine allgemein besonders gute Sprachkonformität. Was aber offensichtlich nicht stimm.
und damit einer der bekanntesten und einflussreichsten Compiler überhaupt.
Das gilt aber für alle anderen Compiler, die Vorgestellt werden. Auch dafür gibt es spezielle Anpassungen in Boost und Loki. Also ist die Aussage sinnlos und sollte gestrichen werden.
Die Aussage gilt aber nicht für alle anderen vorgestellten Compiler, und selbst wenn, wäre die Aussage nicht falsch oder sinnlos. --Poldi 19:03, 12. Apr. 2007 (CEST)Beantworten
ist der verbreitetste Compiler unter dem Betriebssystem Windows
Mit der Abwandlung ist das in Ordnung--Kingruedi 00:18, 31. Mär. 2007 (CEST)Beantworten
Gut, aber welcher Compiler ist denn deiner Meinung nach der verbreitetste unter Windows? --Poldi 19:17, 2. Apr. 2007 (CEST)Beantworten
Das weiß ich nicht. Ich denke, dass der MSVC schon ziemlich weit verbreitet ist. Aber wir können den Artikel nicht auf unserem Glauben beruhen lassen --Kingruedi 03:38, 3. Apr. 2007 (CEST)Beantworten
Ich habe vor ein paar Jahren einmal gelesen, der MSVC sei der mit Abstand verbreitetste unter Windows.
Andere Sache: Woraus kann man auf die im Artikel erwähnte hohe Sprachkonformität des g++ seit der Version 4.1 schließen? --Poldi 19:11, 3. Apr. 2007 (CEST)Beantworten

@Sefi: Ich warte noch auf eine Antwort von dir. --Poldi 19:19, 2. Apr. 2007 (CEST)Beantworten

Zum Thema Neutralität

@Kingruedi: Auch nach deinen Erläuterungen wird nicht klar, inwieweit der Text die Neutralität verletzen soll. Du schreibst Neutralität wird zB da verletzt, wo man unhaltbare Aussagen benutzt., aber das kann man wohl so nicht sagen. Ich bin immer noch der Meinung, da liegt ein Missverständnis vor. Eine unhaltbare Aussage wäre zum Beispiel "2 + 2 = 5", aber die Aussage an sich ist neutral.
Wir hatten das Thema Neutralität schon einmal (s.o.), und meine damalige Einschätzung war, dass der Begriff eher auf politisch-weltanschauliche Artikel anwendbar ist. Bei technischen Themen kommen wir damit aber nicht weiter. Durch den bisherigen Diskussionsverlauf sehe ich mich bezüglich dieser Einschätzung bestätigt. --Poldi 19:30, 12. Apr. 2007 (CEST)Beantworten

Die Aussagen sind nicht haltbar. Deine Quelle ist vor ein paar Jahren mal gelesen. Das kannst du nicht ernst meinen. Die Neutralität wird verletzt, weil so in Direkt andere Compiler abgewertet werden (sind nicht etwas alle Compiler die Aufgezählt werden weit verbreitet, ich dachte das war ein Kriterium warum du einige Compiler gelöscht hast; Sind nicht alle Compiler die weit verbreitet sind etwa gleich einflussreich). --Kingruedi 22:51, 12. Apr. 2007 (CEST)Beantworten
Zitat aus Wikipedia:neutraler Standpunkt: Artikel, in denen ein oder mehrere Standpunkte nur ungenügend erklärt werden, lassen sich nicht dadurch neutraler gestalten, indem man den Gegenstandpunkt kürzt. Stattdessen ist darauf zu achten, den nur ungenau erklärten Standpunkt besser zu begründen und zu formulieren. – Und darum möchte ich dich bitten. --Poldi 17:43, 13. Apr. 2007 (CEST)Beantworten

Kinder, bitte streitet euch nicht. Habt ihr schon vergessen? WP:NPOV.

  • Comeau C++ kenn ich als Programmierer nicht, mein Freund auch nicht, sowie ein anderer ebenfalls nicht: Nicht wirklich populär.
  • g++ ist populär, und das auf allen Betriebssystemen. Weil sich hiermit viele IDEs an dem g++ bedienen können, ist er auch einfluss reich.
  • Microsoft Visual C++ gibts nur für Windows, ist closedsource. Jedoch ist er der verbeitester unter Windows.
  • Intel C++ Compiler ist populär, weil er effezient für Intel-Prozessoren compilen kann.

Wer was dagegen hat, soll bitte sprechen. --Petar Marjanovic ( Frag mich • Bewerte mich ) 18:18, 14. Apr. 2007 (CEST)Beantworten

Zum Thema Neutralität wurden schon Diskussionen geführt, z.Zt. läuft gerade eine (s.o.). Da wir nicht für jeden, der in das Thema neu einsteigt, bei null anfangen können, solltest du dir die vorangegangenen Diskussionen durchlesen, wenn du dich beteiligen möchtest. --Poldi 20:08, 14. Apr. 2007 (CEST)Beantworten
Deine Einschätzung zu den Compilern teile ich übrigens (abgesehen von der Begründung mit den IDEs beim g++). Die Bedeutung des Comeau-Compilers für die Realität der Programmiersprache C++ ist im Text übrigens nicht mit der allgemeinen Bekanntheit begründet, sondern mit der hohen Konformität. --Poldi 20:22, 14. Apr. 2007 (CEST)Beantworten
Comeau ist schon bekannt, weil er so konform ist. Aber zum Thema: Was du aus den Wikipedia-Richtlinien zitiert hast, trifft ja nicht wirklich zu. Ansonsten können wir gerne bei so etwas enden: http://de.wikipedia.org/w/index.php?title=C%2B%2B&oldid=30507531 Finde ich nicht sinnvoll. Aber wenn du so zwanghaft drauf bestehen willst: Meinetwegen --Kingruedi 20:38, 14. Apr. 2007 (CEST)Beantworten

Nebulöse Aussagen

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

Man betrachte diesen Absatz:

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, einen der fundamentalen Bestandteile der objektorientierten Programmierung.

das ist m.E. hochspekulativ, ich würde es Schwachsinn nennen. Seit wann und wieso sollte man bei C++ auf Polymorphie verzichten und das gar aus Performance-Gründen?! Was soll da an Java/C# anders oder gar performanter sein? Der Absatz klingt so, als hätte C++ Nachteile eben deswegen. Ich programmiere schon viele Jahre in der Praxis C++ (und kenne auch Java), aber eine solche beschriebene Tendenz ist mir noch nicht begegnet. --84.167.132.36 23:11, 29. Mär. 2007 (CEST)Beantworten

Polymorphie benötigt virtuelle Tabellen und verhindert viele Optimierungsmöglichkeiten (zB Inlining). Außerdem kommt es zu mehr Indirektionen. Templates dagegen werden in C++ zur Compile-Zeit aufgelöst. Meine Erfahrungen unterstützen die These. Schau dir modernen C++-Code an, wie man ihn zB bei Boost oder Loki findet. Vielleicht programmierst du ja einfach altes C++? ;) C#/Java haben sogar einen gewissen Vorteil, da sie zu einem anderen Zeitpunkt den Code optimieren. --Kingruedi 00:17, 30. Mär. 2007 (CEST)Beantworten
C#/Java haben sogar einen gewissen Vorteil, da sie zu einem anderen Zeitpunkt den Code optimieren. --> Das ist kein Privileg von C# oder Java, sondern in C++ grundsätzlich auch möglich. --Poldi 18:25, 30. Mär. 2007 (CEST)Beantworten
Der Performancenachteil von virtuellen Funktionen (also Methoden *G*) wird i.A. arg überschätzt. Ich habe Messungen angestellt, es fällt selbst bei kleinen Funktionen echt nicht ins Gewicht. Auch der vermeintliche Performancevorteil von Funktionsinlineing wird dagegen gerne überschätzt und es wird versucht, auch komplexere Funktionen zu inlinen, was den Code nur aufbläht aber kaum oder gar nicht schneller macht. Moderne CPUs mit Sprungvorhersage und Caches sind verdammt flott, was Funktionsaufrufe und Sprünge angeht. --RokerHRO 09:36, 30. Mär. 2007 (CEST)Beantworten
Performance ist ein kompliziertes Thema, eine einmalige Messung (noch dazu einer einzelnen Person ;-) ) sagt da recht wenig aus. Die Erfahrung zeigt, dass sich da zu leicht systematische Fehler einschleichen. Im Einzelfall kann sowohl Inlining als auch das Weglassen von Inlining einen Performancevorteil zeigen. Definitiv ein Vorteil ist es aber, die Wahl zwischen beiden Varianten zu haben, und den bieten nicht alle Programmiersprachen. --Poldi 18:25, 30. Mär. 2007 (CEST)Beantworten
@ 84.167.132.36: Wir bleiben freundlich, wenn wir hier diskutieren. Wenn du noch einmal hier ein Kraftwort wie "Schwachsinn" verwendest, werde ich deinen Diskussionsbeitrag kommentarlos löschen. Deine Äußerungen zeugen übrigens nicht von einem besonders tiefen Verständnis der Materie. --Poldi 18:25, 30. Mär. 2007 (CEST)Beantworten
So, auch wenn Du das wieder löschst: womit begründest Du deine Vermutung, meine Äußerungen würden nicht von besonders tiefem Verständnis der Materie zeugen? --217.95.166.138 16:21, 31. Mär. 2007 (CEST)Beantworten

Also noch ein Versuch zur inhaltlichen Diskussion: Der Ansatz, Polymorphie durch Templates zu ersetzen, ist mir auch bekannt - wird aber so in dem Absatz nicht erwähnt. Im Übrigen bedeutet dynamische Bindung, daß die Adresse in einer Tabelle nachgeschaut wird, bevor gesprungen wird, das ist ein einziger zusätzlicher Assembler-Befehl, das kann man gegenprüfen. Wo ist da der Performance-Nachteil? Den könnte man höchstens mit nicht-Inline-Möglichkeit begründen, aber das kostet auch kaum bzw. wird man kaum so kurze Funktionen inlinen, die man über dynamische Bindung benutzt. Und in C oder anderen Sprachen müßte man für einen solchen Aufruf sowieso Befehle investieren (switch...), das ist eher noch ineffizienter als dynamische Bindung. Und selbst wenn Java hier anders optimiert, wie oben behauptet, wie soll es denn zur Laufzeit gar hier besseren Code (d.h. inline!) generieren - kann es hellsehen? Ein Verzweigung über Template-Instantiierung erzeugt wesentlich mehr code, was noch problematischer ist als Inlining, Instruktions-Caches sind bei modernen Prozessoren zwar groß, aber immer noch begrenzt.

Fazit: wenn man nun mittlerweile bei der C++-Programmierung auf Polymorphie verzichten würde, was nimmt man den als Alternative? Das verrät der Absatz nicht. Ich finde die Aussage zudem Zweifelhaft, weil die genannten Alternativen schlechter sind. Wo sind die Quellen für eine solche Aussage? Das ergibt keinen Sinn, bei der OOP auf Polymorphie verzichten zu wollen. Und das es insgesamt eine solche Tendenz gibt, bezweifle ich. --217.95.166.138 16:21, 31. Mär. 2007 (CEST)Beantworten

Wie würdest du den Absatz formulieren? (Übrigens hätte es Vorteile, wenn du dich anmelden würdest.) --Poldi 19:17, 2. Apr. 2007 (CEST)Beantworten

Es ist ja richtig, dass manches durch Templates eleganter und performanter gelöst wird, wofür man früher zusätzliche Ableitungen benötigte. Das hat aber weniger mit den dafür benötigten virtuellen Funktionen als mit dem Speichermanagement zu tun, das man mit Templates sehr effizient durchführen kann. Z.B. wären die Container-Klassen der Standard Bibliotheken ohne Templates nicht möglich. In diesem Zusammenhang von Rückgang der Polymorphie zu sprechen ist doch etwas kühn. Polymorphie behält selbstverständlich ihre Berechtigung. Übrigens sind tiefe Klassenhierarchien sind in keiner objektorientierten Programmiersprache eine gute Idee. Ich würde also den Absatz herausnehmen. Thomas118 21:32, 11. Apr. 2007 (CEST)Beantworten

  • Dass Polymorphie ihre Berechtigung behält, wird nicht in Frage gestellt.
  • Dass tiefe Klassenhierarchien auch in anderen Sprachen problematisch sind, wird ebensowenig in Frage gestellt. Nur weil es für andere auch stimmt, ist es doch in diesem Fall nicht falsch.
  • Die Sache mit dem Speichermanagement musst du bitte näher erläutern. Inwiefern ergeben sich dadurch Performance-Vorteile? --Poldi 19:40, 12. Apr. 2007 (CEST)Beantworten

82 oder 83?

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

Zuerst steht im Text "1982 wurde C with Classes in C++ umbenannt." Einige Zeilen weiter steht "Der Name ist eine Wortschöpfung von Rick Mascitti und wurde zum ersten Mal im Dezember 1983 benutzt. Der Name kommt vom Inkrement-Operator „++“, der den Wert einer Variablen um eins erhöht." Was denn nun wurde der Name 1983 oder 82 erfunden? --Captain Guinness 14:56, 30. Mär. 2007 (CEST)Beantworten

... und wer ist überhaupt Rick Mascitti? Der Papagei von Stroustrup? Ich würde sagen, da fehlt eine Erläuterung. --Poldi 18:25, 30. Mär. 2007 (CEST)Beantworten
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Diskussion:C%2B%2B&oldid=30513852“