🚀 go-pugleaf

Onno Hovers schreef:

>Robert Amesz <rcameszREMOVETHIS@dds.removethistoo.nl> wrote:
>> Frans Bouma schreef:
>
>>>    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 ;)
>
>> Om nog maar te zwijgen van het feit dat de datafiles die je op die
>> manier maakt ook niet overdraagbaar zijn naar big-endian
>> processoren, althans niet zonder de hele lees- en schrijfroutines
>> te herschrijven. 
>
>Hoe had je het dan gehad willen hebben?  Een taal die op
>little-endian processoren met big-endian getallen moet werken of
>andersom?

Huh? Natuurlijk niet.


> En hoe moeilijk is het nou om ntohl(), htonl(), ntohs() en
>htons() te gebruiken?
>

Moeilijk? Nee! Maar sommigen vinden het toch te bewerkelijk of weten 
niet beter, en gaan dan dingen doen als:

  fwrite(& mystructinstance, sizeof(struct mystruct), 1, somefile);

Dan krijg je bestanden waarin de lengte en bytevolgorde afhangen van 
zowel de compiler als de processor. We waren het er geloof ik allemaal 
wel over eens dat dat een Heel Slecht Idee is. <g>

Overigens zit je nog steeds met een probleempje als je je floats, 
doubles of long longs (64 bits) portable wilt opslaan, daar moet je
dan zelf iets leuks op verzinnen. Voor die long long is dat niet echt
een probleem, maar voor floating point getallen is dat lastiger omdat
daar een groot aantal binaire formaten voor bestaat. Als je geen 
nauwkeurigheid wilt verliezen is het opslaan als ascii vaak de enige
goede oplossing. 


Robert Amesz