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

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

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*

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.

k1ro

net schrieb:

@topic: ich würde referenzen abschaffen, pointer reichen voll und ganz

ach ich find

void func(std::string const& s)

schön handlich, v.a. da es genauso schnell ist, man sich das ganze rum-ge-*-ne spart und man es nicht auf 0 überprüfen muss.

phlox81

net schrieb:

@topic: ich würde referenzen abschaffen, pointer reichen voll und ganz.

Referenzen lassen sich nicht löschen, Pointer dagegen schon.
Und wie schon gesagt wurde, Referenzen können nicht NULL sein.

Devil

Mal spontan ausm Bauch raus:

C-Casts verbieten.

explicit als Default, dafür neues Schlüsselwort implicit.

Möglichkeit, stärkere Typen zu definieren. Beispiel

typedef int Weg;
typedef int Geschwindigkeit;
Weg s( 5);
Geschwindigkeit v( 10);
s = v; ///< verboten, da 'unterschiedliche' Typen

Also anstatt typedef ein sinngemäß 'stärkeres' Schlüsselwort, z.B. typeredef oder strong_typedef..

Echte Delegates (keine Bindung von Methodenzeigern an konkrete Klassen, sondern nur an die Signatur der Methode (Ich weiß, technisch problematisch mit Mehrfachvererbung))

Gibt bestimmt noch mehr, was mir jetzt gerade nicht einfällt.

groovemaster

net schrieb:

groovemaster schrieb:

- binäre Fliesskomma Literale wie in C

was issn das?

Sowas zB

0x1.ffffp+10

net 0

groovemaster schrieb:

Sowas zB
0x1.ffffp+10

fliesskommakonstante als hexzahl? das ist total abgefahren
sowas wird man wohl in 100 jahren nicht gebrauchen... und das kann nur c, c++ nicht?
echt seltsam....

camper

net schrieb:

@topic: ich würde referenzen abschaffen, pointer reichen voll und ganz

dann schaffst du auch operatoren überladung ab.

Sovok

asdfghjkl schrieb:

Weitere Libs für: regex, netzwerk, threads, datenbank usw. wären nicht schlecht. Hier ist man immernoch auf externe Lösungen angewiesen.

aber nur wenns ordentlich modular aufgebäut wär
d.h. es müsste immernoch ohne den ganzen schnickschnack funktionieren
ned so ein verflochtenes nest wie die stdlib

bei der stdlib heissts meist entweder sie gibts auf der plattform oder ned
was bedeutet, dass man für die meisten kleinen sachen gleich bei der libc bleiben kann

Artchi

Und warum sollte z.B. regex auf std::string verzichten? Das willst du doch eigentlich damit andeuten?

Warum sollte es z.B. Regex nicht auf jedem System geben? Selbst jeder PDA hat Leistung und Speicher ohne Ende. Verstehe den Grund nicht, warum man noch die Minimalisten-Tour bei C++ fahren soll?

groovemaster

net schrieb:

fliesskommakonstante als hexzahl? das ist total abgefahren
sowas wird man wohl in 100 jahren nicht gebrauchen...

Du musst es ja wissen.