"Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
news:%23Fl$xrC8HHA.3900@TK2MSFTNGP02.phx.gbl...
Don't quite qet what you mean here. If it didn't know the prototype,
how would it know what the function did?
The compiler never knows what "extern" functions do, it just generates
references which the linker must resolve.
But it needs to see the declaration.
In the "C" language (not C++), it is possible to call a function without
a prototype. The parameter types are inferred from usage and the return
type is assumed to be an int (in EAX because the calling convention is
assumed to be cdecl on x86). If the function really returns a double, it
uses the FPU stack to do so. The compiler would not know that, however,
but instead use the value of EAX in the expression, generating the wrong
result.
Ok.
None of this applies to C++, thankfully (although if you use command line
options for calling conventions instead of specifying per-function, you
can get similar problems).
Ok. But in this case, removing the include that
pulled in cstdlib (iostream actually) then the compiler
generates the error that it can't find this function
declaration as I would expect. A good example why
In C++ it does. In C that's just a warning which is ofter overlooked or
you should always include the libs that you need.
Still no idea why atof() is so slow in this
example.