Hi all,
i would like to discuss some problems related to new vector
format/library i am working on.
1) Little or big? Dig files are written (version 4) in portable vector
format which is big endian byte order (note for David: I was wrong
in my last mail).
On little endian machines (i386 for example) byte order of each
number must be changed. My test with d.vect says that such
conversion takes 8% of time
Hi Radim.
I've used, in the past, a little different model, where you
check if the file byte-order matches or not the current platform
byte-order. Thus avoiding unrequested conversions.
In this case one should have the possibility to write files in both
big and little endian flagged by a specific field, and/or
be able to convert them.
Ciao.
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
"mi.ro@iol.it" <mi.ro@iol.it> wrote:
> Hi all,
>
> i would like to discuss some problems related to new vector
> format/library i am working on.
>
> 1) Little or big? Dig files are written (version 4) in portable vector
> format which is big endian byte order (note for David: I was wrong
> in my last mail).
> On little endian machines (i386 for example) byte order of each
> number must be changed. My test with d.vect says that such
> conversion takes 8% of time
Hi Radim.
I've used, in the past, a little different model, where you
check if the file byte-order matches or not the current platform
byte-order. Thus avoiding unrequested conversions.
In this case one should have the possibility to write files in both
big and little endian flagged by a specific field, and/or
be able to convert them.
Ciao.
Seems to be best for speed, I am bit wory about such byte order flexibility
> Hi all,
>
> i would like to discuss some problems related to new vector
> format/library i am working on.
>
> 1) Little or big? Dig files are written (version 4) in portable vector
> format which is big endian byte order (note for David: I was wrong
> in my last mail).
> On little endian machines (i386 for example) byte order of each
> number must be changed. My test with d.vect says that such
> conversion takes 8% of time
Hi Radim.
I've used, in the past, a little different model, where you
check if the file byte-order matches or not the current platform
byte-order. Thus avoiding unrequested conversions.
In this case one should have the possibility to write files in both
big and little endian flagged by a specific field, and/or
be able to convert them.
Ciao.
(Sorry again, last mail was cut)
Seems to be best for speed, I am bit wory about such byte order flexibility