Hi JERRY,
JERRY COFFIN was observed on 04-Sep-97, writing to ROGER SCUDDER
          Something about: void main() again / size
 RS>> decelerations of main and discuss function decelerations other
 JC> Just FWIW, that that's properly spelled "declarations".
 Yeah , a matter of not paying enough attention to what I was
 allowing my spell checker to change. :-/
 RS>> that main.   A function deceleration and a function prototype are
 RS>> the same thing, right?
 RS>> I'm not sure just how it works, but you can not call a function
 RS>> until it had been defined, right?
 JC> Not exactly true.  If you call a function, it must be defined
 JC> somewhere, sometime and be available when you go to link the
 JC> program.  However, the function can be defined well _after_ the
 JC> code that calls it is defined.
 JC> The classic example of this is the qsort function, which calls a
 JC> function you supply (via a pointer).
 Right, like when you do a gcc -c to compile only, the code can
 contain calls to functions that are not defined.  Or at least
 the definitions are not visible to the module being compiled.
 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) int
 RS>> foo() and int foo(...) as equivalent.
 JC> A C compiler will evaluate `int foo()' as equivalent to the way a
 JC> C++ compiler evaluates `int foo(...)', but `int foo(...)' is not
 JC> legal in C. (or at least leads to undefined behavior...)
 Yes, I discovered that while trying some test compiles. In the
 following example, calling foo tore Borland C++ 3.1 to shreads.
void foo(...);
void foo(char *s, int num)
{
    printf("%s%d",s, num);
}
 I compiled it as a c++ program so I'm not sure why it blew up and
 why it was not flagged in the compile stage.
 Windows 95, is at least a little more congenial about allowing
 you to kill dead or run away processes that 3.1 was.... so I
 was able to do a safe shutdown and reboot.
 RS>> OTOH, a C++ compiler will interpret int foo() as meaning int
 RS>> foo(void).  It states that the syntax int foo() is obsolete under
 RS>> C++.
 JC> The first of these is correct.  The second not so at all.  In
 JC> fact, I'd consider the syntax `int foo(void)' as obsolescent under
 JC> C++, with `int foo()' the preferred syntax.  IIRC, function
 JC> declarations in C were deprecated in the last standard, meaning
 JC> they may dissappear at some point, and `int foo()' will mean the
 JC> same thing in C as it presently does in C++.
 Hmmm... well the book is discussing making code compile with
 both C and C++ compilers which might be why they said to write
 it that way.
 If there is one thing that is often publicized about C++ it is
 the way the standard has been so long time coming.  I also read
 often about writers who had just sent their new C++ book off for
 printing when the committee sat down made many changes.
 JC> obsolescent.  If you're writing true C++, I would reccommend using
 JC> empty parens to indicate that the function takes no parameters.
 JC> I'd use "void" between the parens if you're writing code that you
 JC> want to work as either C or C++. Later, Jerry.
 Ok Jerry, sounds like good advice to me.... (like I would know
 the difference.  hehehe).
 Roger Scudder
 rogers@gim.net
... 'If it ain't broke, you can probably still fix it.' - Tim Allen
--- Terminate 5.00/Pro 
 * TerMail/QWK * Terminate = Pointmailer+Tosser+Reader+Packer+QWK!
--- WILDMAIL!/WC v4.12 
---------------