RS> I have read so much about how one should use prototypes in C++ due to
 RS> strong type checking that somewhere along the way I must have assumed 
 RS> it was required. ( Please bear with me... I'm still learning C++... )  

I use, or, rather, "don't" use prototypes in both C and C++, both
without sacraficing the strongest type checking allowed by the languages.

 RS> I'm sure prototypes are required in a program that uses strict top down 
 RS> design. 

Hmmm - perhaps I'm somewhat confused.  I don't associate 'design' with
'layout'.  :-)  I can "write" at the bottom of my source modules
and "move up" rather than continuing to move down all the time.

 RS> I don't want to get into C++ here, but when you say you use prototypes
 RS> when the function is a a part of a class... by part of I assume you me
 RS> a member of...  isn't it correct to declare a class in the .h file and
 RS> in doing that all member functions are always declared in the .h file?

Not completely correct, no.  Most of the time, yes, but not always.  Often
I need (or want) a class in a certain module, but don't need it elsewhere. 
I would then put it in that source module, not in the header.  This goes
even further along the idea of 'information hiding' - it hides the very
fact that OO technology is being used to do the work!  This allows the
source to be considered a larger black box than if the objects were made
visible via a header file.

 RS> Then any functions that are not implemented inline are implemented in
 RS> the .cpp file?  So from your statement above, you only use prototypes
 RS> when you must due to language requirements?  I think that is a mistake.

Right.  I must use a prototype when:

1. Some other module requires one of my functions (put the prototype in the
header file).
2. One of my own module's functions is recursive with another one, i.e.,
a() calls b() and b() calls a() - no way to put the function before its
call (put the prototype at the top of the source module, after all other
#include's).

Otherwise, I find it to be a waste of effort.  Given the following snippet of code:

/* includes: */
#include 
#include "2.h"
/* ... */

/* prototypes: */
int a(void);
char* b(char*, long);
double c(long, long, double);

/* functions:
int a(void)
{ /* ... */ }

char* b(char* y, long z)
{ /* ... */ }

double c(long x, long y, double z)
{ /* ... */ }

static void d(int (*)(void))
{ /* ... */ }


Now, assuming each function is relatively long (two, three screens)... do
the prototypes help you, the programmer, out?  No - you thought that a, b,
and c were in this source module, but missed d.  (In fact, in the current
version, d can't be called...)

I don't give any misleading clues.  :-)  I find that massively prototyping
at the top is as bad as kitchen-sink comments.  The code gets updated...
the comments (prototypes) don't.

 RS> That is ok for small programs with a small number of modules.  In larger
 RS> programs placing prototypes in the source files only makes things more
 RS> difficult for the next programmer who has to modify the program.  It's

No - I don't put EXTERNAL prototypes in the source module - only prototypes
of functions IN that module!

I completely agree - if a() is in a.c, and used in b.c, a.h should
prototype a(), and b.c should #include "a.h".  However, if a() is
only used in a.c, and a() must be defined after its use in that module,
then it only needs to be prototyped in that module.  This helps keep the
namespace from being polluted with unnecessary functions.

Anyway, as you point out, this is a minor stylistic issue, and not critical
to your program's maintainability.  I just wanted to point out that it
isn't necessary to do it your way (or whoever started this thread
).


---