🚀 go-pugleaf

"Matthijs" <matthijslaan@NOSPAMcia-agent.com> wrote in message news:MPG.14552ffc56413268989718@news.xs4all.nl...
> 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?

    sorry, mijn fout, ik was even in de war met een BOOL wat als een long
    is gedefineerd. een BYTE is gewoon als een unsigned char getypedefd
    (WTYPES.H)

    Visual C++ doet standaard niet aan alignment vziw, tenzij je dat als optimalisatie
    opgeeft. een byte en een int in 1 struct zetten is mateloos inefficient. Beter
    is om gewoon 2 ints of 3 extra bytes op te nemen, zodat je int op een longword
    boundary blijft. 

    gcc e.d. doen standaard wel aan alignment van dit soort dingen en je moet dan
    dus zelf de pragma's toevoegen om de packing van de structdata goed te krijgen.
    Dit kan een probleem zijn als je blokken data moet inlezen en die blokken stellen
    structs voor (erg fijn ;)). code dat in VC++ is geschreven werkt dan niet met
    gcc, omdat gcc standaard een byte als 4 bytes in een structure opneemt (terecht,
    dat is veel sneller) echter als je data gepacked is zonder paddingbytes dan
    werkt het niet echt ;)

    Maak je echter gebruik van datafiles die je hebt gecreeerd met je eigen code
    die is gecompileerd met dezelfde compiler, dan is er niets aan de hand.

    Wat in de taalsyntax klopt heeft niet zoveel te maken met de gecompileerde binary.
    Een van de gebreken aan C/C++ is dat er geen binaire standaard is, waardoor
    gecompileerde C++ code niet t.a.t. dezelfde richtlijnen volgt, bv voor 
    data alignment, etc etc.

        FB