Habemus C++14

[hustbaer]

Ach Leute, geht bitte Lisp programmieren anstatt hier sinnlos rumzunerven.
Danke.

[cooky451]

Networking haben sie wohl komplett aufgegeben, abgesehen von diesem URI Kram den niemand braucht.

[hustbaer]

braucht alles seine zeit.
vor allem gibts kaum was brauchbares an "prior art" - maximal noch ASIO, aber ob die so optimal wäre, weiss nicht.

wichtig ist dass sie jetzt in kürzeren abständen immer wieder was machen wollen, und dass die compiler/compiler-entwickler so weit sind dass sie die dinge auch in endlicher zeit integrieren können, also nicht immer jahrelang hinterherhinken.

[TyRoXx]

hustbaer schrieb:

braucht alles seine zeit.
vor allem gibts kaum was brauchbares an "prior art" - maximal noch ASIO, aber ob die so optimal wäre, weiss nicht.

ASIO würde ich so, wie es ist, auch nicht in den Standard übernehmen. io_service hat zu viele Aufgaben und wird an zu vielen Stellen benötigt. Die Sockets benötigen den auch, wenn man nur die synchronen Operationen benutzt.

Viele Teile von ASIO sind auch kaum sinnvoll standardisierbar, weil sie Windows- oder Posix-spezifisch sind oder bloß OpenSSL wrappen.

Um sinnvoll Daten durch die Gegend zu schieben bräuchte man auch noch so etwas wie iostream , aber in benutzbar. Dafür gibt es genau gar keine C++-Vorbilder.

Außerdem wären Coroutinen nicht schlecht. Dafür gibt es in Boost auch ein Vorbild. Hoffentlich setzen sich keine "resumable"-Schlüsselwörter oder so Blödsinn durch.

[hustbaer]

TyRoXx schrieb:

Hoffentlich setzen sich keine "resumable"-Schlüsselwörter oder so Blödsinn durch.

Huch?
Ich finde das wie es C# macht nett (yield return).

Das kann man einerseits als Generator und andrerseits als Coroutine verwenden.

[Scorcher24]

Was Networking angeht, sollte man IMHO libcurl(++) übernehmen. Jaja, ich weiss, wird nicht passieren und ist nicht nach dem standard designed, aber ich finds ehrlich gesagt eine sehr coole Library für Webzugriffe.

[woistdasplusplus]

Scorcher24 schrieb:

Was Networking angeht, sollte man IMHO libcurl(++) übernehmen. Jaja, ich weiss, wird nicht passieren und ist nicht nach dem standard designed, aber ich finds ehrlich gesagt eine sehr coole Library für Webzugriffe.

libcurl ist schön gemacht, aber gibt es ein akzeptables C++-Binding?

[Scorcher24]

woistdasplusplus schrieb:

Scorcher24 schrieb:

Was Networking angeht, sollte man IMHO libcurl(++) übernehmen. Jaja, ich weiss, wird nicht passieren und ist nicht nach dem standard designed, aber ich finds ehrlich gesagt eine sehr coole Library für Webzugriffe.

libcurl ist schön gemacht, aber gibt es ein akzeptables C++-Binding?

Ja, gibt es:
https://github.com/JosephP91/curlcpp

[woistdasplusplus]

Scorcher24 schrieb:

woistdasplusplus schrieb:

Scorcher24 schrieb:

Was Networking angeht, sollte man IMHO libcurl(++) übernehmen. Jaja, ich weiss, wird nicht passieren und ist nicht nach dem standard designed, aber ich finds ehrlich gesagt eine sehr coole Library für Webzugriffe.

libcurl ist schön gemacht, aber gibt es ein akzeptables C++-Binding?

Ja, gibt es:
https://github.com/JosephP91/curlcpp

Wenn ich das schon sehe: sinnloses virtual, curl_global_init bei jedem Konstruktoraufruf, nicht Threadsafe, wilder Exception-Missbrauch, Klassen alle mit curl_ gepräfixt obwohl in Namespace curl, using in Headern(!), etc.

[cooky451]

Mir würden standardisierte Sockets o.Ä. ja völlig reichen, ich brauche keine http oder web lib. Mit dem ganzen utility Kram können die sich ruhig Zeit lassen bis 2021*, aber atm kommt man mit Standard-C++ einfach nicht ans Netzwerk-Interface ran, was schon irgendwie traurig ist.

*jep, wo ich 2017 schon predicted habe kommt dann auch gleich die nächste enthüllung meiner magischen Glaskugel

[Kellerautomat]

Module koennen auch nicht so schwer sein, vor allem gibts seit Monaten (!) eine funktionierende (!) Implementierung in Clang, aber ich sehe genau NULL fortschritt in Richtung standardisierung.

[hustbaer]

Tjo die ham halt auch alle noch andere Sachen zu tun als sich um den Standard zu kümmern.
Das ist einerseits sehr gut, da sie dadurch den Bezug zur Praxis nicht verlieren und ne gute Basis haben überhaupt mitzureden.
Andrerseits bremst es natürlich, was weniger gut ist.

[Tyrdal]

Naja zu hohes Tempo ware jetzt auch nicht gut. Ich hinke ja ja schon wieder dem Standard hinterher.

[cooky451]

Der Unterschied ist dass Modules schon immer erst für C++17 angekündigt wurden, was verständlich ist weil sie viele Änderungen im Sprachteil des Standards benötigen, während "Networking TS" für 2014 geplant war. Na ja, aus dem "Networking TS" ist dann wohl eine Klasse für IPs geworden oder so...

[Bitte ein Bit]

Ich hinke ja ja schon wieder dem Standard hinterher.

Ich standardmäßig auch.

[hustbaer]

Tyrdal schrieb:

Naja zu hohes Tempo ware jetzt auch nicht gut. Ich hinke ja ja schon wieder dem Standard hinterher.

Hohes Tempo ohne Nebeneffekte wie schlechte Qualität?
Oh, da könnte C++ mMn. ein um ein vielfaches höheres Temp vertragen.
Guck dir bloss mal die Standard-Library anderer Sprachen wie Java, C# oder sogar Python, Ruby etc. an.

Was ich nicht braucht, da muss ich mich ja auch nicht sofort einlernen.
=> Immer her damit!

[Tyrdal]

Natürlich muss ich nicht alles sofort lernen, aber die Intervalle in denen die Compiler gewechselt werden sind ja doch recht lang. Das heißt je schneller die Entwicklung desto mehr hat man nicht. Außerdem sind zumindest in meinem Arbeitsbereich fast alle Bereiche schon von QT abgedeckt, so daß mir Sockets im Standard genausowenig nutzen würden wie jetzt Threads.