Puis-je attribuer un nombre de bits en C?

Je suis en train de stocker une grande quantité de booléens de l'information qui est déterminé au moment de l'exécution. Je me demandais quelle est la meilleure méthode pourrait être.

J'ai été essayer d'allouer de la mémoire à l'aide de:

pStatus = malloc((<number of data points>/8) + 1);

en pensant que cela va me donner assez de bits pour travailler avec. Je pourrais alors faire référence à chaque valeur booléenne à l'aide du pointeur dans la notation de tableau:

pStatus[element]

Malheureusement, cela ne semble pas fonctionner très bien. Tout d'abord, j'ai de la difficulté à l'initialisation de la mémoire de la valeur de l'entier 0. Cela peut être fait en utilisant memset()? Pourtant, je ne pense pas que l'impact est pourquoi je plantage lors de l'accès pStatus[element].

Je suis également pas tout à fait convaincu que cette approche est le meilleur à utiliser. Ce que je veux vraiment, c'est essentiellement un géant masque de bits qui reflète l'état de l'valeurs booléennes. Ai-je raté quelque chose?

Comment grand est grand? Un million de bits, qui est stocké par octet est à seulement 1 mo de mémoire. Pourquoi perdre son temps avec les bits lorsque octets travail tellement mieux?
Je pense que les commentaires sont un peu des citoyens de deuxième classe à l'heure actuelle. Mais, cela devient hors sujet pour cette question 😛
Je suis d'accord avec le commentaire ci-dessus. Il va être beaucoup plus simple et plus rapide (à la fois de dev et de l'exécution) de l'utilisation d'un tableau d'octets (unsigned caractères).
Je voudrais vous donner le crédit Lott, mais vous n'avez pas de réponse pour moi de vérifier. Merci pour votre suggestion. Il est facile d'oublier que, tandis que 100 000 points de données est beaucoup pour un homme, l'ordinateur ne sont même pas casser une sueur.
Plus hors-sujet: "convertissez-commentaire(s) de répondre" peut-être la bonne SI caractéristique.
Il serait mieux de ne pas assumer un octet est toujours 8 bits: certaines très anciennes plates-formes avaient 9 bits/octets, et je crois que le VAXes' (et Nintendo64?) le plus petit entier qui est en 32bits. Préférable d'inclure<limites.h>, et l'utilisation de la macro CHAR_BITS qui garantit la bonne quantité de bits par octet, sur chaque plate-forme.
Pas tellement pour le Vax. Les caractères de 8 bits. Et de noter que la plupart des implémentations ci-dessous fonctionne très bien avec n'importe quel nombre de bits par octet tant qu'il y a 8 ou plus 🙂
Bon. Le Point est: pourquoi sacrifier la portabilité à l'aide d'une valeur codée en dur quand vous pouvez faire la bonne chose, dès le début, à presque zéro coût? Vous n'avez qu'à écrire un peu plus, c'est elle!
Vrai. OP utilisé 8 bits, mais en utilisant CHAR_BITs est la bonne Réponse.
Ah, trouvé, sur la page Wikipedia de l'Octet de l'article: L'octet le plus souvent constitué de 8 bits dans les systèmes modernes, cependant, la taille d'un octet peut varier et est généralement déterminé par le sous-jacent système d'exploitation d'ordinateur ou de matériel. Historiquement, les octets ont varié de cinq à douze bits. Citation nécessaire?

InformationsquelleAutor Tim | 2008-11-12

bitmask c malloc

29
```
pStatus = malloc((<number of data points>/8) + 1);
```
Ce n'allouer suffisamment d'octets pour votre bits. Cependant,
```
pStatus[element]
```
Ce accède à l'élément th octet, pas peu. Ainsi, lorsque l'élément est plus qu'un huitième du nombre total de bits, vous êtes accédant à la fin du tableau alloué.

