i've always had a wierd thought about prototypes, do you really need
them? in my case, i think it looks neater having them.
The reason they are required (and yes, they are) is that C++ is
designed to be both strong typed and possible to parse somewhat easily
in one pass. I'll explain what these mean.
Suppose you have the following code:
int main()
{
f(17);
}
void f(int t)
{ }
When the compiler reads the f(17); line, it still hasn't heard of this
function. To it, it doesn't exist. Because of this, it can't make sure
that
-f is a function [functor, class, other callable object], and
-that f takes an integer [long, double, other type with an implicit
conversion from an integer] as the first argument and no more (except
defaults).
Whereas in this (or where the definition of f comes before main):
void f(int t);
int main()
{
f(17);
}
void f(int t)
{ }
the compiler sees the prototype, adds f to a list of known functions,
and then when it reaches the call of f it can compare the 17 with the
arguments f takes and say "ah ha, good call".
Hence in the first version of the code code the compiler cannot
strongly type the code which violates our [Bjarne's] design
principles. Hence we either need to find a way to solve the problem or
disallow the use of functions before their declaration.
There are two ways to solve this. First, we can keep a list of all
function calls that we've seen throughout the code then compare them
to the function when we run across it. However, this soon becomes more
complicated than it first appears, especially as you get big programs
with lots of calls, then realize that it should also make sense to be
able to instance objects of classes/structs that are yet to be
defined, and global variables, and all sorts of stuff. (Actually, I'm
not entirely sure that these are all prohibited, but work with be
here...) This will complicate compilers quite a bit and very likely
slow down compilation noticably. Hence this is undesirable as it
arguably violates the second design principle.
The other option is to read through the file, get a list of all the
functions, then read through again. For an example, in the first
version of the code above the compiler would read through, see there's
a function f(int), add it to its table, then go through and actually
compile. This would work, but it too violates the second condition,
this time outright, by requiring the second pass.
Because of these, Bjarne Stroustrup decided to require declarations of
functions and stuff before their use.
(I'll anticipate a question that may be asked and answer it now. It
has to do with class methods and why the above is illegal while this:
class someClass {
public:
void f()
{ g(); }
void g()
{ }
};
is not, despite it appearing that g is used before it is defined. The
reason is that the body of functions inlined in the class declaration
are parsed as if they are implemented directly after the class, as in
the following:
class someClass {
public:
void f();
void g();
};
inline void someClass::f()
{ g(); }
inline void someClass::g()
{ }
Hence g() is essentially declared before it is used in the definition
of f. This was not done so that the above example is legal though, it
was done to solve this problem:
int i; // Global variable
class someClass {
public:
void f() { i=6; }
private
int i;
};
Which int is referred to by the function f? By the one-pass rule, it
seems it should be the global i. But intuition says it should refer to
someClass::i, especially when you consider that a simple reordering of
the class members, as in
int i; // Global variable
class someClass {
private
int i;
public:
void f() { i=6; }
};
would change the meaning of the i in f() without so much as a whisper
from the compiler, and would thus probably change the working of the
entire program. Moving the definition of functions outside the body:
int i; // Global variable
class someClass {
public:
void f();
private
int i;
};
inline void someClass::f()
{ i=6; }
makes it unamiguous.
See Strostrup's The Design and Evolution of C++, specifically p.
138-139 (at least in my copy), for details.
Yes, I know this is a lot more than you probably anticipated in
response, but I have a habit of going overboard like this and besides,
it's interesting.)
