/ Forside / Teknologi / Udvikling / C/C++ / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
C/C++
#NavnPoint
BertelBra.. 2425
pmbruun 695
Master_of.. 501
jdjespers.. 500
kyllekylle 500
Bech_bb 500
scootergr.. 300
gibson 300
molokyle 287
10  strarup 270
Lidt kompliceret bitnusseri
Fra : Flare


Dato : 10-04-03 15:15

Jeg (vi) er ved at lave et codec i C++. Dette indebærer at noget informtion
skal gemmes i 2 - 16 bit alt afhængih af forholdene.

Codec'et gemmer i et frameformat med følgende struktur:
[12x1bit][25x4bit][25x4bit][data skrevet med 2 - 16 bit]

En lang række af disse frames skal skrives til en fil efter hinanden. Men
hvordan faen gør jeg dette?

Hvilken metode vil være hensigtsmæssig at bruge. ? Og hvordan skrive jeg fx
4 bit tallet 1011 til fil?

Nogen ideer (erfaringer) hvordan man griber dette an?
--
----------------------------------------
Anders Jacobsen 2003 @ www.pings.dk



 
 
Bertel Lund Hansen (10-04-2003)
Kommentar
Fra : Bertel Lund Hansen


Dato : 10-04-03 16:40

Flare skrev:

>Hvilken metode vil være hensigtsmæssig at bruge. ? Og hvordan skrive jeg fx
>4 bit tallet 1011 til fil?

Du kan vælge at gemme hver enhed i sin egen byte. Du kan også
vælge at presse 8 bit sammen i én byte og så selv holde styr på
(både i 'sender' og 'modtager') hvilken enhed bittene hører til.

F.eks. kan du med den metode gemme 2 * 4 bit i én byte.

>Nogen ideer (erfaringer) hvordan man griber dette an?

Er det principper eller (pseudo)kode du er ude efter?

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

Flare (10-04-2003)
Kommentar
Fra : Flare


Dato : 10-04-03 18:14

> Er det principper eller (pseudo)kode du er ude efter?

Tjaa det ved jeg sgu snart ikke. Men grunden til det er naturligvis at det
skal fylde så lidt som overhovdet muligt.
Men jeg kan ikke se hvordan man på en overskuelig måde kan holdestyr på at
jeg har fyldt fx. 7 bit ind i en unsigned char og bruge den sidste bit på
som første i den næste bit data på fx 14 bit . Det bliver da ren kaos at
pille fra hinanden igen.

Så ja jeg tror jeg leder efter principper til at "holde styr" på sådan en
"bit komprimering"

Mvh
Anders



kenneth (11-04-2003)
Kommentar
Fra : kenneth


Dato : 11-04-03 01:01

Prøv evt dette princip.

