Was würdet Ihr an C++ ändern, wenn Ihr keine Rücksicht auf Kompatibilität, Geld, Zeit, Arbeit, etc. nehmen müssten?

[pmw]

Dass Arrays wie char* ihre eigene Länge kennen (wie z.B. in D) und endlich mal eine einheitliche Namensgebung für die Standard-Funktionen. GUI-Toolkit wie wxWidgets für alle Plattformen

[audacia]

Artchi schrieb:

Das endlich Sockets und Threads in die Standard-Lib rein kommen.

Oder kurz: Boost for Standard!

[phlox81]

audacia schrieb:

Artchi schrieb:

Das endlich Sockets und Threads in die Standard-Lib rein kommen.

Oder kurz: Boost for Standard!

boost kennt (noch) keine Sockets.
http://boost.org/libs/libraries.htm#Alphabetically

Ich fänd export schon ganz nett, und evtl. ein moderner nachfolger
für cgis, also praktisch wie jsp nur schnell :p.

Ansonsten sockets und threads wurden ja schon gesagt.
Und teile von boost, nicht alles, zb. boost::filesystem wär
ganz nett für den Standard.

Generell finde ich, das es 2 Standard libs geben müsste,
eine kleine, und im Kern stabile, wie jetzt die STL,
und eine erweiterte, die dann sehr umfassend ist, und
zb. dann auch ganz boost enthält.

Devil

[audacia]

devil81 schrieb:

boost kennt (noch) keine Sockets.

War ja auch hauptsächlich auf die Threads bezogen.

[operator void]

Rauswerfen: was heute eher exotische Altlast als praktisches Feature ist. Dann ist der Sprachumfang schonmal halbiert. Vor allem endlich new[] und delete[] in irgendetwas Exotisches umbenennen, damit die Trennung von new und delete klarer wird.

Ändern: Das Übersetzungsmodell, die Deklarationssyntax, das Design der Stream-Bibliothek, Kleinigkeiten wie das Verhalten der C-Arrays usw.

Hinzufügen: Move-Semantiken, Lambdas, mehr Reflektion.

[Irgendwer]

pmw schrieb:

Dass Arrays wie char* ihre eigene Länge kennen (wie z.B. in D)

Gibt es doch bereits und heist std::string und std::vector.

Was definitiv fehlt sind lambda Ausdrücke. boost::lambda ist ja ganz schön aber macht die Übersetzung langsam.

Ansonsten würde ich mir auch noch wünschen, dass man nur das public und protected Interface einer Klasse in den Header packen muss. Es gibt keinen technischen Grund wieso man private Methoden im Header deklariren muss!

Ordentiliche Funktionen mit variabler Parameterzahl wäre auch fein. Auch variable Anzahl von Template Parametern.

Dann gibt es noch viele kleine Details wie zum Beispiel, dass es explicit gibt anstatt von implicit oder, dass bei template Templates default Argumente nicht spielen und sie deswegen so gut wie nutzlos. Ein typeof wäre auch nicht schlecht.

[PD]

@irgendwer:
Das es dafür keinen technischen grund gibt ist nicht ganz wahr. Irgendwo brauchen Operatoren wie sizeof() auch ihre Infos ^^ Das bedeutet der Typ muss bekannt sein. Wenn man nun in seinem Hauptprogramm eine andere definition hätte (auf grund der fehlenden privates) als z.B. in seiner lib würde sizeof() wahrscheinlich mucken ^^ Und allgemein die Speicherverwaltung wäre ziemlich übel dran.

[Walli]

- Ein vernünftiges assert.
- Ein for_each-Keyword.
- break n, falls es dann mal nötig sein sollte.
- Man soll nicht in jeder Datei explizit sagen müssen, dass sie nicht mehrfach includiert werden darf.
- Ellipsen rausschmeißen.
- Standard UI-Klassen mit allem was dazu gehört.
- threads, wie in boost nur vielleicht ein wenig umfangreicher.
- regex, spirit, filesystem, lambda, uBlas und diverse smart-Pointer aus boost. Ausserdem alles coole was ich noch vergessen habe. Dann noch ne Klasse für ntrees und welche für große Zahlen.
- Ne vernünftige String-Klasse.

[picocat]

ich muss beipflichten: groooooooooooße zahlen!

aber was noch wichtiger ist: endlich alle c-reste wegrationalisieren. und vor allen dingen, windows.h und linux.h (sinnbildlich) vereinheitlichen. das bedeutet: nur noch os-unabhängig.

[audacia]

operator void schrieb:

Rauswerfen: was heute eher exotische Altlast als praktisches Feature ist. Dann ist der Sprachumfang schonmal halbiert. Vor allem endlich new[] und delete[] in irgendetwas Exotisches umbenennen, damit die Trennung von new und delete klarer wird.

Rauswerfen? Sicher? Dir ist klar, welcher Basis sich C++ entzöge?

operator void schrieb:

Ändern: Das Übersetzungsmodell, die Deklarationssyntax, das Design der Stream-Bibliothek, Kleinigkeiten wie das Verhalten der C-Arrays usw.

Ich glaube, du brauchst eine andere Programmiersprache.

Walli schrieb:

- Ne vernünftige String-Klasse.

Lars Hupel schrieb:

und vor allen dingen, windows.h und linux.h (sinnbildlich) vereinheitlichen. das bedeutet: nur noch os-unabhängig.

Bloß nicht! Da können wir ja gleich in Java programmieren!

Moritz

[picocat]

audacia schrieb:

Lars Hupel schrieb:

und vor allen dingen, windows.h und linux.h (sinnbildlich) vereinheitlichen. das bedeutet: nur noch os-unabhängig.

