|
![](/App_Themes/Normal/images/Window/Backgrounds/news.gif) | position af bit i bitfield Fra : Peter CC |
Dato : 25-12-02 10:04 |
|
hvis jeg har et bitfield hvor jeg ønsker et navn for bit 0 3 og 5, hvordan
definerer jeg det så?
struct {
unsigned int A;
unsigned int Dummy1;
unsigned int B;
unsigned int Dummy2;
unsigned int C;
};
Virker, men ser lidt grimt ud. Er der ikke en måde at definere at b kommer
to bit efter a, andet end ved at gøre a to bit stor?
Det vil give sideeffekter så som at a=1; a++; ikke gør at a er lig nul, men
istedet er 2. Bit 0 er godt nok nul, men så skal man altid specifikt teste
på den.
Anyway... sådan vil jeg helst ikke have det. Kan man definere både størelsen
og positionen af en bit variabel?
Dette skal bruges som flag i en statusbyte, hvor ikke alle bit er defineret
som flag.
| |
René Allan Larsen (25-12-2002)
![](/App_Themes/Normal/images/Window/Backgrounds/news.gif) | Kommentar Fra : René Allan Larsen |
Dato : 25-12-02 20:20 |
|
In article <aubs9d$3ra$1@news.cybercity.dk>, Peter CC wrote:
> From: "Peter CC" <nomail@nomail.nomail>
> Newsgroups: dk.edb.programmering.c
> Subject: position af bit i bitfield
> Date: Wed, 25 Dec 2002 10:03:47 +0100
>
> hvis jeg har et bitfield hvor jeg ønsker et navn for bit 0 3 og 5, hvordan
> definerer jeg det så?
Du definerer det som normalt, men lader bare være med at navngive nogle af dem
(denne kodestump er testet i BC++ 3.1):
struct MyBitField_t {
unsigned int bit0 : 1;
unsigned int : 2;
unsigned int bit3 : 1;
unsigned int : 1;
unsigned int bit5 : 1;
} MyBitField;
[kode fjernet]
> Virker, men ser lidt grimt ud. Er der ikke en måde at definere at b kommer
> to bit efter a, andet end ved at gøre a to bit stor?
> Det vil give sideeffekter så som at a=1; a++; ikke gør at a er lig nul, men
> istedet er 2. Bit 0 er godt nok nul, men så skal man altid specifikt teste
> på den.
Ovenstående kode virker.
MVH, René
| |
Peter CC (25-12-2002)
![](/App_Themes/Normal/images/Window/Backgrounds/news.gif) | Kommentar Fra : Peter CC |
Dato : 25-12-02 22:39 |
|
> Du definerer det som normalt, men lader bare være med at navngive nogle af
dem
> (denne kodestump er testet i BC++ 3.1):
>
> struct MyBitField_t {
> unsigned int bit0 : 1;
> unsigned int : 2;
> unsigned int bit3 : 1;
> unsigned int : 1;
> unsigned int bit5 : 1;
> } MyBitField;
Arh ja naturligvis. Jeg mente jeg havde prøvet det allerede, men må have
glemt et eller andet.
Takker mange gange for svaret.
| |
Byrial Jensen (25-12-2002)
![](/App_Themes/Normal/images/Window/Backgrounds/news.gif) | Kommentar Fra : Byrial Jensen |
Dato : 25-12-02 21:09 |
|
Peter CC <nomail@nomail.nomail> skrev:
> hvis jeg har et bitfield hvor jeg ønsker et navn for bit 0 3 og 5, hvordan
> definerer jeg det så?
Mange ting vedrørende bitfelter er implementationsafhængigt, bl.a.
hvor stor en lagerenhed de allokeres i, og i hvilken rækkefølge de
allokeres inden for lagerenheden. Tjek derfor dokumentationen til din
C-oversætter.
Når det er sagt, kan du prøve med:
struct useful_bits
{
unsigned int a : 1; // Første bit
unsigned int : 2; // To ubrugte, unavngivne bit
unsigned int b : 1; // Fjerde bit
unsigned int : 1; // Et ubrugt, unavngivent bit
unsigned int c : 1; // Sjette bit
};
> Er der ikke en måde at definere at b kommer
> to bit efter a, andet end ved at gøre a to bit stor?
Ja, med unavngivne bitfelter.
> Det vil give sideeffekter så som at a=1; a++; ikke gør at a er lig nul,
Gør /ikke/ det hvis a er et bitfelt med en bredde på 1 bit. Overløb
i heltalsaritmetik giver altid uspecificeret adfærd. Resultatet er
ukendt!
Brug i stedet xor til at ændre værdien til det modsatte på en
standardiseret og portabel måde.
| |
Igor V. Rafienko (26-12-2002)
![](/App_Themes/Normal/images/Window/Backgrounds/news.gif) | Kommentar Fra : Igor V. Rafienko |
Dato : 26-12-02 16:57 |
|
[ Byrial Jensen ]
[ ... ]
> Gør /ikke/ det hvis a er et bitfelt med en bredde på 1 bit. Overløb
> i heltalsaritmetik giver altid uspecificeret adfærd. Resultatet er
> ukendt!
Er bitfelt spesielle på dette punktet? (Med "spesielle" mener
"annerledes enn det som gjelder for unsigned integral types").
ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
-- pederst på irc
| |
![](/images/tree/0.gif) Byrial Jensen (06-01-2003)
![](/App_Themes/Normal/images/Window/Backgrounds/news.gif) | Kommentar Fra : Byrial Jensen |
Dato : 06-01-03 00:10 |
|
Igor V. Rafienko <igorr@ifi.uio.no> skrev:
> [ Byrial Jensen ]
>
>> Gør /ikke/ det hvis a er et bitfelt med en bredde på 1 bit. Overløb
>> i heltalsaritmetik giver altid uspecificeret adfærd. Resultatet er
>> ukendt!
>
> Er bitfelt spesielle på dette punktet? (Med "spesielle" mener
> "annerledes enn det som gjelder for unsigned integral types").
Nej, bitfelter adskiller sig ikke fra andre "integral types" med
hensyn til at aritmetisk overløb resulterer i uspecificeret adfærd.
| |
![](/images/tree/0.gif) ![](/images/tree/0.gif) Igor V. Rafienko (06-01-2003)
![](/App_Themes/Normal/images/Window/Backgrounds/news.gif) | Kommentar Fra : Igor V. Rafienko |
Dato : 06-01-03 12:30 |
|
[ Byrial Jensen ]
[ ... ]
> > > Overløb i heltalsaritmetik giver altid uspecificeret adfærd.
[ ... ]
> Nej, bitfelter adskiller sig ikke fra andre "integral types" med
> hensyn til at aritmetisk overløb resulterer i uspecificeret adfærd.
Legg merke til at vedkommende hadde _unsigned_ int. All aritmetikk
utføres modulo <en passende størrelse> for _unsigned_ integral types,
om jeg ikke husker feil. Mao UINT_MAX + 1 _skal_ være 0.
ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
-- pederst på irc
| |
![](/images/tree/0.gif) ![](/images/tree/0.gif) ![](/images/tree/0.gif) Byrial Jensen (06-01-2003)
![](/App_Themes/Normal/images/Window/Backgrounds/news.gif) | Kommentar Fra : Byrial Jensen |
Dato : 06-01-03 20:19 |
|
Igor V. Rafienko <igorr@ifi.uio.no> skrev:
> [ Byrial Jensen ]
>
> [ ... ]
>
>> > > Overløb i heltalsaritmetik giver altid uspecificeret adfærd.
>
> [ ... ]
>
>> Nej, bitfelter adskiller sig ikke fra andre "integral types" med
>> hensyn til at aritmetisk overløb resulterer i uspecificeret adfærd.
>
>
> Legg merke til at vedkommende hadde _unsigned_ int. All aritmetikk
> utføres modulo <en passende størrelse> for _unsigned_ integral types,
> om jeg ikke husker feil. Mao UINT_MAX + 1 _skal_ være 0.
Du husker ret, og jeg huskede forkert. C99 afsnit 6.2.5#9 siger:
A computation involving unsigned operands
can never overflow, because a result that cannot be
represented by the resulting unsigned integer type is
reduced modulo the number that is one greater than the
largest value that can be represented by the resulting type.
| |
|
|