C++17
-
-
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!
-
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 anund 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.
-
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.
-
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 symbolenicht kompliziert, nicht aufwändig, aber mächtig - allerdings fürchte ich mich ein bisschen davor, auf den kompilier-kaffee verzichten zu müssen...
-
bei ranged for:
end() kann endlich einen anderen Typ als begin() haben.
Das spart jede Menge Dazuerfindung von Iteratorwerten für Generatoren.
-
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>
-
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).
-
Aber Header und Cpp-Datei weiterhin geschrieben werden müssen?
und das hätte dann welchen Vorteil?
-
Artchi schrieb:
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.
-
TyRoXx schrieb:
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.
-
krümelkacker schrieb:
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 mitautooder kann man die einzelnen Typen auch explizit angeben?