C++0x doch ohne Concepts

> std::bind, std::function, std::tuple

Lol, die braucht man genauso oft^^

Badestrand

Eggy schrieb:

im neuen c++ ist so viel mist drin, den man nie braucht.

So oder so ähnlich:

vector<int> vals = { 1, 2, 3, 4, 6 };

auto is_smaller_than_three = [] (int i)->bool
{
	return i<3;
}

vals.erase( remove_if( vals.begin(), vals.end(), is_smaller_than_three ) );

Statt:

vector<int> vals;
vals.push_back( 1 );
vals.push_back( 2 );
vals.push_back( 3 );
vals.push_back( 4 );
vals.push_back( 5 );
vals.push_back( 6 );

struct IsSmallerThanThree
{
    bool operator()( int i )
    {
        return i<3;
    }
};

vals.erase( remove_if( vals.begin(), vals.end(), IsSmallerThanThree() ) );

Eggy schrieb:

> std::bind, std::function, std::tuple

Lol, die braucht man genauso oft^^

Verwechsel mal nicht "man" und "du"...

Beispiel:

template <class T> swap(T& a, T& b)
    {
        T tmp(a);   // now we have two copies of a
        a = b;      // now we have two copies of b
        b = tmp;    // now we have two copies of tmp (aka a)
    }

  // Rvalue:

    template <class T> swap(T& a, T& b)
    {
        T tmp(std::move(a));
        a = std::move(b);   
        b = std::move(tmp);
    }

Toll, was ist daran jetzt besser? Wir erstellen immernoch 3 Objekte, selber Verbrauch wie vorher, die Objekte sind dabei höchstens leer nach jedem move .

Hä? schrieb:

// Rvalue:
    template <class T> swap(T& a, T& b)
    {
        T tmp(std::move(a));
        a = std::move(b);   
        b = std::move(tmp);
    }
Toll, was ist daran jetzt besser? Wir erstellen immernoch 3 Objekte, selber Verbrauch wie vorher, die Objekte sind dabei höchstens leer nach jedem move

"selber Verbrauch" stimmt nicht. Denk an Klassen, die Resourcen kapseln (wie zB vector). Die Objekte an sich sind klein (3 Pointer zum Beispiel) aber eine Kopieroperation kann trotzdem teuer sein, weil eventuell ein dickes Array (wie bei vector) neu angelegt und kopiert werden muss. Mit

T tmp(std::move(a));

sagst Du, dass das Kopieren destruktiv bzgl der Quelle sein darf ("move construction" erlaubt). Für Typen, wie vector bedeutet das, dass einfach die Zeiger umgebogen werden können, ohne das Speicher neu angefordert werden muss oder Elemente kopiert werden müssen.

Gruß,
SP

Hä? schrieb:

Toll, was ist daran jetzt besser?

Ich sehe gerade, dass das, was ich geschrieben habe auch in etwa in der Einführung steht:

This move() gives its target the value of its argument, but is not obliged to preserve the value of its source. So, for a vector, move() could reasonably be expected to leave its argument as a zero-capacity vector to avoid having to copy all the elements. In other words, move is a potentially destructive read.
[...]
The first task of rvalue references is to allow us to implement move() without verbosity, or rutime overhead.

Wer lesen kann ist klar im Vorteil...

Gruß,
SP

Heißt es dann so: ?

string b = "xxx";
string &a = b; // a = b = "xxx"
string &&c = b; // c = b = a = "xxx"
string x = c; // x = "xxx", c = "" ?????

Ist am Ende c dann leer oder was ist dann in c?

Hä? schrieb:

Heißt es dann so: ?
string b = "xxx";
string &a = b;    // a = b = "xxx"
string &&c = b;   // c = b = a = "xxx"
string x = c;     // x = "xxx", c = "" ?????
Ist am Ende c dann leer oder was ist dann in c?

Die Einführung ist nicht 100% auf den letzten Stand. Die Regeln wurden leicht geändert. Deine 3. Zeile kompiliert nicht mehr. Du kannst keine Lvalues an Rvalue-Referenzen binden. Dave Abrahams's "Rvalue References 101" ist aktueller und sehr ausführlich.

Zu Deiner Frage: Lies Dir diesen Abschnitt durch.

Bevor Du die nächste Frage stellst, lies Dave's Artikel 2mal komplett und konzentriert durch. Es steht wirklich alles dort....

Gruß,
SP

Sebastian Pizer schrieb:

Bevor Du die nächste Frage stellst, lies Dave's Artikel 2mal komplett und konzentriert durch. Es steht wirklich alles dort....

Nicht, dass Du mich falsch verstehst: Keiner sagt, dass Rvalue-Referenzen leicht zu verstehen sind. Deswegen frag ruhig, wenn Dir etwas unklar ist. Aber frag nicht, wenn Du einfach nur zu faul zum Lesen bist.

Nexus

Neben den grossen Neuerungen wie Variadic Templates, RValue-Referenzen und Lambda-Ausdrücke finde ich auch viele kleinere Dinge sehr nützlich, zum Beispiel Initialisierungslisten, constexpr , neue enum s und static_assert (wird einige Templatefehlermeldungen sicher auch schon besser lesbar machen).

