Was sind eure Highlights von C++14?

Sone

/blitzmerker/ schrieb:

Sone schrieb:

In welcher Situation ist man von der storage duration nicht abhängig, hat aber einen Vorteil wenn die Elemente auf dem Stack landen?

Einfach süß

Das ist ja Blödsinn. Nein, der Stack ist ja performanter, hab' ich wieder außen vorgelassen. Kopf->Tisch.

Sone schrieb:

Ich habe immer noch dieselbe Meinung darüber - prinzipiell nur Syntaxzucker, nichts weiter. Trotzdem mag ich es und es hätte mich gefreut, würde es angenommen werden.

Ne, :=: wäre idiotisch. Heute ist man soweit, dass man beim Ausdruck swap(a, b) mit ADL schon sehr viele swap-Funktionen tatsächlich aufrufen kann. Käme hier :=: dazu, hat man für die genau gleiche Funktionalität völlig unnötigerweise zwei verschiedene Schreibweisen und hätte mehr Mühe, generischen Code zu schreiben.

Manchmal überlegen sich Leute rein gar nichts, wenn sie Proposals liefern.

krümelkacker schrieb:

und noch ein using std::swap; davor, damit auf std::swap zurück gefallen werden kann, wenn es keine spezielle Version für einen bestimmten Typen gibt, die per ADL auffindbar ist.

Oder:

template <typename T>
void adl_swap(T& lhs, T& rhs)
{
    using namespace std;
    swap(lhs, rhs);
}

Vielleicht noch perfect forwarden. using namespace std statt using std::swap deswegen, weil die swap-Funktion dann zu dem Zeitpunkt noch nicht deklariert sein muss. Oder muss sie das ohnehin?

Ethon_ schrieb:

N3574 - Binding stateful functions as function pointers

Gehts hier um Lambdas mit Variablen in der Capture-List? Falls ja, wie soll das vernünftig implementiert werden?

<>

camper

glühbirne schrieb:

using namespace std statt using std::swap deswegen, weil die swap-Funktion dann zu dem Zeitpunkt noch nicht deklariert sein muss. Oder muss sie das ohnehin?

Das ergibt keinen Sinn. Eine Deklaration innerhalb des Templates ist nicht erforderlich, und wenn man viel Glück hat enthalten umliegende Namensräume keine swap-Deklarationen, die keine Funktionen sind. Falls doch, hat man ein Problem, dann ist das kein Funktionsaufruf mehr (jedenfalls nicht der einer Funktion namens swap, sondern ggf. ein Konstruktoraufruf (Typ gefunden), oder ein Aufruf eines überladenen ()-Operators (Objekt mit Namen swap)) - und dann findet auch kein ADL bei der Instantiierung statt. Also ist es besser, eine swap-Deklaration im Scope zu haben, die garantiert eine Funktion deklariert.

krümelkacker

Sone schrieb:

Was ist der Sinn von** std::array **, wenn es schon richtige Arrays gibt?

Wo ist der Sinn von VLAs wenn's doch std::dynarray gibt? Aber im Vergleich zu rohen Arrays und std::array bietet die Präsenz von VLA als auch dynarray eine gewisse Konsistenz bzgl. zwei Mittel für eine Sache anzubieten. Supi. Ich weiß nicht, kommt mir halt doppelt-gemoppelt vor. rohe Arrays und std::array ist ja nur so gewachsen. Ist das Grund genug, VLAs zusätzlich zu dynarray anzubieten?

knivil

Kellerautomat schrieb:

Man kann die Funktion auch einfach in eine State-Maschine transformieren, so wie das ein C# Compiler mit async/await auch macht. Das hat dann gar keinen Overhead.

Ich wuerde im ersten Schritt auf bekanntes abbilden, genau wie std::thread auf POSIX-Threads unter Linux aufbaut anstatt die entsprechenden syscalls zu benutzen. Desweiteren sehe ich Probleme, wenn ein yield innerhalb von verschachtelten Schleifen oder rekursive Funktionen aufgerufen wird. Ein endlicher Automat wird nicht ausreichen.

Edit: Mal abgesehen davon, dass setcontext für Context-Switching gar nicht mal nötig ist. Das kann man problemlos mit Assembler machen, siehe z.B. boost.context.

Man kann alles mit Assembler machen. What's the point?

Ethon

glühbirne schrieb:

Ethon_ schrieb:

N3574 - Binding stateful functions as function pointers

