Bonjour
 
Voilà, je recherche une classe permettant de représenter
un tableau de bits (éléments codés sur 1 bit et non en tant que booléen) et dont peut dynamiquement spécifier
la taille (bitset est, donc, exclus).
 
J'ai pensé à la classe <i>bit_vector</i> mais il paraît qu'elle sera éliminé de la STL.
 
En vous remerciant d'avance pour vos conseils.

bah y en a guère ca pose plein de probleme l'accés bit à bit du point de vue iterateur.
Ca se code pas trop mal à la main sinon

boost dynamic_bitset (pas d'itérateurs) ne conviendrait pas ? :x

c dispo dans la 1.34.1 ?

Sans aucun doute, ça a plusieurs années

ok j'avais pas vu, je note

Bonjour tout le monde
 
Je vous confirme bien que la classe dynamic_bitset convient tout à fait  
à mes besoins.
Pour l'utiliser je me suis donc télécharger la dernière version de Boost.  
Par contre, je me pose les questions métaphysiques suivantes :
 
1) pourquoi n'y a t-il pas de classe équivalente dans la STL ?
2) pourquoi avoir passé la taille du bitset en tant que paramètre de patron
 
En vous remerciant d'avance
 
 

1/ parce que
1/ parce que
 
c'ets le design qui est comme ça c'ets tout

d'abord

bah c'est vrai. LE rationale de la chose était ce qu'il était à l'époque. bit_set doit plus se voir comme un espèce de bit field objet qu'autre chose. D'où son aspect statique.

et vector<bool> ?
 
Oui je sais vector<bool> c'est le mal, c'est un container pourri avec de faux iterateurs tout ça, mais si on l'utilise en étant conscient de ses limites, ça peut faire un bon bitset dynamique sans avoir à se tapper boost.
 
J'ai rien contre boost mais qd je peux faire la même chose avec la STL qu'avec boost, je prends la STL.

vector<bool> c'ets qd meme bien la crap, meme les gens du standard le disent :s

il y a qlq pitfall, mais pour s'en servir spécifiquement comme un bitfield dynamique, ça fait l'affaire.
 
il faut juste savoir que l'operateur [] ne renvoie pas une référence de bool.
vector<bool> est un container dysfonctionnel, mais pas inutilisable.

Quand j'ai le choix entre STL et Boost, je prend Boost
je me retrouve pas avec 50 implémentations différentes ^^

ouais enfin std::string quoi :E

Si tu codes proprement, tu peux faire abstraction de l'implémentation de la STL.
De toute façon la STL définie juste une interface et un comportement, l'implémentation t'es même pas sencé t'en soucier.
 
Sans compter que dans boost il y a aussi des variantes d'implémentation à cause des comportements différents des compilos face aux templates.

 
d'un côté le problème se trouve sur une implémentation de la STL.
de l'autre côté sur un compilo (c'est pas comparable à mon avis) ou sur une unique librairie de boost qui fournira un workaround.
 
J'ai suivi les problèmes d'un gars qui codait un GC pour le c++ et qui se cognait la tête avec les implémentations de la STL.
 
Mais fondamentalement, j'ai rien contre la STL  

ouais en effet pour greffer un GC dans la STL on doit tenir compte de l'implémentation, mais c'est pas vraiment du dev ça, c'est du trifouillage technique. La STL actuelle ne garantie pas qu'on puisse y placer un GC (ça évoluera peut-être avec C++0x).
 
Pourquoi ton gards n'utile pas STLPort, c'est conçu pour acueillir un GC.
 
Par contre certaines implémentations de la STL sont dictées par les capacités du compilo à gérer les templates. Rien que std::pair n'est pas correctement implémentable sans les méthodes membres templates, et il y a qlq années tous les compilos ne les supportaient pas. Si la STL de Visual Studio 5 et 6 étaient si nulle, c'est en partie parce que VC supportait mal les templates.

Justement il dev un GC "générique", qui est censé marcher pour toutes les implémentations, et ça pose pb pour l'instant.
 
(de toute façon, vive le D >.< )

ah ouais qd même !
Et il compte le mettre open-free-gnu tout ça ?
 
Je me demande si c'est techniquement possible. La comme ça je me dis, s'il a besoin de regarder l'implémentation, et sachant qu'il y a une infinité d'implémentations qui évoluent comme elles le sentent, c'est impossible. Soit il utilise que du 100% standard (les allocator donc) et il n'a pas à regarder l'implémentation, soit il se restreint à qlq implémentations et ça sera pas générique.

eine grosse pluzun  

le D, qlq bonnes (le type bit, les typedef opaques...) et qlq mauvaises idées (pas d'héritatge multiple...).
 
Mais je dis + 1 si ça aurait pu remplacer le Java (même sur un VM) et l'implémentation est exemplaire : le mec a codé un très bon compilo C++ (histoire de pas être sectaire) et le compilo D produit aussi un très bon code.
 
Mais je n'aime pas le principe d'enlever des features car jugées trop complexes (donc comme l'héritage multiple). Les features complexes, déjà ça peut être utiles à ceux qui les maitrisent, à ceux qui codent des libs, et si tu ne sais pas, t'es pas obligé de t'en servir.
 
En C++, tu peux coder à ton niveau : en presque C, sans les templates, sans la STL, sans héritage multiple, sans RTTI...
Le langage ne t'impose rien et ne te freine pas.

 
C'est potentiellement le futur GC made in Boost  (Cf la mailing list Devel de boost de septembre 2007 il me semble, proto dispo implémenté en qqs centaines de lignes)
Il a essayé de suivre les recommandations pour gérer la STL mais la plupart des implémentations ne suivent pas "jesaisplusquel" principe au niveau de l'utilisation d'un membre donné "nécessaire" au GC (j'ai pas compris tous les détails, ca me dépasse généralement ^^)
 
Concernant l'héritage multiple, ça de discute.
 
j'aime bien les interfaces de cette façon : http://www.cdiggins.com/bil.html

 
Ben ça doit être les allocateurs justement, je ne vois que ça.
Sinon je vais jetter un coup d'oeil au GC de boost, ça me surprend un peu qu'ils soutiennet l'idée d'utiliser un GC
c'est pas trop dans le style.

Le problème c'est que pour le monde pro tu n'es pas sensé coder tout seul dans ton coin, tu codes souvent dans une équipe.

je ne suis pas non plus pour le nivellement vers le bas. Ce sont les autres qui doivent apprendre. De toute façon dans tout métier scientifique t'es sencé apprendre en continue toute ta vie.