Was fehlt in C++11?

314159265358979

Demnächst soll ja der neue Standard kommen. Viele neue Sprachfeatures, eine viel größere Standardlibrary. Allerding würde mich interessieren: Was fehlt euch immer noch in C++11?

Ich persönlich finde es sehr schade, dass concepts es dann doch nicht geschafft haben. Jeder kennt und hasst die ewig langen Fehlermeldungen des Compilers bei z.B. Templates.

Was mir auch noch abgeht, sind Thread-safe Container, wie man sie in Java kennt. concurrent_vector, oder sowas.

Zwar nicht unbedingt ein must-have Feature, aber dennoch sehr wünschenswert finde ich auch noch Sockets.

EOutOfResources

Ein Dateisystem mit Ordnerstrukturen und dergleichen hab ich mir schon öfters gewünscht. (Jaja, ich weiss, dass es das in boost gibt aber ich mache einen Unterscheid zwischen STD und boost ).

SideWinder

Modulaufteilung statt Header/Cpp

MfG SideWinder

boost::gui

Sockets wären nett.

Concepts sahen wirklich interessant aus. Hoffe das wird was für C++3x.

Boah, C++3x - hat man bis dahin C++ noch nicht ins Museum gesteckt

Wenn das in einem ähnlichen Tempo bei den Compilerherstellern umgesetzt wird, wie der z.Z. aktuelle Standard wird das bestimmt C++11 + x

SeppJ

cmath:
const long double pi = ...
:p

Außerdem sieht das, was Alexandrescu zu Ranges statt Iteratoren sagt recht fundiert aus. Ich habe es noch nicht praktisch getestet, aber falls das so gut ist wie er behauptet, wäre das eine tolle Sache.

otze

concepts.

Statischer Con-/Destructor könnte ich gut gebrauchen.

volkard

SeppJ schrieb:

Außerdem sieht das, was Alexandrescu zu Ranges statt Iteratoren sagt recht fundiert aus. Ich habe es noch nicht praktisch getestet, aber falls das so gut ist wie er behauptet, wäre das eine tolle Sache.

Ich teste daran rum. Es ist recht gut. Aber nicht total-überzeugend.
Von "iterators must go" kann leider keine Rede sein. Zu viele Algos leben sinnvoll von mehreren Iteratoren (oder klassisch von Indizes).

volkard

StellerFragen schrieb:

Statischer Con-/Destructor könnte ich gut gebrauchen.

Statische Destruktoren? Erkläre mal. Ist das, wenn man vor den Destruktor nicht virtual schreibt?

Statische Konstruktoren? Erkläre mal. Ist das, wenn man ein Objekt erzeugen will, dessen Typ man zur Compilezeit kennt?

EOutOfResources schrieb:

Ein Dateisystem mit Ordnerstrukturen und dergleichen hab ich mir schon öfters gewünscht.

Gibts das immer noch nicht? Gibts wenigstens Threads?

ipsec

volkard schrieb:

Statische Destruktoren? Erkläre mal. Ist das, wenn man vor den Destruktor nicht virtual schreibt?

Statische Konstruktoren? Erkläre mal. Ist das, wenn man ein Objekt erzeugen will, dessen Typ man zur Compilezeit kennt?

Ich glaube er meint damit ein ähnliches Konzept wie in C#: der statische Konstruktor jeder Klasse wird zum Programmbeginn aufgerufen (seine Aufgabe ist, statische Member der Klasse zu initialisieren), entsprechend räumt der Destruktor am Ende des Programms die statischen Member wieder auf.

Brauche ich persönlich nicht.

Athar

Ich vermisse einen Weg, den Compiler in ganz bestimmten Situationen Parametertypen automatisch bestimmen zu lassen. Insbesondere möchte ich so etwas schreiben können:

sort(vec,[](&l,&r){return l.z<r.z;});

Lambda-Funktionen sind schön und gut, aber bis jetzt muss man immer noch die (oft recht langatmigen) Parametertypen selbst angeben, was gar nicht schön ist.

Eigentlich ist mir auch das return noch zu viel, besser sowas:

sort(vec,[](&l,&r){=> l.z<r.z;});

Aber gut, langsam wird's kryptisch.

wxSkip

diskette schrieb:

EOutOfResources schrieb:

Ein Dateisystem mit Ordnerstrukturen und dergleichen hab ich mir schon öfters gewünscht.

Gibts das immer noch nicht? Gibts wenigstens Threads?

Threads gibt es.
Allerdings funktionieren sie im GCC 4.5.2 noch nicht (es fehlen manche Implementierungen, weiß nicht, wie es mit 4.6 aussieht).

Dobi

Dateisystem fänd ich genau wie EOutOfResources ganz nett. Ich hab nix gegen boost, aber so würds mir noch besser gefallen.

Ne definierte Binärschnittstelle für libs wär toll, obwohl mir klar ist, dass das nicht so einfach geht.

@Athar: Bist du Golfer?

volkard

Athar schrieb:

Eigentlich ist mir auch das return noch zu viel, besser sowas:
sort(vec,[](&l,&r){=> l.z<r.z;});
Aber gut, langsam wird's kryptisch.

Smalltalk oder Perl halten es so, daß ganz schlicht der letze Ausdruck returnt wird.

sort(vec,[](&l,&r){l.z<r.z;});

Und dann braucht man die Parameter auch nicht zu nennen, denn alle Bezeichner, die nicht aufgelöst werden können, müssen ja von außen kommen.

sort(vec,[]{l.z<r.z;});

Und an {} innerhalb eines Ausdrucks ist auch schon klar genug gemacht, daß jetzt Code kommt.

sort(vec,{l.z<r.z;});

Geht leider nicht ganz. Die Übergabereihenfolge von l und r ist noch zu wichtig.
Also entweder mindestens

sort(vec,(l,r){l.z<r.z;});

oder standardisierte Namen

sort(vec,{lhs.z<rhs.z;});

oder

sort(vec,<);

Dobi

volkard schrieb:

sort(vec,{l.z<r.z;});

Das wär allerdings echt schick.

Athar

Dobi schrieb:

@Athar: Bist du Golfer?

Nicht unbedingt, aber ich finde schon, dass eine Sprache erlauben sollte, sich möglichst kurz zu fassen - vor allem in häufig vorkommenden Situationen.
Und das macht einem C++ nicht immer einfach.

Dobi schrieb:

volkard schrieb:
sort(vec,{l.z<r.z;});
Das wär allerdings echt schick.

Oh ja, das wäre eine feine Sache.
Fast schon schade, dass man bei C++ so stark auf Rückwärtskompatibilität achtet. Aber auch wenn man diese berücksichtigt, sollten da einige Verbesserungen drin sein, die C++ näher an diese schöne kleine Zeile bringen.

Edit:

volkard schrieb:

Geht leider nicht ganz. Die Übergabereihenfolge von l und r ist noch zu wichtig.

Da hätte ich angenommen, dass den unbekannten Bezeichnern von links nach rechts jeweils der nächste Parameter zugewiesen bekommen. Ist aber wahrscheinlich keine gute Idee.
Standardisierte Namen sind definitiv gut, diese könnten sich etwa an die schon bekannten Bezeichner _1, _2, ... anlehnen.

wxSkip

Was haben Lambdas mit Rückwärtskompatibilität zu tun?