Gehts hier um Lambdas mit Variablen in der Capture-List? Falls ja, wie soll das vernünftig implementiert werden?

<>

Jap, so ähnlich - zb. um Lambdas mit Capture-List als C-Funktionszeiger verwenden zu können. Die einzige Möglichkeit die mir einfällt:

Dynamisch zur Laufzeit einen ausführbaren Speicher allozieren und da (Assembler) Code reinschreiben, der die C-Calling Convention respektiert, die Parameter entgegennimmt und das Funktionsobjekt mit ihnen aufruft.

Ist mit libffi closures ganz easy machbar, libffi übernimmt den ganzen Lowlevel-Kram.

Cyres

krümelkacker schrieb:

Cyres schrieb:
Frage_Swap schrieb:

Wie würde man sowas machen, also ohne den Operator?
swap(a, b)
und noch ein using std::swap; davor, damit auf std::swap zurück gefallen werden kann, wenn es keine spezielle Version für einen bestimmten Typen gibt, die per ADL auffindbar ist.

und noch ne Klasse, und noch Member, und noch ne Methode und und und...

krümelkacker

Cyres, wenn du das schon gegenüberstellen willst, dann richtig!

x :=: y;

versus

using std::swap;
swap(x,y);

Denn wir können sicher erwarten, dass :=: auch für eingebaute Typen funktionieren wird, was du für swap eben nur mit std::swap bekommst.

Mussu gar nicht beleidigt sein. :p

Kellerautomat

knivil schrieb:

Ich wuerde im ersten Schritt auf bekanntes abbilden, genau wie std::thread auf POSIX-Threads unter Linux aufbaut anstatt die entsprechenden syscalls zu benutzen. Desweiteren sehe ich Probleme, wenn ein yield innerhalb von verschachtelten Schleifen oder rekursive Funktionen aufgerufen wird. Ein endlicher Automat wird nicht ausreichen.

Worauf etwas aufbaut, ist vollkommen irrelevant. Von Automatentheorie habe ich keine Ahnung, aber in C# funktionierts offenbar, also haben die das irgendwie geloest.

knivil schrieb:

Edit: Mal abgesehen davon, dass setcontext für Context-Switching gar nicht mal nötig ist. Das kann man problemlos mit Assembler machen, siehe z.B. boost.context.

Man kann alles mit Assembler machen. What's the point?

Es ist voellig egal, wie es implementiert ist. Man braucht dazu jedenfalls nicht von einer deprecateten API abhaengen.

phlox81

krümelkacker schrieb:

Jens Weller hat anscheinend in seiner Artikel-Serie auch viele Porposals verarbeitet, die nicht im C++14 Entwurf gelandet sind. Mir stellt sich die Frage, was davon wirklich im C++14 Entwurf gelandet ist. Ist dies hier eine vollständige Liste der "core language features"?

Die Serie enthält nur die Papers welche Teil des Bristol mailings selbst waren, in Bristol wurden aber auch Papers des Januar Mailings besprochen. Und ich habe den (wahnsinnigen) Ansatz gehabt, alle papers zusammenzufassen.

Und da C++14 momentan noch im Entwurf ist, gibt es auch keine Liste der core features. Es wird wohl C++14 sein, aber was drin ist, zeigt bisher nur der Draft nach Bristol. Ob und was sich in Chicago noch ändert muss man sehen, der Trend geht wohl dazu dass C++14 von einigen TS begleitet wird, also Dingen, die es nicht in den Standard geschafft haben. Wie z.b. filesystem, concurrency, concepts oder networking. Wie (und ob) diese TS für compiler umgesetzt werden, muss man abwarten. Ich halte vorallem filesytem für wahrscheinlich, auch wenn es sicher nicht offiziell Teil von C++14 wird.

krümelkacker schrieb:

Und dann gibt's in der Standardbibliothek natürlich mindestens noch make_unique als neues Feature. Was noch? Sind die Typ-Transformations-Aliase auch dabei?

C++14 hat neben den Bugfixes für C++11 evtl. noch einige kleinere Features wie obiges, ich denke dass man darüber nach Chicago besser bescheidt weiss.

knivil

Worauf etwas aufbaut, ist vollkommen irrelevant. Von Automatentheorie habe ich keine Ahnung, aber in C# funktionierts offenbar, also haben die das irgendwie geloest.

Immer diese Schwachsinnsargumentation. Scheme hat Continuations (haben die ja auch irgendwie geloest) trotzdem passen sie nicht ins Konzept von C++.