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

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.

net 0

camper schrieb:

net schrieb:

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

dann schaffst du auch operatoren überladung ab.

auch das, der übersichtlichkeit wegen. sowas wie 'object.add()' ist viel eindeutiger. bestes negativbeispiel sind ja << und >> bei den streams, welche ja urspünglich bit-shift operatoren sind, aber da eine andere bedeutung haben. damit man so'n unfug gar nicht erst machen kann, kennt z.b. java auch keine operatorenüberladung.
hehe, das fällt schon auf - viele verbesserungen laufen auf sowas wie java hinaus

groovemaster

net schrieb:

camper schrieb:

net schrieb:

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

dann schaffst du auch operatoren überladung ab.

auch das, der übersichtlichkeit wegen. sowas wie 'object.add()' ist viel eindeutiger.

Wieso das? Wenn ich zB zwei (mathematische) Vektoren habe und rechne

a = a + b;
// bzw
a += b;

ist das einfacher und intuitiver als

a.add(b);

Operatorüberladung (sowie Referenzen) abzuschaffen ist imo Unsinn. Wer sowas nicht nutzen will, braucht es ja auch nicht.

net 0

groovemaster schrieb:

Wieso das? Wenn ich zB zwei (mathematische) Vektoren habe und rechne
a = a + b;
// bzw
a += b;
ist das einfacher und intuitiver als
a.add(b);

was macht das '+'? addiert es immer zwei elemente der vektoren oder hängt es den einen vektor an den anderen dran?

groovemaster schrieb:

Operatorüberladung (sowie Referenzen) abzuschaffen ist imo Unsinn. Wer sowas nicht nutzen will, braucht es ja auch nicht.

manchmal muss man es. gibt viele libs die das einsetzen

Shade Of Mine

net schrieb:

sowas wie 'object.add()' ist viel eindeutiger.

Beliebter Java Fehler:

a.add(b);

ups. falsch. add addiert b zu a und liefert das ergebnis ohne a zu verändern.
wäre mit + nicht passiert.

+ ist natürlich genauso eindeutig wie eine methode 'plus', dh, wenn du die Methode plus zum dividieren verwendest, würdest du sagen 'doofer programmierer' und nicht 'doof dass man methoden selber benennen kann', oder?

macht
vec.add(otherVec);
jetzt eine addition von allen werten, da vec[0]+=otherVec[0] usw. oder hängt es otherVec an vec an?
wer kann das schon sagen. genauso bei +
es ergibt sich aus der api. bei einer guten api wird man das nicht verwechseln.

ein
a.add(b)
ist aber immer zweideutig
natürlich kann man sagen, dass es sich aus der api ergibt, aber zB bei vec+otherVec kann ich immer zu einer methode append() wechseln, aber was amche ich bei a.add(b)? da kann ich nicht zu etwas anderem wechseln, um besser auszudrücken ob ich + oder += meine.

mal von so perversitäten wie
a.add(b.multiply(c.divide(4)));

PD schrieb:

@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.

Wer lesen kann ist im Vorteil : Ich schrieb über private Methoden welche nichts an der Größe ändern.

Sovok

Artchi schrieb:

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?

weil die industrie noch viele minnimalistensysteme einsetzt die mit c++ programmiert werden?
und die zahl der embedded systeme is eher am steigen als am zurückgehn

du darfst nich nur den consumer markt sehn

otze

this sollte in self umbenannt werden, und der typ von self sollte nicht T* sondern T& sein.