🚀 go-pugleaf

Frans Bouma wrote:
> 
> "Sjoerd Schreuder" <sa_schreuder@wanadoo.nl> wrote in message news:3C762FF1.B9125B5B@wanadoo.nl...
> > Frans Bouma wrote:
[..stukken geknipt om het overzichtelijk te houden..]
> > Waarom zou je je eigenlijk vastleggen op little of big endian?
> 
>     hoe zou je het dan willen oplossen? :)

Kiezen voor "native", wat dat ook moge zijn. En verder converteren bij I/O.
Redelijk recht-toe-recht-aan, en optimaal voor elk platform. Hooguit
wat meer code, maar die code kan automatisch gegenereerd worden.

> > Dat is alleen van belang als je de individuele bytes van een word
> > kunt aanspreken. Dus in de volgende gevallen:
> > * Het casten van een pointer-to-word naar een pointer-to-byte.
> > * Het streamen van words naar externe bronnen zoals een file of
> >   het netwerk.
> >
> > Het eerste geval wil je gewoon niet in je taal hebben zitten
> > (of maak je "implementation defined", zoals C en C++ doen).
> > In het tweede geval kun je zonder probleem een conversieslag doen
> > omdat je I/O toch al snelheidsbepalend is.
> >
> > Dus mij lijkt het dat de beste oplossing is vrij te laten welke
> > vorm intern wordt gebruikt. Voor externe representatie moet je
> > dan wel een standaard kiezen, maar daar zijn al een heleboel
> > standaards voor: Unicode, TCP/IP, CORBA, ...
> 
>     Nou, als er gekozen zou zijn binnen de CLR voor big endian, dan
>     had elke operatie naar fysiek memory een conversie nodig gehad,
>     wanneer je in mixed mode werkt, of wanneer code buiten de CLR
>     aangeroepen worden. Lijkt me niet zo verstandig.

Je negeert totaal mijn oplossing: laat het vrij in de standaard
en gebruik de native ordening. Bij mixed-mode hoef je dan niet
te converteren, want die andere code gebruikt ook de native ordening.

Bij jouw oplossing moet je ook converteren als je native code aanroept
op een verkeerde endian machine. Aangezien je niet weet of je code
op zo'n machine gaat draaien, zul je die code altijd moeten schrijven
indien je native code wilt aanroepen.

>     Maar ik denk dat hier van een mug een olifant gemaakt
>     wordt. In een hogere ordetaal werkt men met typed data, en
>     hoe individuele bytes zijn gerangschikt is veelal niet van belang:
>     voor het optellen van een short bij een int is het niet van belang
>     die volgorde te weten, alleen bij het lezen van data uit een file
>     die is geschreven met een C programmaatje bv, dan moet je weten
>     of de 4 bytes die een int voorstellen, ook in hetzelfde format
>     staan als de endian-configuratie van het platform waar de inlezende
>     partij op draait. Voorbeeld hiervan is het inlezen van TGA files
>     op inteldozen :)

Met je eens. Alleen bij I/O maakt het uit, dus waarom zou je het vastleggen
voor berekeningen die niets met I/O te maken hebben?

> > > > Gezien de keuzes die ze hebben gemaakt, lijkt de huidige Pentium
> > > > processor de voornaamste target van de standaard te zijn.
> > >
> > >     Je moet EEN keuze maken.
> >
> > Waarom zou je een keuze MOETEN maken? C en C++ doen dat ook niet,
> > en je kunt moeilijk zeggen dat die talen niet bestaan.
> 
>     je moet toch je 4 byte dwords opslaan in een volgorde. Voor
>     de C/C++ programmeur is dat steevast niet belangrijk, totdat
>     er bv een blok data ingelezen wordt wat de inhoudt van een struct
>     is, dus wat je bv direct naar een struct cast.

Dat moet je dus niet doen. De functies ntohl() bestaan toch ook al jaren?
Verder bestaan er al genoeg standaards om gegevens binair uit te wisselen.
Zo heeft elke CORBA implementatie wel een idl-compiler die de marshalling
voor je genereert. Dan heb je er geen omkijken meer naar.

>           Is die data
>     weggeschreven op een big-endian bak, dan is het lastig werken
>     op een intelbak. Ookal zit je in C/C++. Maar omdat dit niet
>     alledaagse problemen zijn: nogmaals: hier wordt van een mug
>     een olifant gemaakt, wat niet vreemd is bij rethoriek, afkomstig
>     uit de Warmelink-hoek :)

Zucht. Bij gebrek aan argumenten ga je maar op de man spelen? Had ik
niet van je verwacht.

> > Maar misschien ben ik te veel beinvloed door C en C++, waar dat allemaal
> > aan de compilerbouwer wordt overgelaten. Die kan een keuze maken die
> > voor dat platform natuurlijk is.
> 
>     valt uiteraard veel voor te zeggen. Maar als je zit te werken in taal A,
>     zonder maximale waarden voor lengtes en 64bit wordt gekozen voor ints,
>     hoe zijn dan de datablokken inwisselbaar met classes geschreven in taal
>     B met maximale lengte voor ints van 32bits? Dat levert weer marshalling
>     ellende op, iets wat men juist wil vermijdden.

Die marshalling kunnen idl-compilers prima voor hun rekening nemen. En het
idl formaat is toch ondertussen al redelijk standaard. Misschien nog niet
de jure, maar wel de facto.

In een poging de discussie af te ronden:

We zijn het dus eens dat alleen bij I/O (inclusief aanroep andere code)
het noodzakelijk is om het formaat vast te leggen. Mijn oplossing is om
het formaat van I/O vast te leggen en te converteren tijdens I/O, jouw
oplossing is om voor het hele programma de little/big endian vast te leggen.

In beide gevallen moet er soms geconverteerd worden, maar die code
kan automatisch gegenereerd worden.

Beide oplossingen zijn mogelijk (alhoewel misschien niet optimaal),
ik hoop dat we dat eens zijn.

We wegen de voor- en nadelen verschillend, waardoor we op een verschillende
voorkeur uitkomen.

Dus: let's agree to disagree.

Sjoerd Schreuder