Je voudrais définir quelques fonctions d'assistance
```
int get_bit(int element)
{
    uint byte_index = element/8;
    uint bit_index = element % 8;
    uint bit_mask = ( 1 << bit_index);

    return ((pStatus[byte_index] & bit_mask) != 0);
}

void set_bit (int element)
{
    uint byte_index = element/8;
    uint bit_index = element % 8;
    uint bit_mask = ( 1 << bit_index);

    pStatus[byte_index] |= bit_mask);
}

void clear_bit (int element)
{
    uint byte_index = element/8;
    uint bit_index = element % 8;
    uint bit_mask = ( 1 << bit_index);

    pStatus[byte_index] &= ~bit_mask;
}
```
(contrôle d'erreur sur la portée de l'élément à gauche pour plus de clarté. Vous pouvez faire ce macros, trop)
- en ce qui concerne get_bit - alors qu'il est merveilleusement parallèle à d'autres implémentations, vous pouvez extraire l'octet d'abord, puis vérifiez le bit non nul: char b = pStatus(byte_index); if (b) { uint bit_windex = élément % 8; ... } else { return 0; }
- Pourquoi? (pas en désaccord, je me demandais pourquoi). Le compilateur doit faire un travail décent de l'une ou l'autre version.
- Vous ne devriez pas supposer qu'un octet de 8 bits. Utilisation CHAR_BIT au lieu de 8, include <limits.h> si nécessaire. Cela s'applique à la plupart des commentaires dans ce fil, il me semble.
- Pas en supposant qu'un octet de 8 bits peut-être fait sens dans le passé, mais il semble un peu radical d'aujourd'hui.
- En fonction de votre ordinateur/compilateur, il peut être plus efficace pour ce faire, en termes de 32/64 bits [integer] mots. Mon ordinateur n'a pas eu un 8-bit de la mémoire de bus depuis les années '80.
InformationsquelleAutor The Archetypal Paul
7

...en pensant que cela va me donner assez de bits pour travailler avec. Je pourrais alors faire référence à chaque valeur booléenne à l'aide du pointeur dans la notation de tableau:
```
pStatus[element]
```
élément est de s'attaquer aux octets, pas de bits. Vous voulez quelque chose comme:
```
pStatus[element/8] & (1 << (element % 8))
```
- attention, & lie plus étroitement que <<, de sorte que vous voudrez probablement pStatus [/élément 8] & (1 << (élément % 8))
- Selon difranco.net/cop2220/op-prec.htm << est une priorité PLUS élevée que & Paul: Pourriez-vous parenthesize ce que vous avez prévu?
InformationsquelleAutor Paul Betts
5

Petit point: pour obtenir suffisamment de mémoire pour stocker les N bits (N/8) + 1 octets est imprécise (peut-être un de trop).

(N+7)/8 est toujours le nombre minimum, si.
- Je l'utilise toujours (N/8)+1 parce que logiquement, il n'a plus de sens, mais lorsque l'espace est restreint (N+7)/8 est utile de rappeler (bien que plus difficile à comprendre et peut-être plus sujettes à l'erreur).
InformationsquelleAutor orip
4

Bien, la réponse la plus simple serait d'utiliser calloc à la place de malloc.

Il est défini à l'initialisation de la mémoire qu'elle alloue à zéro, et peuvent souvent le faire en utilisant la page de la cartographie des tours.

Qui va prendre soin de votre problème d'initialisation de la mémoire. La douzaine de posts ici semblent répondre de manière adéquate aux indexation problème et le fait que vous, à l'occasion d'allouer un octet supplémentaire (oh l'horreur!), donc, je ne vais pas répéter leur contenu ici.

InformationsquelleAutor Edward KMETT
2

pStatus[élément] vous donnera un octet entier à cette adresse.

Pour définir un élément particulier que vous feriez quelque chose comme:
```
pStatus[element >> 3] |= 1 << (element & 7);
```
À réinitialiser un élément:
```
pStatus[element >> 3] &= ~1 << (element & 7);
```
et de tester un élément:
```
if (pStatus[element >> 3] & (1 << (element & 7)) != 0)
```
l'allocation initiale doit être
```
pstatus = malloc((<number of data points> + 7) / 8)
```
ce que vous aviez va fonctionner, mais les déchets de un octet parfois

InformationsquelleAutor Ferruccio
2

