D'un point de vue logique (non technique), il n'y a aucun avantage.
Tout code C / C ++ ordinaire peut être encapsulé dans une "construction de bibliothèque" appropriée. Après un tel emballage, la question de "si cela est plus avantageux que cela" devient une question théorique.
Du point de vue de la vitesse, C / C ++ devrait permettre à la construction de la bibliothèque de générer du code aussi efficace que le code ordinaire qu'il encapsule. Ceci est cependant soumis à:
- Fonction inlining
- Vérification à la compilation et élimination de la vérification inutile de l'exécution
- Élimination du code mort
- Beaucoup d'autres optimisations de code ...
En utilisant ce type d'argument non technique, toutes les "fonctions manquantes" pourraient être ajoutées par n'importe qui, et ne sont donc pas considérées comme un inconvénient.
Cependant, les exigences et limitations intégrées ne peuvent pas être surmontées avec du code supplémentaire. Ci-dessous, je soutiens que la taille de std::bitset
est une constante au moment de la compilation et que, même si elle n'est pas considérée comme un inconvénient, c'est toujours quelque chose qui affecte le choix de l'utilisateur.
D'un point de vue esthétique (lisibilité, facilité d'entretien, etc.), il y a une différence.
Cependant, il n'est pas évident que le std::bitset
code l'emporte immédiatement sur le code C ordinaire. Il faut regarder de plus gros morceaux de code (et non un échantillon de jouet) pour dire si l'utilisation de std::bitset
a amélioré la qualité humaine du code source.
La vitesse de manipulation des bits dépend du style de codage. Le style de codage affecte à la fois la manipulation des bits C / C ++ et s'applique également à std::bitset
, comme expliqué ci-dessous.
Si l'on écrit du code qui utilise le operator []
pour lire et écrire un bit à la fois, il faudra le faire plusieurs fois s'il y a plus d'un bit à manipuler. La même chose peut être dite du code de style C.
Cependant, bitset
a aussi d' autres opérateurs, tels que operator &=
, operator <<=
, etc., qui fonctionne sur toute la largeur de la bitset. Étant donné que la machine sous-jacente peut souvent fonctionner sur 32 bits, 64 bits et parfois 128 bits (avec SIMD) à la fois (dans le même nombre de cycles de processeur), un code conçu pour tirer parti de ces opérations multi-bits peut être plus rapide que le code de manipulation de bits "en boucle".
L'idée générale est appelée SWAR (SIMD dans un registre) , et est un sous-sujet sous manipulations de bits.
Certains fournisseurs C ++ peuvent implémenter bitset
entre 64 bits et 128 bits avec SIMD. Certains fournisseurs pourraient ne pas (mais pourraient éventuellement le faire). S'il est nécessaire de savoir ce que fait la bibliothèque du fournisseur C ++, la seule façon est de regarder le désassemblage.
Quant à savoir si std::bitset
a des limites, je peux donner deux exemples.
- La taille de
std::bitset
doit être connue au moment de la compilation. Pour faire un tableau de bits avec une taille choisie dynamiquement, il faudra utiliser std::vector<bool>
.
- La spécification C ++ actuelle pour
std::bitset
ne fournit pas un moyen d'extraire une tranche consécutive de N bits à partir d'un plus grand bitset
de M bits.
La première est fondamentale, ce qui signifie que pour les personnes qui ont besoin de bitsets de taille dynamique, elles doivent choisir d'autres options.
Le second peut être surmonté, car on peut écrire une sorte d'adaptateurs pour effectuer la tâche, même si la norme bitset
n'est pas extensible.
Il existe certains types d'opérations SWAR avancées qui ne sont pas fournis dès le départ std::bitset
. On pourrait lire sur ces opérations sur ce site Web les permutations de bits . Comme d'habitude, on peut les implémenter par eux-mêmes, fonctionnant par dessus std::bitset
.
Concernant la discussion sur la performance.
Un avertissement: beaucoup de gens demandent pourquoi (quelque chose) de la bibliothèque standard est beaucoup plus lent qu'un simple code de style C. Je ne répéterais pas ici les connaissances préalables en matière de micro-analyse comparative, mais j'ai juste ce conseil: assurez-vous de comparer en "mode de sortie" (avec les optimisations activées), et assurez-vous que le code n'est pas éliminé (élimination du code mort) ou hissé hors d'une boucle (mouvement de code invariant en boucle) .
Étant donné qu'en général, nous ne pouvons pas dire si quelqu'un (sur Internet) faisait correctement les microbenchmarks, la seule façon de parvenir à une conclusion fiable est de faire nos propres microbenchmarks, de documenter les détails et de soumettre à l'examen et à la critique du public. Cela ne fait pas de mal de refaire des microbenchmarks que d'autres ont déjà fait.
std::bitset
est fixée au moment de la compilation. C'est le seul inconvénient paralysant auquel je peux penser.