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.

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/

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

Wut? Oh noes!

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

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

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.

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

Wehe ihr lest meine alten posts !

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

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

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>

Aber Header und Cpp-Datei weiterhin geschrieben werden müssen?

und das hätte dann welchen Vorteil?

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

so wie ich das sehe - schon. nur kann und soll es auch weiterhin header geben. header sind ja nichts anderes als dateien, die zu einer übersetzungseinheit (ÜE) verwurstet werden. so wie ich es verstehe, wird man zukünftig für eine ÜE definieren können, dass teile von dieser als modul zu verstehen sind (auch: ein modul kann sich über mehrere ÜE erstrecken), wobei bestimmte symbole aus dem modul heraus exportiert werden können, die der compiler dann sieht. angeblich soll es sogar versuche geben, ein einheitliches format für die module über die compiler-hersteller hinweg zu definieren.

headerdateien wird es weiterhin geben und sie werden auch weiterhin ihre berechtigung haben. ca. genauso wie makros.

im detail kenne ich den aktuellen stand des proposals aber nicht.

Doch, Modules ersetzen Header. Das ist Sinn der Sache. Mit Visual Studio kann man das sogar schon ausprobieren.

Im C++ Sinn eher Ergänzen als Ersetzen.

Es gibt ja jetzt auch ein "destructuring bind":

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

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

Echt, sowas soll kommen?

Wozu braucht man da dann noch das auto , das sieht irgendwie sehr seltsam aus... geht das dann nur mit auto oder kann man die einzelnen Typen auch explizit angeben?