>>>> 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?
If you read parse.c you'll see that there's a few values that's atof()ed
straight in.
>>>> 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".
I'm not even gonna ask. ;)
>>>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).
Eheh, well, we'll see what I can cook up. ;)
- CISC
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