Allerdings finde ich, mit der "einheitlichen" Initialisierung haben sie übertrieben. Dass die Initialisierungsliste implizit für Konstruktoraufrufe verwendet werden kann, gefällt mir nicht. So ist nämlich für eine Klasse, die keinen Initialisierungslistenkonstruktor anbietet, Folgendes möglich:

std::fstream file = {"file.txt", std::ios_base::out};

Beim std::vector hingegen wird hier nicht der Konstruktor aufgerufen, der 4 Elemente mit Startwert 3 setzt, sondern der mit der Initialisierungsliste:

std::vector<int> v = {4, 3};

In meinen Augen ist das nicht sehr konsistent. Mir wäre es lieber, man könnte Initialisierungslisten höchstens explizit für Konstruktoraufrufe benutzen (evtl. durch auto oder sowas wie std::construct(std::initializer_list) ).

Dass man das = in den oberen Fällen auch weglassen kann, halte ich ausserdem für unnötig und zudem auch hässlich, diese Schreibweise werde ich wohl kaum verwenden. Hat die irgendwelche Vorteile? Ich meine:

std::vector<int> v {4, 3};

P.S.:

Badestrand schrieb:

So oder so ähnlich: [...] Statt: [...]

Du hast nicht mal Lambda-Ausdrücke benutzt! Schäm dich!

hustbaer

Nexus schrieb:

P.S.:

Badestrand schrieb:

So oder so ähnlich: [...] Statt: [...]

Du hast nicht mal Lambda-Ausdrücke benutzt! Schäm dich!

'Türlich hat er nen Lambda-Ausdruck benutzt, bloss nicht inline. Was ich auch etwas komisch finder, aber naja.

Nexus

hustbaer schrieb:

'Türlich hat er nen Lambda-Ausdruck benutzt, bloss nicht inline. Was ich auch etwas komisch finder, aber naja.

Stimmt, hab ich beim Überfliegen für eine Funktion gehalten. Und ich würds auch eher inline machen...

Hier ist der comp.std.c++-Thread zum Thema. Hier ein paar Zitate daraus:

Pete Becker schrieb:

Joe Gottman schrieb:

Dos this mean that the new loop is gone as well?

No.

Doug Gregor schrieb:

The new for loop will still be in C++0x, with the same syntax. The
actual implementation of the new for loop will be based on argument-
dependent lookup rather than concepts, but the user experience will be
almost the same. The actual details will be in the post-Frankfurt
mailing, in document number N2930.

Rodolfo Lima schrieb:

Joe Gottman schrieb:

Dos this mean that the new loop is gone as well?

I don't think so. At least they're trying to implement the new for
loop based on ADL of begin/end functions. More info at:
Blog entry by Michael Wong at ibm.com

Steven Clamage schrieb:

The Committee voted to remove concepts from the version of the standard
now being worked on because we estimated it would take at least 2 more
years, and possibly 5, to complete the work and publish.

With many other desirable features ready to go, and with the current
standard already more than 10 years old, that seemed too long a delay.

The choice was difficult, and nobody was happy about having to drop
concepts, but the alternatives -- 5 years delay or standardizing an
unusable version of concepts -- were far worse.

Removing concepts will take some time, so the publication date of the
new standard might slip by 3 months or so, due specifically to the
removal of concepts. As Beman noted in an earlier message, we had to
lengthen our schedule still more for other reasons.

The Committee still wants concepts in C++, and will continue developing
it in anticipation of the next update of the standard.

Sorry, dass ich so penetrant auf meinen eigenen Beitrag hinweise, aber dieser ist hier irgendwie untergegangen(und die Antwort interessiert mich brennend )

Matzer schrieb:

volkard schrieb:

ich hätte gerne Zugriff auf den Parsebaum und würde ihn frei ummodeln können....

Kann mir jemand vielleicht kurz erläutern, in welcher Form sich der Zugriff auf den Parserbaum hinsichtlich der Sprachfeatures auswirken würde? Welchen "Mehrwert" hätte man zu erwarten, falls dies gestattet wäre? Ich hab leider nicht allzu viel Ahnung was das Parsen angeht, bin mir also der Auswirkungen nicht ganz bewusst.

Und wie sieht dieser Zugriff auf den Parserbaum in Sprachen aus, die soetwas verwirklichen?

Walli

Ich habe heute einen Vortrag von Michael Wong gehoert und da hat er genauer erlaeutert, warum es rausgeflogen ist. Ich war auch relativ ueberrascht. Hauptsaechlich hatten sie die Komplexitaet wohl nicht mehr vernuenftig im Griff. Ganz aufgegeben wurden die Concepts IIRC wohl nicht, nur auf ein Erscheinen in C++0x wird man wohl nicht mehr hoffen koennen. Die Timeline sieht wohl mittlerweile so aus, als sei x >= B. Er scherzte, dass man sich auch offen behaelt auf Basis 24 zu wechseln wenn es noetig sei .