On 24 Sep, Sigbjørn Skjæret wrote:
>>> 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.
Yes. Are there many fixed values in lame?
>>> 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.
"KISS".
>>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
I'm waiting for your solution which didn't need casts (and remember the
mail which talked about casts in lame).
Bye,
Alexander.
--
Intel: where Quality is job number 0.9998782345!
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
