Sigbjrn Skjret wrote:
/* 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).
HP-UX 10.20 man varargs say that it has only one arg.
Frank Klemm wrote:
:: /* 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" ,
-Original Message-
From: David Balazic [mailto:[EMAIL PROTECTED]]
Sigbjrn Skjret wrote:
/* 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
Mathew Hendry schrieb am Don, 28 Sep 2000:
From: Mathew Hendry
varargs.h is pre-ANSI and non-standard - use stdarg.h for
the standard stuff. Should be
va_start(ap)
Oops! I mean
va_start(ap, lastarg)
where ap is your va_list and lastarg is the last non-variadic
Mark Taylor schrieb am Die, 26 Sep 2000:
I think we have to keep the old interface, since several applications
use it. So lame_global_flags will still have to be instantiated by the
calling program and exposed to the calling program. I dont think this
is incompatiable with a shared library?
:: Sigbjørn Skjæret schrieb am Die, 26 Sep 2000:
::Why do we need float at this point ??
::
:: Because several of the parsed arguments are floats?
::
:: ie. frequencies could be passed in Hertz as ints,
:: was just something to think about now while we
:: change the API
Sigbjrn Skjret 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
"R" == Robert Hegemann [EMAIL PROTECTED] writes:
R Mark Taylor schrieb am Die, 26 Sep 2000:
I think we have to keep the old interface, since several
applications use it. So lame_global_flags will still have to
be instantiated by the calling program and exposed to the
IIRC, if you use varargs then the compiler can't detect if the supplied
parameters
are of wrong type. Example :
[...]
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.
This is indeed true, and
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.
I think we have to keep the old interface, since several applications
use it. So
and parsing gets abit more messy...
How ?
[...]
This is how it looks now, better than using va_arg() at each case imho...
void lame_set_int(lame_global_flags *gfp, lame_param_tag tag1, ...)
{
va_list ap;
int param; /* (varargs promotes integrals to int) */
va_start(ap, tag1);
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)
:: /* 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);
::
On 25 Sep, Sigbjørn Skjæret wrote:
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*"
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. ;)
"Keep It Simple, Stupid".
[...]
Right, well, I believe that's exactly what it is now. ;)
- CISC
--
MP3 ENCODER mailing list (
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.
Sigbjørn Skjæret schrieb am Die, 26 Sep 2000:
Why do we need float at this point ??
Because several of the parsed arguments are floats?
ie. frequencies could be passed in Hertz as ints,
was just something to think about now while we
change the API anyway
Should
Why do we need float at this point ??
Because several of the parsed arguments are floats?
ie. frequencies could be passed in Hertz as ints,
was just something to think about now while we
change the API anyway
Yes, but no reason not to have the possibility there. ;)
Should I start implementing this now, or wait after 3.87 release?
Hi CISC,
3.87 was released last night. It's mostly just to have a
last release before the code re-orginization that Takehiro
is going to do this week. That will involve splitting
the C code into a frontend and library
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
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
I think we can make a very simple library setup stuff:
proposal:
int lame_open();
// allocates internal structures
int lame_set_param( int handle, LameParameter Parameter, int Value );
// assigns Lame's parameter a value
int lame_init_params( int
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
[...]
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 not something like:
lame_set_float(char *variable_name, float val);
lame_set_int(char *variable_name, int val);
Hey, gr8, idea, and maybe another with void*?
But this brings up another question: The code is going to do a lot of
parsing, and it looks like each variable will require several
Sigbjørn Skjæret schrieb am Mon, 25 Sep 2000:
[...]
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
::
:: proposal:
::
:: int lame_open();
:: // allocates internal structures
::
:: int lame_set_param( int handle, LameParameter Parameter, int Value );
:: // assigns Lame's parameter a value
::
a) Not every variable is an integer. C programmer try to store everything
On 23 Sep, Sigbjørn Skjæret wrote:
Ok, after thinking about this for a while, and experimenting a little, I
thought of a couple of issues with using TagItems to pass configuration
settings in LAME...
1.) Floats and doubles will lose all it's precision (this can be simply
avoided by
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
Ok, after thinking about this for a while, and experimenting a little, I
thought of a couple of issues with using TagItems to pass configuration
settings in LAME...
1.) Floats and doubles will lose all it's precision (this can be simply
avoided by passing the string-pointer from arg-parsing
30 matches
Mail list logo
