On (02 Sep 97) Roger Scudder wrote to Jerry Coffin...
 RS>  I want to take it in the direction of C++ so I moved it to
 RS>  the C++ echo.
Sounds good to me...
 RS>  Speaking only of decelerations for now... I want to get away from
 RS>  decelerations of main and discuss function decelerations other
Just FWIW, that that's properly spelled "declarations".
 RS>  that main.   A function deceleration and a function prototype
 RS>  are the same thing, right?
In C++ they are.  In C, they're not.  In C a prototype is also a
declaration.  However, a declaration is not a prototype - a declaration
specifies that some particular name is the name of a function, but it
says nothing about the arguments to the function.
In C++, all function declarations specify the arguments the function
takes, so there's no distinction between a declaration and a prototype.
 RS> I mean a prototype does not allocate memory.
That's correct.
 RS> I'm not sure just how it works, but you can not call a function
 RS> until it had been defined, right?
Not exactly true.  If you call a function, it must be defined somewhere,
sometime and be available when you go to link the program.  However, the
function can be defined well _after_ the code that calls it is defined.
The classic example of this is the qsort function, which calls a
function you supply (via a pointer).
 RS>  So is a prototype just a string literal that the compiler can use
 RS>  as a guide to check against any subsequent definitions of the
 RS>  function for differences?  Is the prototype copied into some
 RS>  reference table or something?
Yes and no.  The compiler will create a symbol table entry based upon a
prototype or declaration.  Normally when you store the information in
the symbol table, you don't store it as a string.  Instead, you'd have a
data structure something vaguely like this:
class {
    TYPE ret_type;
    char *name;
    ARGS arg_list;
};
However, this is conceptually about the same as storing the prototype as
a string; it allows the compiler to look at function calls and compare
them to the declarations it's already seen.
 RS>  Going back to the original thread, The book I am reading right
 RS>  now, which may be outdated (1994) on this topic, states that an
 RS>  ANSI C compiler will evaluate a prototype (or deceleration)
 RS>  int foo() and int foo(...) as equivalent.
A C compiler will evaluate `int foo()' as equivalent to the way a C++
compiler evaluates `int foo(...)', but `int foo(...)' is not legal in C.
(or at least leads to undefined behavior...)
 RS> OTOH, a C++ compiler
 RS>  will interpret int foo() as meaning int foo(void).  It states
 RS>  that the syntax int foo() is obsolete under C++.
The first of these is correct.  The second not so at all.  In fact, I'd
consider the syntax `int foo(void)' as obsolescent under C++, with `int
foo()' the preferred syntax.  IIRC, function declarations in C were
deprecated in the last standard, meaning they may dissappear at some
point, and `int foo()' will mean the same thing in C as it presently
does in C++.
 RS>  Right, but I want to explore decelerations of other functions.
 RS>  I want to know if you agree with the book (FWIW - it is named
 RS>  "The Revolutionary Guide to OOP Using C++") that int foo() is
 RS>  obsolete under C++ and that a C++ compiler will not evaluate
 RS>  a deceleration of int foo() as equivalent to int foo(...) as
 RS>  is the behavior for a ANSI C compiler.
As I said above, no I don't agree that it's obsolete or even
obsolescent.  If you're writing true C++, I would reccommend using empty
parens to indicate that the function takes no parameters.  I'd use
"void" between the parens if you're writing code that you want to work
as either C or C++.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------