typedef struct
{
int var1;
int var2;
union
{
struct
{
int bitfield_1:1;
int bitfield_2:1;
int bitfield_3:1;
int bitfield_4:1;
int reserved:28;
} bitfield;
bitfield_value;
}test_struct.


main()
{
test_struct myStruct;
myStruct.bitfield_1 = TRUE;
myStruct.bitfield_2 = TRUE;
myStruct.bitfield_3 = FALSE;
printf(" bitfield : %b",myStruct.bitfield_value);
}


"Flare" <dct_flare@hotmail.com> wrote in message
news:3e95a66c$0$238$edfadb0f@dread15.news.tele.dk...
> > Er det principper eller (pseudo)kode du er ude efter?
>
> Tjaa det ved jeg sgu snart ikke. Men grunden til det er naturligvis at det
> skal fylde så lidt som overhovdet muligt.
> Men jeg kan ikke se hvordan man på en overskuelig måde kan holdestyr på at
> jeg har fyldt fx. 7 bit ind i en unsigned char og bruge den sidste bit på
> som første i den næste bit data på fx 14 bit . Det bliver da ren kaos at
> pille fra hinanden igen.
>
> Så ja jeg tror jeg leder efter principper til at "holde styr" på sådan en
> "bit komprimering"
>
> Mvh
> Anders
>
>



kenneth (11-04-2003)
Kommentar
Fra : kenneth


Dato : 11-04-03 01:09

Arggh. Jeg må lige rette mig selv.

> Prøv evt dette princip.
>
> typedef struct
> {
> int var1;
> int var2;
> union
> {
> struct
> {
> int bitfield_1:1;
> int bitfield_2:1;
> int bitfield_3:1;
> int bitfield_4:1;
> int reserved:28;
> } bitfield;
> bitfield_value;
}
> }test_struct;
>
>
> main()
> {
> test_struct myStruct;
> myStruct.bitfield.bitfield_1 = TRUE;
> myStruct.bitfield.bitfield_2 = TRUE;
> myStruct.bitfield.bitfield_3 = FALSE;
> printf(" bitfield : %b",myStruct.bitfield_value);
> }
>

Men det var jo også bare et princip.


>
> "Flare" <dct_flare@hotmail.com> wrote in message
> news:3e95a66c$0$238$edfadb0f@dread15.news.tele.dk...
> > > Er det principper eller (pseudo)kode du er ude efter?
> >
> > Tjaa det ved jeg sgu snart ikke. Men grunden til det er naturligvis at
det
> > skal fylde så lidt som overhovdet muligt.
> > Men jeg kan ikke se hvordan man på en overskuelig måde kan holdestyr på
at
> > jeg har fyldt fx. 7 bit ind i en unsigned char og bruge den sidste bit

> > som første i den næste bit data på fx 14 bit . Det bliver da ren kaos at
> > pille fra hinanden igen.
> >
> > Så ja jeg tror jeg leder efter principper til at "holde styr" på sådan
en
> > "bit komprimering"
> >
> > Mvh
> > Anders
> >
> >
>
>



Flare (11-04-2003)
Kommentar
Fra : Flare


Dato : 11-04-03 11:38

Ok. Jeg har sidet og nusset lidt med bitfields i structs. `
Men er det er mig der er er galt på den eller definere man ikke structs som:

struct navn
{
int bitfield_1:1;
}
?

Forstår ikke helt dit ex. hvorfor pakke et struct ind i en union og pakke
den ind i et struct?
Og hvad er bitvalue? den har ingen type?

> > typedef struct
> > {
> > int var1;
> > int var2;
> > union
> > {
> > struct
> > {
> > int bitfield_1:1;
> > int bitfield_2:1;
> > int bitfield_3:1;
> > int bitfield_4:1;
> > int reserved:28;
> > } bitfield;
> > bitfield_value;
> }
> > }test_struct;
> >
> >
> > main()
> > {
> > test_struct myStruct;
> > myStruct.bitfield.bitfield_1 = TRUE;
> > myStruct.bitfield.bitfield_2 = TRUE;
> > myStruct.bitfield.bitfield_3 = FALSE;
> > printf(" bitfield : %b",myStruct.bitfield_value);
> > }



kenneth (12-04-2003)
Kommentar
Fra : kenneth


Dato : 12-04-03 17:09

Jeg har lavet dig et eksemple der kan compile.

<Eksempel start>

#include <stdio.h>

typedef unsigned long int bitf32;

typedef struct
{
union
{
struct
{
bitf32 power:1; /* reserver 1 bit */
bitf32 color:2; /* reserver 2 bit */
bitf32 reserved:29;
} bitfield_str;
bitf32 bit_value;
};
} MyStruct;

#define ON 1
#define OFF 0

#define BLACK 0
#define WHITE 1
#define RED 2
#define BLUE 3

int main()
{
MyStruct test;
test.bit_value = 0;
test.bitfield_str.power = ON;
test.bitfield_str.color = BLUE;

printf("Bitfield data 0x%x \n",test.bit_value);
return 0;
}

<Eksempel stop>

Ideen med en union er at du har adgang til dine data i en variable når du
har samlet dine data i dit bitfield.
Når du har alle dine bits, kan du gemme dem på disken med en fprintf, lige
som jeg i eksemplet skriver dem i en xterm/dosbox.
Jeg håber at du kan komme vidre herfra.


"Flare" <dct_flare@hotmail.com> wrote in message
news:3e969b00$0$143$edfadb0f@dread15.news.tele.dk...
> Ok. Jeg har sidet og nusset lidt med bitfields i structs. `
> Men er det er mig der er er galt på den eller definere man ikke structs
som:
>
> struct navn
> {
> int bitfield_1:1;
> }
> ?
>
> Forstår ikke helt dit ex. hvorfor pakke et struct ind i en union og pakke
> den ind i et struct?
> Og hvad er bitvalue? den har ingen type?
>
> > > typedef struct
> > > {
> > > int var1;
> > > int var2;
> > > union
> > > {
> > > struct
> > > {
> > > int bitfield_1:1;
> > > int bitfield_2:1;
> > > int bitfield_3:1;
> > > int bitfield_4:1;
> > > int reserved:28;
> > > } bitfield;
> > > bitfield_value;
> > }
> > > }test_struct;
> > >
> > >
> > > main()
> > > {
> > > test_struct myStruct;
> > > myStruct.bitfield.bitfield_1 = TRUE;
> > > myStruct.bitfield.bitfield_2 = TRUE;
> > > myStruct.bitfield.bitfield_3 = FALSE;
> > > printf(" bitfield : %b",myStruct.bitfield_value);
> > > }
>
>



Ivan Johansen (12-04-2003)
Kommentar
Fra : Ivan Johansen


Dato : 12-04-03 22:35

kenneth wrote:
> Ideen med en union er at du har adgang til dine data i en variable når du
> har samlet dine data i dit bitfield.
Det er ikke korrekt. Standarden (§9.5/1) siger at kun et af felterne i
en union kan være aktive. Det vil sige at du ikke kan gøre dig nogen
forventninger til den værdi der læses fra et felt efter at have skrevet
til et andet felt. At det alligevel virker med de fleste kompilere er en
anden sag.

Ivan Johansen


Igor V. Rafienko (11-04-2003)
Kommentar
Fra : Igor V. Rafienko


Dato : 11-04-03 19:32

[ dct_flare@hotmail.com ]

> Jeg (vi) er ved at lave et codec i C++. Dette indebærer at noget
> informtion skal gemmes i 2 - 16 bit alt afhængih af forholdene.


Designer dere formatet selv, eller er dere nødt til å forholde dere
til et allerede eksisterende format?

Dersom det første er tilfellet, kan dere enten gi blaffen i å pakke
data med flere flagg per byte, eller, dersom dette blir for
(plassmessig) kostbart, pakke alle dataene og sørge for å pad'de[*] de
til en passende byte/word grense.

Dersom det siste er tilfellet, hvordan har andre taklet dette formatet
før? Det er _meget_ uvanlig å adressere/skrive/lese enkelte bits.


> Codec'et gemmer i et frameformat med følgende struktur:
> [12x1bit][25x4bit][25x4bit][data skrevet med 2 - 16 bit]


Ok, man bruker (+ 12 100 100) => 212 bit til headere og 2-16 bit med
data. Men siden antall databit er variabelt, må det være en eller
annen angivelse av lengden, hva? Da, siden dere vet hvor mange databit
det er, bare rund opp 212 bit + data bit til nærmeste bytegrense. Dvs.
fil-IO foregår på bytenivå, og dere skriver pack/unpack funksjoner som
konverterer mellom datastrukturen i minne og de faktiske bytene
skrevet ut på fil.


> En lang række af disse frames skal skrives til en fil efter
> hinanden. Men hvordan faen gør jeg dette?


typedef struct playerAction_t {
int direction;
bool_t bomb;
bool_t laola;
} playerAction_t ;

typedef uint16_t action_packet_t;

const size_t UP_DIRECTION = 0x001U;
const size_t DOWN_DIRECTION = 0x002U;
const size_t DIRECTION_MASK = 0x007U;

const size_t BOMB_MASK = 0x080U;
const size_t LAOLA_MASK = 0x100U;

action_packet_t
playerActionToPacked( playerAction_t *pa )
{
action_packed_t value = 0x0U;

switch ( pa->direction ) {
case GO_UP: value |= UP_DIRECTION; break;
case GO_DOWN: value |= DOWN_DIRECTION; break;
default: /* well... ? */
}

if ( pa->bomb )
value |= BOMB_MASK;

if ( pa->laola )
   value |= LAOLA_MASK;

return value;
}


void
playerActionFromPacked( playerAction_t *pa, action_packet_t value )
{
switch ( value & DIRECTION_MASK ) {
case UP_DIRECTION: pa->direction = GO_UP; break ;
case DOWN_DIRECTION: pa->direction = GO_DOWN; break ;
default: /* well...? */
}

pa->bomb = ( value & BOMB_MASK ) ? TRUE : FALSE;
pa->laola = ( value & LAOLA_MASK ) ? TRUE : FALSE;
}

Koden (med visse modifikasjoner) er tatt fra "vår" versjon av spillet
XBlast. playerAction_t beskriver handlingene til hver spiller.
action_packet_t sendes faktisk over nettverket som en byte sekvens
(det er et lite problem med byte rekkefølgen, med htons/ntohs hjelper
også her). Hver gang man skal sende informasjon om hva en spiller
gjør, kaller man playerActionToPacked for å få en "pakket"
representasjon av dette. Som du ser er det en rekke ubrukte bit som
finnes i action_packet_t, men siden disse blir ignorert, spiller det
ingen rolle hva de inneholder[+]. Det er kun disse funksjonene som vet
forholdet mellom de enkelte byte/bit-verdiene og verdiene i
datastrukturen i programmet (i dette tilfellet en array av
playerAction_t).

Det bør også nevnes at "rå" utskrift av struct'er i minne rett til fil
ikke anbefales, da kompilatoren ofte har en rekke friheter hva angår
pakking av ekstra informasjon i struct'ene. Dermed, selv om det er
fristende å gjøre:

typedef struct foo {
int x;
int y;
} foo_t;


foo_t f;
f.x = 42;
f.y = -42;

fwrite( &f, sizeof, 1U, output_stream );

.... bør man ikke gjøre det, siden man ikke nødvendigvis har kontroll
over hva kompilatoren dytter i foo_t. Dette gjelder også
konstruksjoner, der man anvender en union for å overlappe to
datastrukturer:

union {
foo_t f;
char buf[ sizeof( foo_t ) ];
} u;

foo_t f;
f.x = 42;
f.y = -42;

u.f = f;
fwrite( u.buf, sizeof u.buf, 1U, output_stream );

Jeg likte aldri den måten å gjøre ting på, selv om det er nettopp
slike tricks union egentlig anvendes til.

Når alt dette er sagt, er jeg litt usikker på hvordan _faen_ gjør det.
Du får vente noen år til, slik at jeg kan evt. rapportere om det etter
et personlig oppmøte.


> Hvilken metode vil være hensigtsmæssig at bruge. ? Og hvordan skrive
> jeg fx 4 bit tallet 1011 til fil?


Du gjør ikke det. Du kan velge å skrive det ut som en av

bin( xxxx 1011 )
bin( xxx1 011x )
....      
bin( 1011 xxxx )

Akkurat hva x'ene er spiller ingen rolle. Dersom man lar de være 0,
vil mønstrene over svare hhv til dec( 11 ), dec( 22 ) og dec( 176 ).
Siden C dessverre ikke har mulighet til å oppgi konstanter binært,
foreslår jeg hexadesimal notasjon.





ivr
[*] Dette er en voldtekt av det norske språket. Ordet er ment til å
være en oversettelse av det engelske "to pad (something)".
[+] I eksempelet over ville det ha holdt med en byte (heller enn
uint16_t), men i virkeligheten måtte vi ha to.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Flare (13-04-2003)
Kommentar
Fra : Flare


Dato : 13-04-03 14:14

Tak til jer allesammen for de mange forslag. Det er sgu noget nasty noget
jeg har rodet mig ud i. Og efter at have testet noget det ligner 30 ting, er
jeg ikke noget frem til noget der er tilfredsstillende.

God godt vide hvad man "rigtig" gør. Det helt store problem er at bit summen
ikke er et helt multiplum af 16 men kan fx. være 53 7 bit tal der
efterfølges af 45 11 bit tal.

Det er jo svært at pakke 11 bit andet det skal sprede sig over flere
"instanser". Det helt primære er at der IKKE må spildes bytes. Eller er det
jo obsonst at vi laver komplicert beregninger til bestemmelse af om vi fx.
skal brige 9 el 11 bit.

Men jeg må jo kæmpe videre for det skal lykkes.

Mvh
Anders




Flare (13-04-2003)
Kommentar
Fra : Flare


Dato : 13-04-03 17:27

Unionen nedenunder er umiddelbart mit bedste bud på noget som jeg burde
kunne implementere. Men det giver mere eller mindre spilds plads ved visse
bit. Fx hvis jeg vælger 9 bit. Vil jeg have et tab på 7 bit for hver eneste
tal jeg gemmer. Dette er jo ike særlig fantastisk. Men jeg synes sgu ikke
jeg kan komme på en bedre metode?

typedef unsigned short int bit;

typedef struct
{
union
{
bit bit16;

struct
{
bit bit1 : 2;
bit bit2 : 2;
bit bit3 : 2;
bit bit4 : 2;
bit bit5 : 2;
bit bit6 : 2;
bit bit7 : 2;
bit bit8 : 2;
bit bit9 : 2;
bit bit10 : 2;
bit bit11 : 2;
bit bit12 : 2;
bit bit13 : 2;
bit bit14 : 2;
bit bit15 : 2;
bit bit16 : 2;
} bitfield1;

struct
{
bit bit1_3 : 3;
bit bit4_6 : 3;
bit bit7_9 : 3;
bit bit10_13 : 3;
bit bit14_16 : 3;
} bitfield3;

struct
{
bit bit1_4 : 4;
bit bit5_8 : 4;
bit bit9_12 : 4;
bit bit13_16 : 4;

} bitfield4;

struct
{
bit bit1_5 : 5;
bit bit6_10 : 5;
bit bit11_15 : 5;

} bitfield5;

// ====OSV ..
struct
{
bit bit1_9 : 9; //HMMMM her er jo alt for meget spild plads.

} bitfield9;



Niels Erik Danielsen (13-04-2003)
Kommentar
Fra : Niels Erik Danielsen


Dato : 13-04-03 18:31


"Flare" <dct_flare@hotmail.com> wrote in message
news:3e957c78$0$230$edfadb0f@dread15.news.tele.dk...
> Jeg (vi) er ved at lave et codec i C++. Dette indebærer at noget
informtion
> skal gemmes i 2 - 16 bit alt afhængih af forholdene.

Er det du har brug for ikke en bit kø?
En kø hvor du kan indsætte eller fjerne 1 til 16 bit adgangen.

Jeg har endgang lavet en bit stak hvor jeg kan push'e og pop'e 1 til 8 bit
adgangen.
Men jeg ved ikke om denne type løsning er for tung til dit brug..

class CBitStack
{
private:
BYTE m_Stack[50];
int BytePos;
int BitPos;
public:
CBitStack();
void Push(BYTE BitsIn,BYTE NoBit);
BYTE Pop(BYTE NoBit);
GetStak();
PutStak();
}

CBitStack::CBitStack()
{
int BytePos=0;
int BitPos=0;
}

void CBitStack::Push(BYTE BitsIn,BYTE NoBit)
{
WORD Bits;

if (NoBit==0)
{
BytePos=0;
BitPos=0;
m_Stack[0]=0;
}
else
{
BitsIn=BitsIn & ((1<<(NoBit))-1);
Bits=BitsIn<<BitPos;
m_Stack[BytePos]=m_Stack[BytePos]|(Bits&0xff);
m_Stack[BytePos+1]=Bits>>8;

BitPos+=NoBit;
if (BitPos>8)
{
BitPos-=8;
BytePos+=1;
}
}
}

BYTE CBitStack::Pop(BYTE NoBit)
{
WORD Bits;
BYTE OutBit;

if (NoBit==0)
{
BytePos=0;
BitPos=0;
}
else
{
Bits=m_Stack[BytePos]+(m_Stack[BytePos+1]<<8);
Bits=Bits>>BitPos;
OutBit=Bits & ((1<<(NoBit))-1);

BitPos+=NoBit;
if (BitPos>8)
{
BitPos-=8;
BytePos+=1;
}
}
return OutBit;
}




Bertel Lund Hansen (13-04-2003)
Kommentar
Fra : Bertel Lund Hansen


Dato : 13-04-03 18:47

Flare skrev:

>Jeg (vi) er ved at lave et codec i C++. Dette indebærer at noget informtion
>skal gemmes i 2 - 16 bit alt afhængih af forholdene.

>Codec'et gemmer i et frameformat med følgende struktur:
>[12x1bit][25x4bit][25x4bit][data skrevet med 2 - 16 bit]

>En lang række af disse frames skal skrives til en fil efter hinanden. Men
>hvordan faen gør jeg dette?

>Hvilken metode vil være hensigtsmæssig at bruge. ? Og hvordan skrive jeg fx
>4 bit tallet 1011 til fil?

>Nogen ideer (erfaringer) hvordan man griber dette an?

Her er et program der kan gemme værdier helt tæt i en buffer. Det er på
kladdeniveau, men virker hvis man ikke stresser det. Det kan kun håndtere
positive tal (negative tal og tæt pakning rejser nogle problemer) og størrelser
under 30 bits.

Princippet er at man pakker en stribe tal med stuff(bits,value). Bagefter
kan de pakkes ud med retrieve(bits). Både pakning og hentning skal
foregå i ´rækkefølge.

Jeg vil dog ikke specielt anbefale det fordi de fordele det giver, næppe
opvejer ulemperne. Forestil dig f.eks min skuffelse da jeg i en måneds tid
havde finpudset et primtalsprogram der kunne pakke alle primtal op til 22 mio.
på en almindelig floppy (Erathostenes' si og bitpilleri), da jeg opdagede at
en zipning af en banal liste fyldte lige så lidt.

Programmet holder styr på positionerne ved hjælp af int pos_byte og pos_bit.
Så ved man hvor langt man er kommet i bytes og hvor mange bits deri der
allerede er optaget.

Bufferen er vilkårligt sat til 1000 byte, men kan naturligvis udvides efter behov.
Den kan så skrives til en fil når den er fyldt op, men det har jeg ikke kodet.


/* Buffer til opbevaring af værdier der spænder over et varierende antal bits.

Alle printsætninger uden for main() er i koden skrevet helt til venstre.
De bruges kun til kontrol og forklaring. Ligeså display().

Mulige katastrofer:
Der bruges ikke reset() før man henter data. Man vil da læse frem i en udefineret buffer.
Bitantallet ved hentning svarer ikke til antallet ved gemning.
Hentede data vil da være meningsløse fra første fejl og fremefter.

Negative tal kan ikke klares.

Der er ingen egentlig fejlhåndtering.
*/

#include <stdio.h>


// Bruges kun til testdata.
enum { ANTAL=4 };

// Testdata: (antal bits, værdi)
const int t[][2] = { {15,7}, {26,8}, {7,30}, {3,4} };


class Buffer {
public:
Buffer () { pos_byte=0, pos_bit=0; buff[0]=0; }
void stuff (const int &bits, int val);
void display ();
void reset () { pos_byte=0; pos_bit=0; };
int retrieve (const int &bits);

private:
int pos_byte, pos_bit;
unsigned char buff[1000];
};


void Buffer::stuff (const int &bits, int val) {
if (val<0) throw 1; // Primitiv fejlhåndtering.
if (bits>30) throw 2; // Undgår de værste katastrofer.
int max=1;
for (int b=0; b<bits; ++b) max*=2;
if (max<=val) throw 3;

printf("Val: %d ",val);
val<<=pos_bit;
printf("Skiftet val: %d Pos_bit: %d Pos_byte: %d\n",val,pos_bit,pos_byte);
buff[pos_byte]+=val & 0xFF;
pos_bit+=bits;
while (pos_bit>7) {
val/=256;
++pos_byte;
buff[pos_byte]=val & 0xFF;
pos_bit-=8;
}
}


void Buffer::display () { // Beregnet til kontrol.
int temp, mask;
for (int b=pos_byte; b>=0; --b) {
printf(" ");
temp=buff[b];
mask=128;
for (int n=0; n<8; ++n) {
if (temp & mask) printf("1");
else printf("0");
mask/=2;
}
}
printf("\n\n");
}


int Buffer::retrieve (const int &bits) {
unsigned int temp, mask=1;
int nr=pos_bit+bits, faktor=256;

printf("Pos_bit: %d Pos_byte: %d\n",pos_bit,pos_byte);
temp=buff[pos_byte];
while (nr>7) { ++pos_byte; nr-=8; temp+=buff[pos_byte]*faktor; faktor*=256; }
for (int n=0; n<pos_bit; ++n) temp/=2;
for (int n=1; n<bits; ++n) mask=mask*2+1;
printf("Bits: %d Maske: %d Temp: %d\n",bits,mask,temp);
pos_bit+=bits;
if (0 && pos_bit>7) {
pos_bit-=8;
++pos_byte;
}
pos_bit=nr;
return temp & mask;
}



int main () {
Buffer field;
for (int n=0; n<ANTAL; ++n) {
printf("(%d, %d) ",t[n][0],t[n][1]);
}
printf("\n\n");
for (int n=0; n<ANTAL; ++n) {
field.stuff(t[n][0],t[n][1]);
field.display();
}
field.reset();
for (int n=0; n<ANTAL; ++n) printf("Hentet: %d\n",field.retrieve(t[n][0]));

return 0;
}


--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

Flare (13-04-2003)
Kommentar
Fra : Flare


Dato : 13-04-03 18:54

Det kan kun håndtere
> positive tal (negative tal og tæt pakning rejser nogle problemer) og
størrelser
> under 30 bits.

Lige før jeg begynder at nærstudere din kode er mit behov at kunne pakke tal
fra 2 - 16 bits efter hinanden. Har du formuleret din sætning forkert?

Anders



Bertel Lund Hansen (13-04-2003)
Kommentar
Fra : Bertel Lund Hansen


Dato : 13-04-03 19:11

Flare skrev:

>Lige før jeg begynder at nærstudere din kode er mit behov at kunne pakke tal
>fra 2 - 16 bits efter hinanden. Har du formuleret din sætning forkert?

Næ. Jeg har bare lavet en ret generel kode. Den ville ikke blive
ret meget enklere af at jeg nøjes med 16 bit som maksimum.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408924
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste