>> 1.) Floats and doubles will lose all it's precision (this can be simply
>> avoided by passing the string-pointer from arg-parsing and converting
>> when parsing TagItems instead)
>What about passing the pointer to the float/double instead?
Sure, but that means you will have to temporarily store the value somewhere
else.
>> 3.) 64bit pointers will be truncated (not too much trouble unless you have
>> and use more than 4gig of memory in your machine).
>Don't keep the AmigaOS compatibility of my functions (see bellow why)
>and change the data part (ti_Data) of the struct to "void*".
Hmmm, yes, maybe, if the compiler allows it. ;)
>> simply making a new TagItems interface which allows you to specify the type
>> of data the TagItem contains. This will be much better in the long run, and
>> will allow the TagItems to contain any type of data.
>This sounds more complex than my proposed "void*" change. Keep in mind:
More complex, but not that hard.
>the Amiga TagItem implementation was done with 32bit pointers in mind
>and not with portability. An (IMHO) more elegant (and still simple)
>solution for the data part would look like
[...]
>The first proposal is IMHO enough for everyday use, the second is for
>architectures which didn't allow lossless transportation of information
>between a void* and an integer type (in case you use ti_data to contain
>the information instead of a pointer to the information).
Only "problem" I can see immediately with void* is that all values needs to
be casted, which wasn't strictly necessary with unsigned long, and float/
double still needs to be temporarily stored. :P
- CISC
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
