Sigbjřrn Skjćret wrote:
> 
> >> >This way there is no need to parse any strings, we don't pass
> >> >any pointers, the setup routine would just be a big switch/case.
> >> This is basically the way TagItems work when passed on stack, in fact, that
> >> combined with another identical function that does float we're pretty much
> >> set.
> >       Why do we need float at this point ??
> 
> Because several of the parsed arguments are floats?
> 
> Well, anyway, I just finished up the following:
> 
> /* Set a parameter with string-pointer */
> void lame_set_string(lame_global_flags *gfp, lame_param_tag tag1, ...);
> 
> /* Set a parameter with float or double value (varargs promotes floats to double) */
> void lame_set_float(lame_global_flags *gfp, lame_param_tag tag1, ...);
> 
> /* Set a parameter with char, short or int value (varargs promotes integrals to int) 
>*/
> void lame_set_int(lame_global_flags *gfp, lame_param_tag tag1, ...);

IIRC, if you use varargs then the compiler can't detect if the supplied
parameters
are of wrong type. Example :

/* sample freq is an int , but be supply a float */
lame_set_int(gfp, LAME_SAMP_FREQ, 44101.213 );

The compiler won't notice that the parameter is of wrong type
and when the function will try to extract an int from the stack,
it will get garbage.


But if this is of no concern , then a simpler interface can be used :

lame_set_parameters(lame_global_flags *gfp, ...);
/* or this one , as the type of the first argument is always the same */
lame_set_parameters(lame_global_flags *gfp, lame_param_tag tag1, ...);

/* Usage :
lame_set_parameters(gfp, LAME_SAMP_FREQ__INT, 44100 ,
LAME_NR_CHANNELS__INT , 2 ,
                    LAME_LOW_PASS_VALUE__FLOAT , 16.050 ,
LAME_LOW_PASS_WIDTH__FLOAT , 0.75,
                    LAME_COMMENT__STRING , "This is cool" ,
LAME_END_MARKER);

LAME_END_MARKER informs the lame_set_parameters to stop reading values,
as AFAIK
there is not other way to determine whether all the args has been read 

the __FLOAT and __INT attachments are there only to help illustrate my
idea,
but could be helpful in the actual implementation too

*/


 
> This can cater for any kind of parameter, and the functions themselves are
> very simple, yet can take several parameters in a row...
> 
> Should I start implementing this now, or wait after 3.87 release?
> 
> Mark?
> 
> What needs to be changed to make a real shared library:
> 
> o Exchange all direct access to lame_global_flags in parse.c with calls to
>   lame_set_xxx().
> 
> o main.c can't hold lame_global_flags, change lame_init() to allocate and
>   return a pointer to lame_global_flags.
> 
> o Move lame_global_flags out of lame.h, it should never be accessed externally.
> 
> o ..and any other changes still needed for re-entrance ofcos.
> 
> - CISC
> 
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

-- 
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Reply via email to