Je ne peux pas aider mais noter que toutes les réponses dans C ici semblent partir du principe qu'un octet de 8 bits. Ce n'est pas nécessairement vrai dans C (étant entendu qu'il pourra être true sur la plupart des grands de matériel), afin de faire de cette hypothèse dans le code est plutôt une mauvaise forme.

La bonne façon d'écrire de l'architecture neutre code est à
```
#include <limits.h>
```
et ensuite utiliser le CHAR_BIT macro où vous en avez besoin "le nombre de bits dans un char".
- C'est un commentaire, pas une réponse.
InformationsquelleAutor unwind
1

Vous rendre plus heureux et définir un type et les fonctions de fonctionner sur ce type. De cette façon, si vous découvrez que peu accès sont trop lent, vous pouvez modifier l'unité de mémoire par boolean byte/word/long ou d'adopter des sparse/dynamique des structures de données si la mémoire est vraiment un problème (c'est à dire, si vos jeux sont pour la plupart des zéros, vous avez juste à garder une liste avec les coordonnées de la 1.

Vous pouvez écrire votre code afin d'être complètement à l'abri des changements apportés à la mise en œuvre de votre vecteur de bits.

InformationsquelleAutor plinth
0

pStatus[élément] n'est pas de l'adresse de bit. L'octet exact c'est dépendante du type de pStatus -- je suppose char* ou équivalent -- donc pStatus[élément] devient l'élément ième octet.

Vous pourriez memset à la valeur 0, oui.

InformationsquelleAutor Lou Franco
0
```
 pStatus = malloc((<number of data points>/8) + 1);
```
Qu'une partie de l'amende.
```
 pStatus[element]
```
voici où vous avez des problèmes. Vous êtes octets d'adresse, quand vous voulez bits de l'adresse.
```
 pStatus[element / 8 ]  
```
permettra d'obtenir le droit d'octets dans le tableau.

InformationsquelleAutor James Curran
0

Vous avez besoin d'allouer c = malloc((N+7)/8) octets, et vous pouvez définir le nième avec
```
 c[n/8]=((c[n/8] & ~(0x80 >> (n%8))) | (0x80>>(n%8)));
```
clair avec
```
 c[n/8] &= ~(0x80 >> (n%8));
```
et de tester avec
```
 if(c[n/8] & (0x80 >> (n%8))) blah();
```
- Pourquoi effacer le morceau avant de le mettre dans la première équation? le "& ~(...)" phrase est inutile.
InformationsquelleAutor Rhythmic Fistman
0

Si vous n'avez pas l'esprit d'avoir à écrire des wrappers, vous pouvez également utiliser les deux bit_set ou bit_vector de C++STL, semble qu'ils (surtout le second) exactement ce dont vous avez besoin, déjà codé, testés et emballés (et beaucoup de cloches et de sifflets).

C'est une véritable honte qui nous manque, un simple moyen d'utiliser du code C++ dans des applications C (n, la création d'un wrapper n'est pas à moi, ni plaisir, et signifie plus de travail à long terme).

InformationsquelleAutor Joe Pineda
0

Ce serait mal avec std::vector<bool>?
- sizeof(bool)=1. vector<bool> stocke une entrée par octet. std::vector<> consomme une charge supplémentaire. Il utilise C++ pas C. les Meilleurs choix bit_vector (une entrée par bit) et/ou bitset. Ref: sgi.com/tech/stl/bit_vector.html && sgi.com/tech/stl/bitset.html
- Correction: Apparemment nouveaux compilateurs se spécialisent maintenant vector<bool> pour fournir une entrée par bit. Je corrige la position des mains.
InformationsquelleAutor pauldoo
0

Cela m'étonne qu'une seule réponse ici mentionne CHAR_BIT. Un octet est souvent 8 bits, mais pas toujours.
- Sur tout ce qui subsiste de non-incorporé platfomrs CHAR_BIT est 8.
- Une grande partie de la C je fais, c'est pour les périphériques embarqués. (Il est vrai que, sur la plupart de ces, CHAR_BITS encore 8). Lorsque la Norme ANSI dit CHAR_BIT est toujours 8, nous pouvons nous passer de CHAR_BIT.
InformationsquelleAutor tpdi
-1

Vous de répartition de code est correct, voir la set_bit() et get_bit() de fonctions données dans cette réponse pour accéder à la valeur de type boolean.

InformationsquelleAutor philant
-1

Si vous êtes limité à seulement quelques bits, vous pouvez au lieu de eaanon01 solution aussi utiliser le c builtin installation de champ de bits (il y a très peu d'occasions où vous pourriez utiliser, mais ce serait une)

Ce bit banging je peux recommendate:
Herny Warrens Hacker "Plaisir"

InformationsquelleAutor flolo
-1

Le booléen est "jamais" une valeur distincte dans C. Donc, une structure peut être pour vous d'aller.

Il est vrai que vous n'initialisez pas le mem région de sorte que vous besoin de le faire individuellement.

Voici un exemple simple de la façon dont vous pourriez le faire avec les syndicats, les structures et les énumérations,
```
typedef unsigned char           BYTE;
typedef unsigned short          WORD;
typedef unsigned long int       DWORD;
typedef unsigned long long int  DDWORD;
enum STATUS
{
    status0 = 0x01,
    status1 = 0x02,
    status2 = 0x04,
    status3 = 0x08,
    status4 = 0x10,
    status5 = 0x20,
    status6 = 0x40,
    status7 = 0x80,
status_group = status0 + status1 +status4
};
#define GET_STATUS( S ) ( ((status.DDBuf&(DDWORD)S)==(DDWORD)S) ? 1 : 0  )
#define SET_STATUS( S ) (  (status.DDBuf|=  (DDWORD)S) )
#define CLR_STATUS( S ) (  (status.DDBuf&= ~(DDWORD)S) )
static union {
 BYTE   BBuf[8];
 WORD   WWBuf[4];
 DWORD  DWBuf[2];
 DDWORD DDBuf;
}status;

int main(void)
{
    //Reset status bits
    status.BBuf[0] = 0;
    printf( "%d \n", GET_STATUS( status0 ) );

    SET_STATUS( status0 );
    printf( "%d \n", GET_STATUS( status0 ) );

    CLR_STATUS(status0);
    printf( "%d \n", GET_STATUS( status0 ) );
    SET_STATUS( status_group );
    printf( "%d \n", GET_STATUS( status0 ) );
    system( "pause" );
    return 0;
}
```
Espère que cette aide. Cet exemple peut gérer jusqu'à 64 état des booléens et pourrait être facilement étendu.

Ce exapmle est basé sur le Char = 8 bits int = 16 bits de long int = 32 bits et long long int = 64 bits

J'ai maintenant également ajouté le support pour les groupes de statut.
- Bon code! Améliorations possibles: #define GET_STATUS( S ) (situation.DWBuf&(DWORD)S) automatiquement renvoie la valeur (baisse superflu de comparaison). Donner un nom à l'union (pas de anon, s'il vous plaît). Convertir les macros dans les fonctions de, et de recevoir de l'union qu'il travaille en tant que param.
- Aussi: vous avez oublié de définir des macro WORD. Et de mieux définir les deux DWORD et WORD à l'aide de macros __int32 et __ _ _ int16 (je crois qu'ils font partie de la norme), ces éléments sont toujours de la même taille sur tous les compilateurs et les plates-formes.
- Pineda: __int32 et __ _ _ int16 est une MS-spécifique à construire. Équivalent le plus proche dans la norme est int32_t et int16_t (définie dans le <stdint.h> et (efficacement) en <inttypes.h>. En général, il est préférable d'utiliser unsigned des équivalents de trésorerie pour les opérations sur les bits.
- Comment fonctionne ce code traite avec plus de 32 bits?
- Parce que le statut de la var est de 64 bits ( unsigned long int )
- Faux: MOT de 16 bits de long, DWORD 32. Vous auriez besoin d'un "long long int" ou un __int64 pour obtenir 64 bits, et ensuite de ne pas tous les compilateurs l'appui de ces options.
- Sur une autre idée, il pourrait être en effet que votre "long int" est de 64 bits de long, ce qui compilateur/OS/version utilisez-vous? La norme ANSI applique uniquement size_of(char)<=size_of(short int)<=size_of(int)<=size_of(long int) Utilisation __int64 ou équivalent pour faire de votre intention évidente!
- Joe Pineda: Oui, vous correcte. Mon erreur. J'ai corrigé maintenant. S'il vous plaît commentaire pour plus d'improments. Je pense que c'est plus lisible slolution que l'utilisation de fonctions. Mais dépend un peu sur les exigences.
- Par exemple, jetez un oeil à ce fil: linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/... Même compilateur, 64bits processeur, système d'exploitation différent (32/64 bits Linux), sur celui que vous avez size_of(long int)=4 et l'autre il est à 8 🙁
- OK, allez les macros si vous le souhaitez (je vais dire "vous dit!" lorsque vous vous blessez). Si vous avez encore un superflu de comparaison sur GET_STATUS!!! Penser à elle, après avoir appliqué le masque de bits, la valeur est 0 ou pas, selon le peu que vous voulez, ne peut pas être autre chose...
- Joe Pineda: Non si vous venez de l'état de retour.DDBuf&(DDWORD)S, alors vous pouvez obtenir returnd des valeurs comme 0x8000 0000 0000 0000 place de seulement 1. Les chiffres 1 et 0 sont de mieux pour tester / provess plus tard. Ensuite, vous n'avez pas à se préoccuper de la valeur de status0
InformationsquelleAutor

Vous devez vous connecter pour publier un commentaire.