‘class std::vector<bool>’ has no member named ‘emplace_back’

[but why]

Die eigentliche Frage ist doch, wieso bietet vector<bool> kein emplace_back an?

[volkard]

but why schrieb:

Die eigentliche Frage ist doch, wieso bietet vector<bool> kein emplace_back an?

wieder ein ballmer peak?

[Columbo]

volkard schrieb:

but why schrieb:

Die eigentliche Frage ist doch, wieso bietet vector<bool> kein emplace_back an?

wieder ein ballmer peak?

Nein, sie haben Herr Bebel vor kurzem entlassen - habt ihr das nicht mitbekommen?

Es dachten die Experten vom Komitee, dass ein emplace_back für vector<bool> prinzipiell unnötig ist (Perfect Forwarding ist für bool ja tatsächlich Überflüssig).

[volkard]

Arcoth schrieb:

volkard schrieb:

but why schrieb:

Die eigentliche Frage ist doch, wieso bietet vector<bool> kein emplace_back an?

wieder ein ballmer peak?

Nein, sie haben Herr Bebel vor kurzem entlassen - habt ihr das nicht mitbekommen?

Es dachten die Experten vom Komitee, dass ein emplace_back für vector<bool> prinzipiell unnötig ist (Perfect Forwarding ist für bool ja tatsächlich Überflüssig).

Naja, das Statement ist immernoch besser als der ganze Code, den Du nüchtern produzierst.

[decimad]

Die Spezialisierung radikal auskommentieren in der STL! Ohne wenn und aber, hier wird kurzer Prozess gemacht! Und dann dynamic_bitset hernehmen, um den ganzen boost-Firlefanz erleichtern, namespace anpassen und in den STL-Ordner schieben! Problem gelöst!

[Columbo]

volkard schrieb:

Naja, das Statement ist immernoch besser als der ganze Code, den Du nüchtern produzierst.

video meliora proboque, deteriora sequor.

Edit:

Die Spezialisierung radikal auskommentieren in der STL! Ohne wenn und aber, hier wird kurzer Prozess gemacht!

Ja, das ist eine Möglichkeit. Bloß nicht, dass dann aber merkwürdige Fehler in anderen Stellen anderer Header kommen.

[decimad]

In welchen genau, ich hab's jetzt noch nicht probiert? Ich denke die Menge an zerstörtem Code, global gesehen, würde sich in überschaubarem Rahmen halten, aber ist nur so eine Vermutung. Und derjenige, der den Code geschrieben hat, hat's ja auch verdient... Wenn ich nen bitset haben will, dann nehme ich auch eins.
Wenn man den "Tag des vector<bool>" einführt, könnte man zudem auf die Problematik hinweisen.

[otze]

Arcoth schrieb:

Und der überladene Operator gibt dann wieder eine Referenz auf bool zurück?

du hast mehr oder weniger verstandn warum ich geschrieben hab: "nicht so knorke" aka: "Löst das Problem nicht" aka "verschiebt das Problem nur ein Ebene höher"

[ScottZhang]

mal nicht so unkreativ, die Rede war von austauschen

template<class T>
class MyClass{
    typedef typename std::conditional<std::is_same<T,bool>::value, char, T>::type value_type;
//...
    value_type& operator[](std::size_t i){
        return elements[i];
    }
private:
    std::vector<value_type> elements;
};

[otze]

otze schrieb:

aka "verschiebt das Problem nur ein Ebene höher"

Jetzt muss halt der Benutzer von MyClass damit zurechtkommen, dass er keine bool& kriegt...

//edit nene, wenn typumleitung, dann auf einen anderen Container.

[nordumfahrung]

otze schrieb:

//edit nene, wenn typumleitung, dann auf einen anderen Container.

Oder einfach

struct not_a_bool { bool value; operator bool&(){return value;} };

[ScottZhang]

otze schrieb:

otze schrieb:

aka "verschiebt das Problem nur ein Ebene höher"

Jetzt muss halt der Benutzer von MyClass damit zurechtkommen, dass er keine bool& kriegt...

//edit nene, wenn typumleitung, dann auf einen anderen Container.

Ich dachte bool und char sind implizit konvertierbar?

[Columbo]

Ja, aber nicht die Referenzen. Und das aus gutem Grund.

[ScottZhang]

Ah ok. Verätst du den Grund noch?

[Columbo]

ScottZhang schrieb:

Ah ok. Verätst du den Grund noch?

Der wichtige Grund ist: Ein bool muss nicht zwangsläufig so groß sein wie ein char . Ist es zwar praktisch immer, muss es aber nicht sein. Das ist besonders wegen Alignment wichtig.

Außerdem ist die Werte-Repräsentation von bool / char auch implementationsspezifisch, denn es ist nicht klar festgelegt, welche Bits gesetzt sein müssen, damit ein bool den Wert true hat.*

Verstehe mich nicht falsch, ich spreche hier vom Standard. In der Praxis dürfte das vielleicht funktionieren.

* Der Standard sagt hier lediglich

The representations of integral types shall define values by use of a pure binary numeration system⁴⁹. ( this International Standard permits 2’s complement, 1’s complement and signed magnitude representations for integral types. )
[...]
⁴⁹~A positional representation for integers that uses the binary digits 0 and 1, in which the values represented by successive bits are additive, begin with 1, and are multiplied by successive integral power of 2, except perhaps for the bit with the highest position.~

Welchen Wert jedoch true und false in dieser Repräsentation haben, ist undefiniert.

[alone ment]

Arcoth schrieb:

Der wichtige Grund ist: Ein bool muss nicht zwangsläufig so groß sein wie ein char . Ist es zwar praktisch immer, muss es aber nicht sein. Das ist besonders wegen Alignment wichtig.

Wieso ist die Grösse besonders wegen dem Alignment wichtig?

Außerdem ist die Werte-Repräsentation von bool / char auch implementationsspezifisch, denn es ist nicht klar festgelegt, welche Bits gesetzt sein müssen, damit ein bool den Wert true hat.*

Inwiefern ist das relevant?

Die zwei einzigen Gründe ist Grösse und Alignment.

[Columbo]

alone ment schrieb:

Arcoth schrieb:

Der wichtige Grund ist: Ein bool muss nicht zwangsläufig so groß sein wie ein char . Ist es zwar praktisch immer, muss es aber nicht sein. Das ist besonders wegen Alignment wichtig.

Wieso ist die Grösse besonders wegen dem Alignment wichtig?

Die Größe kann das Alignment beeinflussen, und das Alignment darf nicht größer sein als die Größe (formuliere ich das jetzt richtig?).
Sind sowohl bool als auch char ein Byte groß, dann sollten Objekte vom Typ bool oder char auf jeder beliebigen Adresse alloziert werden können.

Außerdem ist die Werte-Repräsentation von bool / char auch implementationsspezifisch, denn es ist nicht klar festgelegt, welche Bits gesetzt sein müssen, damit ein bool den Wert true hat.*

Inwiefern ist das relevant?

Das ist gar nicht so relevant. Wollte nur unterstreichen: Falls du eine Referenz von char auf eine Referenz auf bool castest, dann wird der Wert des lvalues möglicherweise nicht derselbe sein wie bei einer Konvertierung von char nach bool . Dann wird vielleicht 1 zu false .