Je regarde la bibliothèque C # appelée Bitstream , qui vous permet Écrire et lire un nombre quelconque de bits à un objectif standard C # Lorsque vous ajoutez des bits à un octet vide, les bits sont ajoutés au MSB de l'octet. Par exemple: p> Toutefois, lorsque vous référencez des bits dans un numéro comme l'entrée em>, le premier bit du numéro d'entrée est le LSB. Par exemple P> Objet CODE>. J'ai remarqué ce qui me semblait une décision de conception étrange: var s = new BitStream();
s.Write(0x1,0,4);
s.Write(0x2,0,4);
s.Write(0x3,0,4);
Debug.Assert(s.ToByteArray()[0] == 0x12); // and not s.ToByteArray()[1] == 0x12
3 Réponses :
Y a-t-il une raison de ce design qui me manque? Toute autre mise en œuvre des bits flux dans ce comportement? Quelles sont les considérations de conception pour cela?
Je doute qu'il y ait une signification significative derrière la descente. Techniquement, cela n'a pas d'importance tant que l'écrivain et le lecteur sont d'accord sur la commande.
Cela me semble incompatible. Depuis dans ce cas, quand "progressivement" mais je viens de montrer que ça compte. Citation: "Copier un octet comme dans l'exemple précédent (les quatre premiers bits, puis les quatre derniers bits), nous n'obtiendrons pas l'octet original. Nous devons la copier" en arrière "(d'abord les quatre derniers bits, puis le quatre premiers bits). "
Comme je l'ai dit, lorsque le lecteur et l'écrivain sont d'accord sur le bit commandant, peu importe. OMI, vous devriez utiliser le bitstream pour lire et écrire. Si vous avez d'autres intentions, comme lire les octets résultants, vous devriez probablement écrire votre propre flux.
Voici quelques considérations supplémentaires:
Dans le cas du booléen - un seul bit est nécessaire pour représenter true ou false. Lorsque ce bit est ajouté au début du flux, le flux de bits est "1." Lorsque vous étendez ce flux à la longueur d'octet, il oblige le rembourrage des bits zéro jusqu'à la fin du flux, même si ces bits n'existaient pas dans le flux pour commencer. La position dans le flux est des informations importantes comme les valeurs des bits et un flux de bits de "1000000" ou 0x80 protège l'attente que les lecteurs ultérieurs du flux peuvent avoir que le premier bit qu'ils lisent est le premier bit qui a été ajouté.
Deuxièmement, d'autres types de données tels que les entiers nécessitent plus de bits de représenter afin qu'ils vont prendre plus de place dans le courant que les booléens. Mélanger des types de données de taille différents dans le même flux peut être très délicat lorsqu'ils ne sont pas alignés sur les limites d'octets.
Enfin, si vous êtes sur Intel X86, votre architecture du processeur est "petite-Endian", ce qui signifie que LSB d'abord comme vous décrivez. Si vous devez stocker des valeurs dans le flux comme Big-Endian, vous devez ajouter une couche de conversion dans votre code - similaire à ce que vous avez montré ci-dessus où vous appuyez sur un octet à la fois dans le flux dans l'ordre de votre choix. . Ceci est gênant, mais couramment requis si vous devez interoper avec des boîtes UNIX Big-Endian ou comme étant requise par une spécification de protocole.
espère que cela aide!
Je suis d'accord avec Elazar.
Comme il / elle fait remarquer, il s'agit d'un cas où le lecteur et l'écrivain ne sont pas d'accord sur le bit commandant. En fait, ils sont incompatibles.