🚀 go-pugleaf

"KLinZ" <klinz@NOSPAMhetnet.nl> wrote in message news:yXEG5.22824$Z7.395483@nlnews00.chello.com...
> Nee, dit blijft 8 bytes omdat BYTE blijkbaar ook 4 bytes is. Maar als je dit

    nee dat was mijn fout. BYTE is 1 byte. BOOL is wel 4 bytes (long), om
    onverklaarbare reden.

> doet
> 
> typedef struct {
>        unsigned char var1;
>        DWORD var2;
> } _test;
> 
> kan deze struct ook 8 bytes groot zijn. Er kunnen nl. 3 padding bytes
> toegevoegd worden achter de unsigned char. Zodat var2 op een dword-aligned
> boundary terecht komt.

    nee, althans niet in VC++. Je moet vziw specifiek aangeven dat je packing
    aanzet en dus offsets gebruiken wilt bij de boundaries van structure members
    (met compiler optie /Zp[n], n is hoeveelheid bytes)

> > Mede door deze "onzin"(IMHO) denk ik er voorlopig niet aan om met C/C++
> > te beginnen. Waar slaat dit nou in hemelsnaam op(bij C/C++, niet jouw
> > antwoord)? Is dit ANSI C (werkt het ook op een andere processor dan
> > Intel-compatible)? Hoe is dit te rijmen met het antwoord van FB, die zegt
> > dat een byte is gedefd als een int? Wordt er gewoon een byte van die int
> > afgehakt?
> >
> 
> Ik wist niet dat in msvc BYTE gedefinieerd was als int, ik nam aan dat BYTE

    doet hetook niet *(#&$@($@ :) mijn fout.

> gewoon een unsigned char was. Nee, die #pragma is erg compiler specifiek. In
> Ansi C is het volgens mij  (maar daar zou je de standaard op na moeten
> slaan) toegestaan dat de compiler padding bytes toevoegd in structs. Met die
> #pragma kun je dus aangeven dat je dat niet wilt. Dit zijn trouwens dingen
> waar je niet veel mee te maken heb als je begint met C/C++. Dat msvc BYTE
> als int definieert is natuurlijk op z'n minst verwarrend te noemen.

    het is een byte.
    BOOL is wel een long, wat volgens mij wel problemen oplevert, maar
    sowieso is het porten van code met structures een hell, bv het
    porten van VC++ code naar gcc, als je beide executables dezelfde data
    formats wilt laten lezen/schrijven.

        FB