>> This is how it looks now, better than using va_arg() at each case imho...
>Why is it better ?
>You wasted an additional variable and gained ( maybe ) some code space
>by not doing a function call ( or maybe it is a macro , probably
>platform dependant ) every time.
It's usually a (rather messy) macro. ;)
>By writing almost the same code 3 times you increase the likehood of
>bugs 3 times :-)
>Alltough most of the code would be repeated anyway.
True, but there's not much space for error. ;)
[...]
>#define CASE(TAG,elem,type) case LAME_ ## TAG : gfp -> elem =
>va_arg(args, type); break;
> CASE( SET_SAMPLING_FREQ , samp_freq , int )
[...]
That's actually not a bad idea...
>/* in my man page va_start has only one argument (ap) ... */
Your man-page is wrong then I think, the second argument is so that va_arg()
knows where to start (ie, it makes ap point to the next argument).
>> I can still implement a way to have the tag also contain the type of the
>> parameter, but since the general consensus seemed to be that this would be
>> too complicated I went for this approach... ;)
>But your existing tag "contain" the type , at least as much as they
>would in my method.
What I meant was that I could device another way of passing the tags that
would allow me to supply information of the parameters type (ptr/float/int),
but this isn't too convenient at the calling end.
>#ifdef YOU
>#define SOME_TAG some_int_value
>#else
>#define SOME_TAG some_int_value
>#end
What was the purpose of this?
>Unless I use
>SOME_TAG__WARNING_THIS_IS_FLOAT_AND_NOT_INT_OR_ANYTHING_ELSE,
>but that is not the point , since it would work both with your and my
>code.
The advantage of having 3 different functions is also that you at a later
stage can change the type of the internal parameter, and still accept the
old without having to add a duplicate tag (f.ex. if you change from int to
float, then you can just add the tag to lame_set_float(), and add a cast in
lame_set_int)...
- CISC
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
