Was sind eure Highlights von C++14?

Cyres

Frage_Swap schrieb:

Sone schrieb:
Aber bei mir ganz vorne dabei, der swap-Operator:
a :=: b;
Wie würde man sowas machen, also ohne den Operator?

swap(a, b)

Sone

hmmmmmmmmmm schrieb:

Also für strings, complex und chrono, richtig?

Ja, make_unique ist auch ein nettes Goodie. Frage mich, wieso es kein make_unique in C++11 gibt...

TyRoXx

Sone schrieb:

Aber bei mir ganz vorne dabei, der swap-Operator:
a :=: b;
Auch überladbar in Klassen, etc.

Dieser Blödsinn wurde zum Glück nicht angenommen. Hätte mich auch gewundert.

Wenn schon für jeden Mist ein Operator, dann richtig:

//move-Operator
a ~= b;

//begin und end Operatoren, weil die so lustig aussehen.
std::begin(range) == :-) range
std::end(range) == :-( range
for (auto i = :-) range; i != :-( range; ++i)

//switch-Operator: Endlich kann man switch-Statements in eine Zeile quetschen.
int f(int a) {
  switch (a) {
    case 0: return 1;
    case 2: return 3;
    default: return 2;
  }
}

int f(int a) {
  return a ?? 0: 1 ?: 2: 3 ?: 2;
}

//Inkrementieren und Dekrementieren um zwei!
int i = 0;
i+++;
assert(i == 2);

//uniform initialization für enum
enum e {
  a{0},
  b{1}
};

//geschweifte Klammern überladen
struct S {
  static std::string operator {} () {
    return "jo";
  }
};
assert(S{} == "jo");

Das alles ist nicht weniger sinnvoll als der Swapperator.

Sone

Ich fand die Idee zuerst auch bescheuert, zugegeben:

Sone schrieb:

Und swap-Operatoren hört sich ziemlich lustig, dennoch unnötig an.

Ich habe immer noch dieselbe Meinung darüber - prinzipiell nur Syntaxzucker, nichts weiter. Trotzdem mag ich es und es hätte mich gefreut, würde es angenommen werden.

TyRoXx schrieb:

Das alles ist nicht weniger sinnvoll als der Swapperator.

Doch. Einiges würde existierende Syntax in den Grundfesten erschüttern und ist darüber hinaus schlecht lesbar.
Ich finde die derzeitige Syntax für einen Swap-Operator auch doof, zugegeben. Sieht auf die Dauer unlesbar aus. Da ist mir swap(a, b) lieber.

knivil

Sone schrieb:

Ja, make_unique ist auch ein nettes Goodie. Frage mich, wieso es kein make_unique in C++11 gibt...

Das hat Herb Sutter in einem Vortrag erwaehnt: Man hat es schlicht vergessen. Gleichzeitig hat er eine Implementation angegeben, trivial quasi.

TyRoXx

constexpr wird endlich wirklich nützlich, wenn man in solchen Funktionen Statements benutzen darf.
Angenehm ist auch, dass man Werte in Lambdas hineinbewegen kann. Das spart an manchen Stellen unnötige Kopien.
Das VLA ist der letzte Sargnagel für C-Arrays. Jetzt kann man versehentlich eine Variable als Länge angeben. Wenn ich das richtig verstehe, können VLA-Definitionen std::bad_array_length werfen. Da nehme ich doch lieber array oder vector .

otze

TyRoXx schrieb:

Das VLA ist der letzte Sargnagel für C-Arrays. Jetzt kann man versehentlich eine Variable als Länge angeben.

Warum sollte das schlecht sein?

Wenn ich das richtig verstehe, können VLA-Definitionen std::bad_array_length werfen. Da nehme ich doch lieber array oder vector .

Warum? VLAs liegen auf dem Stack, im Gegensatz zu array oder vector. Das ist groß-ar-tig. 0 overhead, automatisch augeräumt und unglaublich nützlich. Ich habe VLAs ab dem Moment vermisst, als ich reduce operatoren mit OpenMP implementieren wollte für die ich ein kleines array - größe anzahl der threads (dynamisch) brauche. std::array ist umständlich und std::vector spürbarer overhead.

Kellerautomat

Ich bin eher enttäuscht vom neuen Standard. Wenig wirklich neues, viele Notwendigkeiten endlich dabei.

Polymorphe Lambdas sind absolut hässlich, das auto muss weg.
Allocatoren werden mit inplace realloc endlich gefixt.
Das neue printf benutzt immer noch Typ-Spezifizierer.
std::convert ist nur ein Fix für die Symptome, keine Lösung.
std::nonowning_tr ist nutzlos, die Begründungen dafür BS.
Polymorphic Allocators: So hätte es von Anfang an sein sollen. Ein Allokator hat nicht Teil eines Typs zu sein.
Resumable functions: Na hoffentlich wird das von Compilern nicht über Context-Switching implementiert.

Meine Meinung dazu.

krümelkacker

Cyres schrieb:

Frage_Swap schrieb:

Wie würde man sowas machen, also ohne den Operator?
swap(a, b)

und noch ein using std::swap; davor, damit auf std::swap zurück gefallen werden kann, wenn es keine spezielle Version für einen bestimmten Typen gibt, die per ADL auffindbar ist.

knivil

Resumable functions: Na hoffentlich wird das von Compilern nicht über Context-Switching implementiert.

Wenn Resumable Functions aehnlich Coroutines sein sollen, dann gibt es unter Linux nur die Moeglichkeit es mittels Threads zu loesen, da andere Betriebssystemfunctionen wie setcontext als deprecated markiert sind.

firefly

otze schrieb:

Warum? VLAs liegen auf dem Stack, im Gegensatz zu array oder vector.

auch std::array liegt komplett auf dem "Stack".

Laut http://en.cppreference.com/w/cpp/container/array
ist std::array vergleichbar mit einem struct, welches ein C-Array mit fester länge enthält.

Und zu mindestens die Implementation von std::array im gcc 4.6.3 enthält kein
new um platz für die Elemente zu bekommen.

Sone

auch std::array liegt komplett auf dem "Stack".

Das ist offensichtlich. std::array ist nur ein Wrapper um ein echtes Array.

Ein Swap-Operator würde übrigens automatisch ADL einbinden.

Eisflamme

Keine neuen Operatoren für irgendwelche herkömmlichen Funktionen, was soll so was? C++ ist kryptisch genug, bald programmiert das keiner mehr, weil's zu verworren aussieht und stirbt aus, genial. Absolut für die Anti-Swap-Operator-Bewegung. Da fände ich einen Move-Operator noch sinnvoller, aber auch das finde ich schwachsinnig...

vector<string> vec1, vec2;
// fill vec1
vec2 ä vec1;

camper

otze schrieb:

TyRoXx schrieb:

Das VLA ist der letzte Sargnagel für C-Arrays. Jetzt kann man versehentlich eine Variable als Länge angeben.

Warum sollte das schlecht sein?

Wenn ich das richtig verstehe, können VLA-Definitionen std::bad_array_length werfen. Da nehme ich doch lieber array oder vector .

Warum? VLAs liegen auf dem Stack, im Gegensatz zu array oder vector. Das ist groß-ar-tig. 0 overhead, automatisch augeräumt und unglaublich nützlich. Ich habe VLAs ab dem Moment vermisst, als ich reduce operatoren mit OpenMP implementieren wollte für die ich ein kleines array - größe anzahl der threads (dynamisch) brauche. std::array ist umständlich und std::vector spürbarer overhead.

Ich verstehe nicht, wieso der Sprachkern für so ein Feature geändert werden muss. Eine Librarylösung würde es auch tun (dass dafür zusätzliche Compilermagie benötigt wird, ist unwesentlich).

camper schrieb:

Ich verstehe nicht, wieso der Sprachkern für so ein Feature geändert werden muss. Eine Librarylösung würde es auch tun (dass dafür zusätzliche Compilermagie benötigt wird, ist unwesentlich).

Die C99-Kompatibilität finde ich nicht schlecht. Mich stört nur der unnötige Check zur bad_array_length, das wäre die Aufgabe einer Librarylösung. Schön wäre auch eine Librarylösung, die keine Exception wirft, sondern auf den Heap zurückgreift, wenn der Stackspeicher nicht ausreicht.

krümelkacker

Jens Weller hat anscheinend in seiner Artikel-Serie auch viele Porposals verarbeitet, die nicht im C++14 Entwurf gelandet sind. Mir stellt sich die Frage, was davon wirklich im C++14 Entwurf gelandet ist. Ist dies hier eine vollständige Liste der "core language features"?

Und dann gibt's in der Standardbibliothek natürlich mindestens noch make_unique als neues Feature. Was noch? Sind die Typ-Transformations-Aliase auch dabei?

Das mit der gnädigeren Deduktion für Funktionsrückgabetypen finde ich gut.
Polymorphe Lambdas sind auch nicht schlecht.
make_unique ist nett.
Und diese Typ-Transformations-Aliase wären auch nett.
Die flexiblere Capture-Clause für Lambdaausdrücke ist auch gut. Fand ich damals schon ziemlich blöd, dass es kein "move capture" gab.

Die VLAs find ich irgendwie blöd und ich weiß auch nicht, was ich von dyn_array halten soll. Wo ist jetzt noch der Sinn von dyn_array, wenn es VLAs gibt? Konnten die sich nicht entscheiden? ein dyn_array ist natürlich wieder nicht move-bar. Na supi. Ich verstehe nicht, was das alles soll.

BTW: Habe gerade gesehen, dass hier auch ein paar C++14 Bibliotheks-Features auftauchen.

camper

speckarray schrieb:

camper schrieb:

Ich verstehe nicht, wieso der Sprachkern für so ein Feature geändert werden muss. Eine Librarylösung würde es auch tun (dass dafür zusätzliche Compilermagie benötigt wird, ist unwesentlich).

Die C99-Kompatibilität finde ich nicht schlecht.

Gemessen daran, was alles (zum Glück) nicht unterstützt wird, bleibt da nicht viel Kompatibilität übrig.

Sone

Sind die Typ-Transformations-Aliase auch dabei?

Ja.

Wo ist jetzt noch der Sinn von dyn_array, wenn es VLAs gibt?

Was ist der Sinn von** std::array **, wenn es schon richtige Arrays gibt? Und std::array hat natürlich genauso wenig Move-Semantik wie dynarray ...

Ich verstehe nicht, wieso der Sprachkern für so ein Feature geändert werden muss. Eine Librarylösung würde es auch tun (dass dafür zusätzliche Compilermagie benötigt wird, ist unwesentlich).

So sehe ich das auch. Der Standard kann dabei sogar die storage duration-Klasse offen lassen*. Das wäre bei VLAs allerdings nicht so flexibel... der sizeof -Operator darf auf sie nicht angewandt werden (Größe muss separat gespeichert werden, auch wenn das in den meisten Fällen automatisch passiert), als Member kann man die Größe nicht im Konstruktor festlegen...
(Edit: Über letzteres bin ich mir gerade im Unklaren)

*Klar, dass das - wo möglich und sinnvoll - auf den Stack gepackt wird.

Sone schrieb:

Was ist der Sinn von** std::array **, wenn es schon richtige Arrays gibt?

Richtig: es gibt keinen.

Sone

Das ist so furchtbar lächerlich. Wenn ein Feature überhaupt keine Daseinsberechtigung hat, wäre es schon längst als deprecated markiert (oder überhaupt nicht erst aufgenommen worden).

Mich stört nur der unnötige Check zur bad_array_length, das wäre die Aufgabe einer Librarylösung.

Ich finde, der ist gerechtfertigt. VLA-Elemente sollen auf dem Stack landen. Daher ist diese Klausel

If the size of the array exceeds the size of the memory available for objects with automatic storage duration, the behavior is undefined.
[Fußnote:]Implementations that detect this case are encouraged to throw an exception that would match a handler of type std::bad_array_length

in meinem Interesse.

Schön wäre auch eine Librarylösung, die keine Exception wirft, sondern auf den Heap zurückgreift, wenn der Stackspeicher nicht ausreicht.

Wenn es dir sowieso nicht wichtig ist, wo deine Objekte landen, was du schließlich suggerierst, nimm gleich std::vector !
In welcher Situation ist man von der storage duration nicht abhängig, hat aber einen Vorteil wenn die Elemente auf dem Stack landen?