Bloß nicht! Da können wir ja gleich in Java programmieren!

Moritz

was hast du gegen os-unabhängigkeit?

[net 0]

fehlt nur noch 'ne 'c++ virtual machine'

[audacia]

Lars Hupel schrieb:

was hast du gegen os-unabhängigkeit?

Nichts, aber du schriebst: nur noch OS-unabhängig! Welche Sprache sollte man denn sonst benutzen, wenn man OS-spezifische Sachen programmieren will? Assembler? C?

[audacia]

net schrieb:

fehlt nur noch 'ne 'c++ virtual machine'

Ungefähr das wollte ich ausdrücken

[asdfghjkl]

Der Präprozessor muss weg. Auf das das ganze #include, #define Gerassel könnte man gut verzichten. Eventuell nur noch für bedingte Compilierung zulassen.

Ein vernünftiges Binärinterface: Will ich C++ Code von anderen Programmiersprachen verwenden, dann mus ich die Klassen erst mit C wrappen.

Die alten C-Libs verbannen und dafür gute OO-Alternativen bauen (Also für Math, Zeit/Datum, Konvertierung, usw. ).
Weitere Libs für: regex, netzwerk, threads, datenbank usw. wären nicht schlecht. Hier ist man immernoch auf externe Lösungen angewiesen.

Einen vernünftigen Reflectionmechanismus, wie man ihn aus C#, Java kennt. Mit allem was dazu gehört: Dynamisches Laden von Libs, mehr Typinformation, compilierung von Code zur Laufzeit, ...

Schnellere C++ Compiler. Bei großen Projekten dauert ein Build ne halbe Ewigkeit.

[audacia]

asdfghjkl schrieb:

Der Präprozessor muss weg. Auf das das ganze #include, #define Gerassel könnte man gut verzichten. Eventuell nur noch für bedingte Compilierung zulassen.
...
Die alten C-Libs verbannen und dafür gute OO-Alternativen bauen (Also für Math, Zeit/Datum, Konvertierung, usw. ).
Weitere Libs für: regex, netzwerk, threads, datenbank usw. wären nicht schlecht. Hier ist man immernoch auf externe Lösungen angewiesen.

Einen vernünftigen Reflectionmechanismus, wie man ihn aus C#, Java kennt. Mit allem was dazu gehört: Dynamisches Laden von Libs, mehr Typinformation, compilierung von Code zur Laufzeit, ...

Das wurde schon einmal versucht: die diversen Ergebnisse sind u.a. Java, C# und diese ganze .NET-Geschichte.

C++ muß abwärtskompatibel bleiben!
/Edit: OK, ich hab den Titel des Threads nicht genau gelesen. Trotzdem: warum wollt ihr ein zweites Java?

Moritz

[finix]

Walli schrieb:

- break n, falls es dann mal nötig sein sollte.

break label vielleicht, aber break n? *schauder*

[asdfghhj]

audacia schrieb:

Das wurde schon einmal versucht: die diversen Ergebnisse sind u.a. Java, C# und diese ganze .NET-Geschichte.

C++ muß abwärtskompatibel bleiben!
/Edit: OK, ich hab den Titel des Threads nicht genau gelesen. Trotzdem: warum wollt ihr ein zweites Java?

Moritz

Wieso? C++ ist doch noch nicht einmal mehr heute kompatibel zum aktuellem C Standard. Es geht ja nicht darum ein 2. Java zu schreiben, sondern C++ konsistenter/übersichtlicher/sauberer zu machen. Bestimmte Dinge sind einfach nicht mehr ganz Zeitgemäß.

[groovemaster]

pmw schrieb:

Dass Arrays wie char* ihre eigene Länge kennen

Wo kennt denn char* seine Länge? Oder meinst du C-Strings? char* kann aber durchaus mehr als nur ein C-String sein.
Zudem kennen built-in Arrays dank sizeof ihre Gösse. Und wer nicht in der Lage ist, sich diese bei new[] zu merken, sollte sich evtl. ein anderes Hobby suchen.

Was ich mir in C++ wünschen würde?
- typeof Schlüsselwort und template aliasing (beides kommt vermutlich mit dem nächsten Standard )
- ein vernünftiger built-in String Typ (zumindest für Literale) und nicht diese verwaschenen char*/wchar_t* C-Strings
- andere Typsyntax - zB statt 'int foo[10]' lieber 'int[10] foo'
- erweitertes break
- binäre Fliesskomma Literale wie in C
- Properties
- dynamischen Speicher in der Grösse anpassen - vielleicht renew[] oder sowas
- effektivere STL - mehr Funktionalität (wie zB Threads), dafür weniger aufgeblähte Klassen
- GUI Lib

Und weil sich einige soviel Laufzeitfunktionalität wünschen, C++ ist in erster Linie eine Compilezeit Sprache. Und das wird sie hoffentlich auch bleiben.

[net 0]

groovemaster schrieb:

- typeof Schlüsselwort und template aliasing (beides kommt vermutlich mit dem nächsten Standard )
- ein vernünftiger built-in String Typ (zumindest für Literale) und nicht diese verwaschenen char*/wchar_t* C-Strings
- andere Typsyntax - zB statt 'int foo[10]' lieber 'int[10] foo'
- Properties
- effektivere STL - mehr Funktionalität (wie zB Threads), dafür weniger aufgeblähte Klassen
- GUI Lib

geht auch wieder richtung java. also: vergesst c++ und nehmt java

groovemaster schrieb:

- binäre Fliesskomma Literale wie in C

was issn das?

@topic: ich würde referenzen abschaffen, pointer reichen voll und ganz.
... und ein 'const' nur noch am ende von methoden zulassen.