na********@gmai l.com wrote:
Is the ellipsis( ... ) a part of C/C++
Yes. When C++ was designed, C generally used the syntax
int foo();
to declare functions. C had no type checking of the arguments, so this
means «declare function foo to take any number of arguments, and return an
int». In really old text books, code would often just declare functions
from the standard library instead of including the proper header. Foo could
be defined in another compilation unit as:
int foo(bar)
int bar;
{ return do_stuff(bar); }
As you can see, «any number of arguments» usually means «whatever the
function expects». Dennis Ritchie has commented on this here:
http://www.lysator.liu.se/c/chistory.ps.
For another comment on the implications, I refer to the third commandment:
http://www.lysator.liu.se/c/ten-commandments.html
In C++, the function declaration syntax came to use the syntax we know
today, but to support the concept «any number of arguments», as some C
library functions use, ... was introduced.
or stdarg.h?
No.
If its part of the C/C++, then shouldnt the compiler know where the end of
the arguments is
Yes.
and automatically insert a NULL?
No.
Maybe this is not how C/C++ is designed but what are the disadvantages if
it is so?
First of all, what is NULL? In C++, it's an integral constant, while in C,
it's an implemention defined pointer constant. There's no general way for
the compiler to know what types a function expects for ..., and it would be
nice if you could use more than one type in ...? So, while there are no
general disadvantages, there are no real advantages either. And if you can,
you should avoid using ... in functions.
--
rbh
