C++17

Auf welche Features von C++17 freut ihr euch am meisten?

*push*

werden die concepts es noch in C++17 schaffen oder endgültig nicht?

krümelkacker

Die Features, auf die ich mich am meisten gefreut hätte, sind nicht in C++17 vorhanden sondern separate Technical Specifications (Concepts, Ranges).

C++17 haut mich jetzt nicht so von den Socken. Ich muss aber zugeben, dass ich da wahrscheinlich auch nicht den kompletten Überblick habe, was bei C++17 alles neu ist. Ich finde die eine oder andere Bibliotheks-Erweiterung zumindest gut: optional, variant, string_view.

Allerdings ist ein variant ggf. in einem invaliden Zustand. Damit meine ich, dass ein variant<string,Foo> ggf weder einen string noch einen Foo Wert speichert. Das ist schon schade. Aber man muss sich schon anstrengen, um so einen Zustand zu erreichen. In Rust umgeht man das Problem, weil das Moven eines Wertes von A nach B nie schiefgehen kann. In C++ kann

Foo a = ...;
   Foo b = std::move(a);

ja eine Ausnahme werfen -- entweder, weil Foo gar keinen Move Ctor hat und der Copy Ctor schmeißt eine Ausnahme, oder weil Foo einen Ausnahme-schmeißenden Move-Ctor hat.

Es gibt ja jetzt auch ein "destructuring bind":

auto blah(double) -> pair<double, int>;

void cxx11() {
    double mantissa;
    int exponent;
    std::tie(mantissa, exponent) = blah(3.14159265);
}

void cxx17() {
    auto [mantissa, exponent] = blah(3.14159265);
}

Das ist nett. Das Zurückgeben von mehreren Werten aus einer Funktion ist damit ergonomischer.

versionsnummer schrieb:

werden die concepts es noch in C++17 schaffen oder endgültig nicht?

http://honermann.net/blog/2016/03/06/why-concepts-didnt-make-cxx17/

dot

Artchi

Wie sieht es mit der eliminierung der Headers aus? Module?

Artchi schrieb:

Wie sieht es mit der eliminierung der Headers aus? Module?

Wut? Oh noes!

5cript

Ich bin ein bisschen enttäuscht vom Umfang von C++17.
- Ich erwarte nicht, dass Networking TS es schafft, falls doch freu ich mich
darauf. (Bitte bis November 2016!)
- Filesystem war überfällig, ist jetzt aber nichts neues, wegen boost
- fold expressions
- typename in template template Parametern war überfällig.
- optional ist überfällig
- erase_if (ersatz des erase, remove_if)
- Nested namespace definition fühlt sich überfällig an

und ich glaube std::string_view wird sich relativ schnell in mein Herz schleichen ;).

5cript schrieb:

und ich glaube std::string_view wird sich relativ schnell in mein Herz schleichen ;).

hat es bei mir schon lange - wobei ich ja span/string_span aus der GSL noch besser fände. wird es aber wohl auch nicht mehr in C++17 schaffen. genausowenig wie die coroutines-TS, auf den ich mich von allen neuerungen am meisten freue, mehr noch als auf concepts. ich find aber auch generell die TS dieses mal viel interessanter als den neuen standard. auch den modules-TS.

Ich freu mich am meisten auf Networking und Filesystem. Oh, und fold expressions sind auch ganz cool. Oh, und Concepts! Falls es das noch bis C++17 alles schafft.

Und dieses auto[x, y, z] = ... sieht auch ganz cool aus.
Erinnert mich ein wenig an Python.

Artchi

Networking, Filesystem usw. sind doch nicht so spannend, da man die doch schon immer über 3rd Parties (Boost usw.) einbinden konnte.

Ich halte es für wichtiger, wenn man der Sprache gearbeitet wird. Z.B. das endlich die Modules einzug halten. Die Header widersprechen total dem DRY-Grundsatz, schrecklich! 2017 muss man wirklich nicht noch mit Headern rum hantieren.

Artchi schrieb:

Networking, Filesystem usw. sind doch nicht so spannend, da man die doch schon immer über 3rd Parties (Boost usw.) einbinden konnte.

Curl/Boost.{Asio,Filesystem} fand ich schon immer recht cool. Hat einfach immer und immer wieder Spaß gemacht, damit zu arbeiten. Und weiterhin noch draufzubauen.

Ich halte es für wichtiger, wenn man der Sprache gearbeitet wird. Z.B. das endlich die Modules einzug halten. Die Header widersprechen total dem DRY-Grundsatz, schrecklich! 2017 muss man wirklich nicht noch mit Headern rum hantieren.

Das war mir garnicht bewusst, das mit den Modulen. Wie das wohl aussehen wird. *lemme see*
Also ich kannte nie was anderes als Header, hab ein Leben lang fast nur mit C und C++ hantiert und ich fühl mich wohl mit Headern.

5cript

Ziege schrieb:

Also ich kannte nie was anderes als Header, hab ein Leben lang fast nur mit C und C++ hantiert und ich fühl mich wohl mit Headern.

Also ich finde das wie man es in Java macht ekelhaft.
de.bla. ...

5cript schrieb:

Wehe ihr lest meine alten posts !

Ich habe sie mir angeguckt und dafür nur drei Worte:
Oh mein Gott!

im aktuellen proposal zu den modulen sind die "bloß" eine ergänzung zu den header. funktioniert im prinzip so:

#include <iostream>
#include <cwhatever>

module foobar; //bis hierhin ganz gewöhnlich
//ab hier ist alles teil eines moduls.

export void fun(); //teil des interfaces des moduls
void bar(); //nicht teil des interfaces

import quuz; //importiert alle im modul quuz exportierten symbole

nicht kompliziert, nicht aufwändig, aber mächtig - allerdings fürchte ich mich ein bisschen davor, auf den kompilier-kaffee verzichten zu müssen...

volkard

bei ranged for:
end() kann endlich einen anderen Typ als begin() haben.
Das spart jede Menge Dazuerfindung von Iteratorwerten für Generatoren.

5cript

GottJesusGeist schrieb:

5cript schrieb:

Wehe ihr lest meine alten posts !

Ich habe sie mir angeguckt und dafür nur drei Worte:
Oh mein Gott!

da war ich 14

</offtopic>

Artchi

Die Modules scheinen aber kein Ersatz für Headers zu sein, oder? Kann es sein, das die nachher nur für den User-Code sind? Aber Header und Cpp-Datei weiterhin geschrieben werden müssen? Also das man alles so wie bisher macht, am Ende dem Tool sagt, das es daraus ein Module generieren muss? Nicht das was ich mir erhofft habe (doppelte Arbeit sparen).