Function Prototypes

Hi, I'm trying to learn how to program and I'm reviewing section 4 of the "c++ made easy" tutorial, and I gotta ask a question I've been curious about for a while, what's the point of defining a function's prototype without defining what the function actually does? Just something I've been wondering about...

Due to the linear mentality of the C++ compiler, each function call requires a lookup of all functions defined up to this point; if that function is not found, an error is thrown. The compiler doesn't care about what the function does, it just wants to make sure you've called it correctly.

Consider:

Code:

---

#include <iostream>

int main()
{
  output();
  return 0;
}

void output()
{
  std::cout << "C++ is too linear for me." << std::endl;
}

---

The compiler runs - though sometimes seemingly saunters - through the code, notices output() and proceeds to perform a lookup of the "output" function. Alas, this function has not been defined at this point (it is defined later!) so the compiler must throw an error; metaphorically, it refuses to use a power-drill when it hasn't been taught how to operate it, and it arguably doesn't need to know how it works, just how to use it.

But you're probably thinking, well, that's stupid. The function's right there, why can't it just search the entire file for it?

Consider if, hypothetically, it did search the file for it. It works great in simple scenarios such as these, but what happens when your function is in a separate file in a separate library amongst a forest of files numbering in the thousands? A quick scan here is an oxymoron. Now we have to resort to some form of a cached function list which we have to keep up-to-date constantly with every build of our app. And what if there's a function in a dll or lib that we don't have direct access to? Now we're just plain hosed.

And so function prototypes are born.

Uhh... Wha?

I'm not too experienced with C++ (and I'm tired), but if I'm understanding you correctly, what you're saying is that you can put your function definitions anywhere as long as all your prototypes are at the top of your code... Right? :confused:

Quote:

---

Originally Posted by Kryota

Uhh... Wha?

I'm not too experienced with C++ (and I'm tired), but if I'm understanding you correctly, what you're saying is that you can put your function definitions anywhere as long as all your prototypes are at the top of your code... Right? :confused:

---

That is correct, as long as the function definition is outside of main(). The main purpose of prototypes is to put the function definition at the bottom, and never have to look at it again once it's done. Saves time to prevent scrolling through functions if there are a lot of them.

It's like to reading a book, if a character is referenced in chapter one that isn't introduced until chapter 25, you're not going to know anything about them. This is why characters are introduced before they're actually used.

Think of a function prototype as an introduction for the compiler.

So what the compiler kind of does is create a .exe file from the main function, and the dll files are sort of the binary equivalents of your other functions, and the .exe reads these dll whenever it needs the code. When the compiler compiles your code it uses prototypes or exact definitions to determine if you're correctly calling the functions, but doesn't care about what they do, the compiler just converts them into dll files which are later read by your program, the linking step, correct? This is just an interpretive guess, but I'm getting that light-bulb-above-your-head feeling, so meh :D

Well, in your case you won't be working directly with dlls for a while, so replace dlls with object files in your model and you're kind of correct :p. There are essentially three phases to your program: compilation, linking, and execution.

Compilation spits out object files.
Linking links the object files into an exe.
Execution, well, it runs your code.

Quote:

---

Originally Posted by jverkoey

Well, replace dlls with object files in your model and you're kind of correct :p.

---

Augh, ignorance is NOT bliss, it's just plain annoying... Is that a technical detail I can ignore for now? :D

You may wish to reread my last post, I have a bad habit of editing posts.

But yes, they're all technical details that you really don't need to know at this point but are nice to know regardless.

Oh wait, I think I understand what you mean by object files, they're binary instructions, not necessarily exact binary conversions of every character in the functions.

Anyways, thanks for helping me, this has cleared up alot of things for me, I really appreciate it :D

*tips hat* You're welcome.

Quote:

---

Originally Posted by Kryota

Oh wait, I think I understand what you mean by object files, they're binary instructions, not necessarily exact binary conversions of every character in the functions.

---

To add to that explanation, there these are the three steps:
Compilation
Linking
Execution

Compilation is the first step when the compiler runs. The compiler parses your code, catches your mistakes, optimizes your code and translates all this for the next step.
The linking steps assembles your program into its final shape, an exe or a dll or whatever you want it to be. Then the code is run in the execution step.

If you're curious, the compiler only looks for the prototypes and as long as they exist, it doesn't care about anything else... even if your function doesn't actually exist.
This is where the linker complains. The linker scans your file for "symbols" as they're called - for names, for functions, for variables and all that stuff in your file so the program can reference to them correctly. So if no function is found with a name (translation: you have a prototype but haven't defined the function), you get a linking error!
Now those are really nasty...