[FAQ] vector<bool>, spécialisation du standard

Bonjour,

En programmant sur mon projet, je me suis heurté à une spécificité de la STL que j'ai trouvé pour le moins étrange. En utilisant un vector<bool>, je pensais pouvoir récupérer le premier élément en faisant ceci: &vec[0], cependant le standard en a décidé autrement et je pensais qu'il était utile de le spécifier dans la FAQ.

"vector<bool>"

Le standard de la norme de C++ a décidé d'optimiser le stockage des booléens dans un std::vector. Ainsi ne vous attendez pas à pouvoir récupérer facilement le un std::vector<bool> via &vec[0]. En effet, ce dernier garde en mémoire les booléens bits à bits.

Il est possible de passer au travers de cette optimisation plus ou moins bancale (cela peut créer des comportement indéterminés dans les programmes pour ceux qui ne savent pas), vous pouvez spécifier un nouvel allocateur en faisant:
typedef std::vector<bool, myallocator> vectorbool;


Bon j'espère que vous trouverez aussi cette information utile, et j'espère qu'elle n'y est pas déjà! Pour plus d'information: Lien

Oui, Sutter traite de ceci sur GotW. :ccool:

Les optimisation aporté à vector<bool> font qu'il n'a pas la sémantique de conteneur attendue comme chez les autres, notamment ce que tu essayes de faire.

De mémoire, ce qui est vraiment retourné par les opérateur d'accés n'est pas un bool mais une sorte de proxy entre le conteneur et les bool (avec un opérateur de transtypage vers bool), ce qui peut produire des comportement différent des autres conteneurs si l'on utilise des pointeurs.

A vérifier sur GotW, il est possible que j'ai mélangé avec d'autre articles :aie:

Oui c'est un proxy qui est retourné. Ce qui fait de lui un conteneur *batard*. Marqué comme deprecated dans la prochaine norme. (me semble).

Citation:

---

Envoyé par Goten

Marqué comme deprecated dans la prochaine norme. (me semble).

---

Actuellement, son état est : Oui, il est cassé, on pourrait soit le faire sans cette "optimisation", soit modifier des choses pour que cette "optimisation" marche bien (une action dans ce sens avait été fait, mais elle éttait dans le contexte des concepts...). Mais en pratique, l'option 1 pourrait casser du code existant en termes de perfs, et il est trop tard pour mettre en place l'option 2. Il restera donc probablement cassé.