Dire que les champs de bits ont des avantages cachés est malheureusement très loin de la vérité selon moi, il vaudrait mieux exprimer les inconvénients cachés de leur utilisation.
Pour répondre à votre question, oui, bien sûr, vous pouvez écrire vos propres algorithmes pour traiter ces champs de bits de longueur arbitraire comme quelque chose de complètement différent.
Bien qu'il n'existe pas de méthode pour obtenir la longueur du champ m_bitfield1 (en utilisant une macro ou autre), vous devrez en assurer vous-même le suivi.
À titre d'information, rien ne dit que la structure ci-dessous aura une taille d'un octet :
struct Obj {unsigned bitfield1 : 3; unsigned bitfield2 : 5;}; // 8 bits total
Cela s'explique par le risque de remplissage après la structure, ainsi qu'entre les deux champs si vous êtes vraiment malchanceux.
Norme C++ (projet n1905) : 9.6/1 Champs de bits
L'allocation des champs de bits dans un objet de classe est définie par l'implémentation.
L'alignement des champs de bits est défini par l'implémentation.
La lecture/accès à ces types de membres peut aussi être un inconvénient, la plupart des compilateurs actuels peuvent optimiser ces instructions pour qu'elles soient assez rapides, mais rien ne dit que ce sera le cas et cela peut créer beaucoup de surcharge d'exécution si le compilateur ne pense pas comme vous.
L'ordre dans lequel les champs de bits apparaîtront en mémoire est également défini par l'implémentation, ce qui peut conduire à un code non portable qui pourrait ne pas donner le même résultat sur deux systèmes différents.
Norme C++ (Projet n1905) : 9.6/1 [Note : *] Champs de bits
les champs de bits chevauchent les unités d'allocation sur certaines machines et pas sur d'autres. Les champs de bits sont assignés de droite à gauche sur certaines machines, de gauche à droite sur d'autres.
