Von wem wird C++ weiter entwickelt ?

Phyton

Hallo, neulich guckte ich mir mal wieder das FAQ von bjarne stroustrup an .
Da kam mir die Frage auf,dass er zwar sicher auch c++ weiter entwickelt.
Aber das eine so große programmiersprache sicher schwer ist alleine weiter zu entwickeln.Deswegen ist meine Frage ob irgend ein Entwickler team oder Firma c++ weiter entwickelt.
Kann sein das dass ne dumme Frage ist, aber Google konnte mir diese Frage nicht beantworten.
Ich hoffe ihr könnt es
Wenn ich die Frage ins falsche thema gesendet hab bitte umändern.

Tobiking2

Da C++ ein ISO Standard ist, gibt es ein Komitee das über den Standard bestimmt: https://isocpp.org/std/the-committee

Yamahari

Bevor du solche Fragen stellst, solltest du vielleicht deine Fähigkeiten in der deutschen Sprache weiterentwickeln.

Phyton

Und du lernst vielleicht keine unnötigen antworten zu geben.

einerseits wird der Standard weiterentwickelt, dort wird vorgegeben was die Sprache so alles können muss.
Andererseits muss dieser Standard natürlich auch erst implementiert werden. Das tun die Compiler Hersteller. Da gibt es kommerzielle (z.B. MS C++ Compiler) aber auch Open Source (z.B. gnu Compiler) Varianten.

TNA

Jeder der möchte, kann einen Vorschlag (proposal) für Änderungen am C++ Standard einreichen. Das Komitee stimmt dann darüber ab.

Phyton

Hallo Leute warum müsssen dann solche komponenten wie sound und grafik mit externen libaries (wie z.b SFML) eingebunden werden und werden dann nicht einfach mit in die standard libary mit aufgenommen (nicht falsch verstehen ich fänd es nur cool wenn es so wäre)

Phyton schrieb:

Hallo Leute warum müsssen dann solche komponenten wie sound und grafik mit externen libaries (wie z.b SFML) eingebunden werden und werden dann nicht einfach mit in die standard libary mit aufgenommen

Ja welche sollen denn aufgenommen werden? SFML? Qt? Gnome? ...

Für jeden, der Feature xy im Standard sehen möchte, gibt es mindestens einem der sagt, der Standard sei völlig überladen.

Columbo

manni66 schrieb:

Für jeden, der Feature xy im Standard sehen möchte, gibt es mindestens einem der sagt, der Standard sei völlig überladen.

Das hat damit nichts zu tun. Und jeder, der behauptet, die Standardbibliothek sei überladen, ist ein Spinner und sollte sich mal Java anschauen.

Hallo Leute warum müsssen dann solche komponenten wie sound und grafik mit externen libaries (wie z.b SFML) eingebunden werden und werden dann nicht einfach mit in die standard libary mit aufgenommen

Eine simple 2D Graphics Lib die auf Cairo basiert wird gerade gedrafted. Es gibt auch Proposals für Netzwerk-Bibliotheken.

Die Standardbibliothek wird durchgehend erweitert, aber es ist extrem schwer, Bibliotheken zu designen, die sowohl generisch und abstrakt als auch effizient und intuitiv sind. Das wird entsprechend schwerer sobald der Maßstab steigt, weswegen nur Bibliotheken mit genügend Bedarf Autoren finden.

manni66 schrieb:

SFML? Qt? Gnome? ...

Nur eine davon ist eine reine rendering library

SeppJ

Was hätte man davon, diese Bibliotheken in den Standard aufzunehmen? Die Bibliotheken existieren doch sowieso schon; haben eigene, aktive Entwickler; und es hindert einen niemand daran, diese zu benutzen. Man sollte nicht dem Fehlschluss unterliegen, dass Bibliotheken von außerhalb des Sprachstandards irgendwie verbotenes Terrain wären.

Phyton

+Arcoth das heißt das leute sagen was sie gerne haben möchten und es dann in einem draft wie du erwähnt hast aufschreiben.
Aber welches Entwickler Team wäre dann für die z.B 2d rendering libary verantwortlich ?

