Habemus C++14

audacia

Kellerautomat schrieb:

Ich schlage vor:
[] (x, y) { doStuff(x, y); }
Aber ne, die muessen da wieder ein vollkommen unnoetiges auto reinpacken.

Vermutlich, weil du normalerweise eh const auto& x willst und nicht auto x . Warum also die Syntax für pass by value optimieren?

Kellerautomat

audacia schrieb:

Kellerautomat schrieb:
Ich schlage vor:
[] (x, y) { doStuff(x, y); }
Aber ne, die muessen da wieder ein vollkommen unnoetiges auto reinpacken.
Vermutlich, weil du normalerweise eh const auto& x willst und nicht auto x . Warum also die Syntax für pass by value optimieren?

[] (const& x, const& y) { doStuff(x, y); }

und nu?

audacia

Kellerautomat schrieb:

[] (const& x, const& y) { doStuff(x, y); }

und nu?

Stimmt, das geht. Mir gefällt nicht, daß ich dann auch

[] (&x, *y, **&z)

schreiben kann. Aber einen formalen Einwand habe ich nicht.

volkard

Kellerautomat schrieb:

audacia schrieb:
Kellerautomat schrieb:
Ich schlage vor:
[] (x, y) { doStuff(x, y); }
Aber ne, die muessen da wieder ein vollkommen unnoetiges auto reinpacken.
Vermutlich, weil du normalerweise eh const auto& x willst und nicht auto x . Warum also die Syntax für pass by value optimieren?
[] (const& x, const& y) { doStuff(x, y); }
und nu?

Gleich überall Typnamen weglassen dürfen, wo der Compiler sie sich basteln kann?

//irgendwo außerhalb einer funktion
sum(x,y){
   return x+y;
}

kann nur eine funktionsdefinition sein, muss zum template werden, alles geht automatisch.
besser noch, das dumme return auch weglassen, es wird immer der befehl returnt, und wer tatsächlich mal den ungewöhnlichen fall hat, daß er void return will, kann auch ganz einfach erzwingen.

//irgendwo außerhalb einer funktion
sum(x,y){
   x+y;
}

//irgendwo außerhalb einer funktion
add(x,y){
   x+=y;
   ;//oder "return;" oder "{}"
}
//natürlich wird x automatisch per referenz übergeben, weils sonst keinen sinn ergibt.

für einzeiler braucht man natürlich keine geschweiften klammern, das wird dann endlich konsistent zu if/for/while und so.

sum(x,y)
  x+y;

nee, ich bin froh, manchmal noch ein auto zu sehen. viel mehr wie "so ein destruktor wird automatisch aufgerufen, ohne, daß was im code steht" sollte nicht stillschweigend passieren. c++11 ist da schon arg übertrieben.

Columbo

typename std::enable_if<std::is_same<T, typename std::remove_reference<U>::type>::value, T>::type // #2

std::enable_if_t<std::is_same<T, std::remove_reference_t<U>>{}, T> // #3 (C++14)

und nu?

Defaultmäßig sollte auto&& als placeholder-Typ verwendet werden, genau wie bei terse range-based for loops (-std=c++1z bei Clang ):

for (a : {1, 2, 3})
    std::cout << a;

Demnach sollte

[] (a, b) {}

äquivalent sein zu

[] (auto&& a, auto&& b) {}

Ich finde im Übrigen

#define var auto&&

ganz praktisch.

Also, in Rust machen die das mit den Closures so, dass der Typ hergeleitet wird:

fn call(dings: int, bums: |int|) {
    bums(dings);
}

fn main() {
    call(23, |x| {
        //   ^^^
        // Typ von x muss ich hier nicht angeben
        println!("x ist {}", x);
    });
    println!("x ist {}", x);
}

Das ist doch auch eine nette Lösung. Vielleicht lässt sich das ja nach C++ übertragen, wenn Concepts kommen:

template<class Func> where Callable<Func(int)>
void call(int dings, Func bums) {
    bums(dings);
}

int main() {
    call(23, [](x){
        std::cout << "x ist " << x << std::endl;
    });
}

Also: Statt auto , auto const& oder auto&& einfach das nehmen, das der Aufrufer erwartet. (?)

Kellerautomat

audacia schrieb:

Kellerautomat schrieb:
[] (const& x, const& y) { doStuff(x, y); }
und nu?
Stimmt, das geht. Mir gefällt nicht, daß ich dann auch
[] (&x, *y, **&z)
schreiben kann. Aber einen formalen Einwand habe ich nicht.

Schreibst es ja auch falsch.

[] (& x, * y, **& z)

@volkard: Ich stimme dir in keinem einzigen Punkt zu. Je kuerzer, desto besser.

@Arcoth: #3 kommt an #1 auch nicht ran. Das tolle an Makros ist, dass man die std-Traits garnicht aus dem std-namespace holen muss, um sie ohne std:: verwenden zu koennen. Und mit einem #undef Header kann man die Makros auch wieder wegraeumen. Makros > all

Zu Lambdas: Ob das nun per default auto oder auto&& heisst, ist ne ganz andere Frage und mir nicht so wichtig. Hauptsache kurz.

volkard

Kellerautomat schrieb:

Je kuerzer, desto besser.

<°)))o>< <°)))o>< <°)))o><

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.

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

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.