Frage

Ich bin reposting ein comp.std.c ++ Usenet Diskussion hier, weil diese Gruppe sehr unzuverlässig geworden ist. Die letzten Beiträge, die ich dort vorgelegt habe, haben ins Leere gegangen, und die Aktivität hat alle, aber nicht mehr. Ich bezweifle, dass ich habe verboten und / oder alle anderen nur das Interesse verloren. Hoffentlich alle interessierten Menschen werden diese Diskussion finden, und es wird eine allgemeine Migration sein. Vielleicht dann werden sie einen neuen Moderator ernennen.


Hallo!

Mit meiner aktuellen Auslegung des Entwurfs N3126 w.r.t. die bedingte Betreiber und XValues ??erwarte ich, dass die folgenden Aussagen zu halten:

 int i = 0;
 int& j = true? i : i;
 int&& k = true? std::move(i) : std::move(i);   // #2
 assert(&i == &j); // Holds since C++98
 assert(&i == &k); // Should this hold as well?

5,16 / 4 sagt:

  

Wenn die zweiten und dritten Operanden [zu   der bedingte Operator] ist   glvalues ??den gleichen Wert Kategorie   und haben die gleiche Art, ist das Ergebnis   diese Art und Wert der Kategorie [...]

Obwohl es nicht klar sagen, dass die resultierende glvalue bezieht sich auf eines der Objekte die glvalue Operanden bezeichnet - oder ist dies implizierte denn sonst wäre es eine prvalue zurückkehren? Mit GCC 4.5.1 in C ++ 0x-Modus schlägt die zweite Behauptung. Die Referenz k scheint beziehen sich auf einige temporäre Objekt. Kann jemand, ob die Klärung comiler erlaubt so im Falle einer vorübergehenden beide Operanden erstellen um den Doppelpunkt sind XValues ??vom gleichen Typ?

Ich bin derzeit davon aus GCC ist fehlerhaft und / oder nicht up-to-date in Bezug zu XValues.

Die Followup Frage: Wäre es nicht schön sein, um das erkennen Wertkategorie eines Ausdrucks? Wenn wir ignorieren den Bedingungsoperator wir können den Wert der Kategorie eines Ausdrucks mit decltype erkennen. Aber was ist

 bool xvalue = std::is_rvalue_reference<
   decltype( true ? std::move(i) : std::move(i) ) >::value;

soll Ausbeute? Mit GCC 4.5.1 wird die xValue Variable initialisiert mit false. Ist dies den aktuellen Standard Entwurf konform?

TIA, Sebastian

War es hilfreich?

Lösung

Ich denke, GCC 4.5.1 ist nicht-konforme WRT §5.16 / 4. Haben Sie einen Fehlerbericht eingereicht?

Wie auch immer, ich denke, es mit dem ternären Operator Code entspricht. decltype wird durch §7.1.6.2 / 4 definiert:

  

Der Typ von decltype (e) bezeichnet ist   wie folgt definiert:

     
      
  • , wenn e ein unparenthesized id-Ausdruck oder ein Klassenmitglied Zugang   (5.2.5), decltype (e) ist die Art von   die per E benannte Einheit. Wenn es keine   diese juristische Person, oder wenn e Namen eine Reihe von   ladenen Funktionen, das Programm   schlecht ausgebildet sind;
  •   
  • sonst, wenn e ein Funktionsaufruf (5.2.2) oder eine Anrufung eines   überladener Operator (Klammern   um e ignoriert werden), decltype (e)   der Rückgabetyp der statisch   gewählte Funktion;
  •   
  • sonst, wenn e ein L-Wert, decltype (e) T &, wobei T der Typ   von e;
  •   
  • andernfalls decltype (e) ist die Art von E. Der Operand des decltype   Spezifizierer ist ein Operand unevaluierten   (Ziffer 5).
  •   

decltype funktioniert, indem die entsprechende Erklärung zu holen und den gewünschten Typ von ihm zurückkehrt. Es hat wenig Intelligenz in Bezug auf nicht-überladene Operatoren. Vielleicht ein weiterer Punkt

  • sonst, wenn e ein xValue, decltype (e) T&&, wo T ist die Art der e

wäre in Ordnung, zumal, wie geschrieben, XValues ??als prvalues ??behandeln lassen. Darüber hinaus Ihr Ausdruck entspricht genau die Definition von std::common_type (§20.7.6.6 / 3).

Eine einfache Abhilfe (ein Begriff Münze: vP):

template< typename T1, typename T2 >
struct common_type_and_category {
    typedef typename std::conditional<
        std::is_same< T1, T2 >::value,
        T1,
        typename std::common_type< T1, T2 >::type
    >::type type;
};
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top