Danke für die Antworten Leute !

Phyton schrieb:

+Arcoth das heißt das leute sagen was sie gerne haben möchten und es dann in einem draft wie du erwähnt hast aufschreiben.

nein, es funktioniert so: https://isocpp.org/std/the-life-of-an-iso-proposal

Columbo

SeppJ schrieb:

Man sollte nicht dem Fehlschluss unterliegen, dass Bibliotheken von außerhalb des Sprachstandards irgendwie verbotenes Terrain wären.

Das tut niemand.

Der Vorteil der Standardbibliothek liegt in Einheit. Wenn eine Netzwerk-Bibliothek Teil der offiziellen Standardbibliothek wird, wird der Großteil künftiger Anwendungen diese auch verwenden. Unsere Bemühungen, die Spezifikation zu entwickeln und umzusetzen, werden gebündelt, und das ist aus einer Community Perspektive extrem effizient. Wenn wir stattdessen N verschiedene populäre Libs haben (wo N natürlich nicht sonderlich groß ist, aber immerhin im zweistelligen Bereich), wird keine von ihnen nahtlos designed oder umgesetzt werden (ich behaupte dies nicht von unserer Standardbibliothek, aber die Tendenz ist deutlich stärker); einige werden womöglich eingestellt, oder nicht für deine nächste Zielplattform implementiert. Kurz: Du hast keine Garantien.

Edit: Ich möchte nicht den Eindruck erwecken, dass ich nicht annehme, dass du all das natürlich weißt. Warum also die Frage?

na sicher, alles, was nicht standard ist, ist in diesem subforum verboten. außer vielleicht boost. eh aus gutem grund, aber so entsteht halt der eindruck.

Columbo

lololo schrieb:

na sicher, alles, was nicht standard ist, ist in diesem subforum verboten.

Nein. Dieses Subforum befasst sich mit Standard C++ und allen relevanten Themen die in keinem anderen Board besser aufgehoben sind. Das mag wie eine Tautologie klingen, aber wenn ein Neuling es sich zu Herzen nimmt, müssen wir nicht einen Haufen GUI und WinAPI Threads verschieben.

SeppJ

Arcoth schrieb:

Edit: Ich möchte nicht den Eindruck erwecken, dass ich nicht annehme, dass du all das natürlich weißt. Warum also die Frage?

Das war eine rhetorische Frage, aber eigentlich hätte ich eine andere rhetorische Antwort erwartet

Deine Einschätzung über die Bündelung von Interessen steht nämlich im Gegensatz zur Schnelligkeit und Expertise bei der Entwicklung. Um ein Extrembeispiel zu nennen: Eine Bibliothek für 3D-Grafik ist sicherlich besser bei Entwicklern aufgehoben, die an der Vorderfront der technischen Entwicklung sind. Die müssten dann alle beim C++-Standard mitwirken (und beim C-Standard, und beim C#-Standard, und beim Java-Standard und allen anderen Sprachen, die vorher die Standalone-Bibliothek via Wrapper benutzt haben), damit man die gleiche Kompetenz erreicht. Und die Erscheinungstermine des C++-Standards müssten an das Erscheinen neuer Entwicklungen in dem Bereich gekoppelt werden.

Das mag bei 3D-Grafik extrem sein, aber gilt auch für vieles andere, z.B. grafische Nutzeroberflächen.

Columbo

Cool. Also haben wir OGRE. Mit einem Haufen Singletons, einem merkwürdigen Plugin System, und einer so gigantischen Struktur das es schwer fällt, überhaupt das Gesamtkonzept unter Hundert Stunden Investition zu verstehen (ich weiß - glaube ich - noch wovon ich rede, ich habe so einiges mit OGRE gemacht). Und das desaströs designte Qt. Mit QString . Und QVector . Und ganz viel new . Oder Irrlicht, mit delete this .

Die Resultate externer Entwicklung sind in der Praxis einfach nicht zufriedenstellend, selbst bei derart großen Bibliotheken. Dagegen sehe ich keinen schlecht designten Teil der Standardbibliothek, mit Ausnahme von IOStream, aber Ogre::Vectorselbst die nutze ich noch ganz gerne. Und über die Qualität von Standardbibliotheks-Implementierungen brauchen wir nicht zu streiten, die sind zumindest bei libstdc++ und libc++ größtenteils allererste Sahne.

Eine Bibliothek für 3D-Grafik ist sicherlich besser bei Entwicklern aufgehoben, die an der Vorderfront der technischen Entwicklung sind.

Das wäre so, wenn die Menge der exzellenten C++ Entwickler (also solche mit einem technischen Verständnis der Sprache das mindestens meinem und besser noch deinem gleicht) und die Menge der im Feld vorne bleibenden Entwickler und der, die Designerfahrung haben, gute Überschneidung hätten. Ist aber irgendwie nicht so. Also brauchen wir ein paar Fachkundige, die Ahnung von dem Model haben, und Designer, die Ahnung haben, wie das ganze in eine API zu fassen ist, und Entwickler, die verdammt noch mal proggern können.

Und damit wären wir im Standardisierungsprozess angelangt.

Edit: Habe vergessen, dass Ogre::Vector usw. ja keine Container sind, sondern nur ein paar Typedefs definieren. Mea culpa.

SeppJ

Arcoth schrieb:

Das wäre so, wenn die Menge der exzellenten C++ Entwickler (also solche mit einem technischen Verständnis der Sprache das mindestens meinem und besser noch deinem gleicht) und die Menge der im Feld vorne bleibenden Entwickler und der, die Designerfahrung haben, gute Überschneidung hätten. Ist aber irgendwie nicht so. Also brauchen wir ein paar Fachkundige, die Ahnung von dem Model haben, und Designer, die Ahnung haben, wie das ganze in eine API zu fassen ist, und Entwickler, die verdammt noch mal proggern können.

Ja. Und wie motivierst du diese Leute dazu, ihre Zeit nur auf C++ zu verwenden? Real bekommst du am Ende eine super-designte Bibliothek heraus, die von Leuten programmiert wurde, die vor 20 Jahren mal zwei Stunden OpenGL im Studium gemacht haben.

Columbo

SeppJ schrieb:

Arcoth schrieb:

Das wäre so, wenn die Menge der exzellenten C++ Entwickler (also solche mit einem technischen Verständnis der Sprache das mindestens meinem und besser noch deinem gleicht) und die Menge der im Feld vorne bleibenden Entwickler und der, die Designerfahrung haben, gute Überschneidung hätten. Ist aber irgendwie nicht so. Also brauchen wir ein paar Fachkundige, die Ahnung von dem Model haben, und Designer, die Ahnung haben, wie das ganze in eine API zu fassen ist, und Entwickler, die verdammt noch mal proggern können.

Ja. Und wie motivierst du diese Leute dazu, ihre Zeit nur auf C++ zu verwenden? Real bekommst du am Ende eine super-designte Bibliothek heraus, die von Leuten programmiert wurde, die vor 20 Jahren mal zwei Stunden OpenGL im Studium gemacht haben.

Hä? Das ist doch gerade das Problem, das mein Vorschlag löst? Die Leute, die von C++ und den unterliegenden APIs Ahnung haben, implementieren die Spec; die Spec aber kann ja halbwegs sprachagnostisch verfasst werden (mit einigen sprachspezifischen Erweiterungen, um generische Funktionalität bereitzustellen).

SeppJ

Arcoth schrieb:

Hä? Das ist doch gerade das Problem, das mein Vorschlag löst? Die Leute, die von C++ und den unterliegenden APIs Ahnung haben, implementieren die Spec; die Spec aber kann ja halbwegs sprachagnostisch verfasst werden (mit einigen sprachspezifischen Erweiterungen, um generische Funktionalität bereitzustellen).

Also ein Wrapper um eine unabhängige Bibliothek, wie jetzt auch?