This is supposed to compile?

Looking through someone else's source today, I saw something that I previously thought was not possible: a source file without a main function. So I fiddled about with the outline, and it turns out that it does compile.

Here's a header "main.h"

Code:

int run(int argc, char **argv);

int main(int argc, char **argv){
    return run(argc, argv);
}

And here's the source

Code:

#include <iostream>
#include "main.h"

int run(int argc, char **argv){
  std::cout << "Wow! This works?" << std::endl;
  return 0;
}

This is a severely stripped down version of the full project (some 400 header and source files, about 300000 lines of code).

In any case, I'd always assumed that an executable source file had to have a main routine. But it turns out it's not. So what's the general advantage of doing something like this? Would it make a large project more manageable? Or is it just showing off/syntactic sugar?

The code, as you've given it, is required to compile and build; the main function (what you're calling the "main routine") is defined in your header file. Keep in mind that the #include directive does straight text substitution: the content of the file is effectively substituted in place of the #include directive.

You will potentially have no end of problems should main.h be #include'd by more than one source file within your project, as you'll run afoul of the "one definition rule" -- main() will be defined once for each source file main.h is #include'd into. If that happens, in practice, the most common symptom is complaints from linkers about multiply defined functions.

The technique of main() calling another function that does all the hard work is sometimes used to get around the fact that the C++ standard disallows calling main() recursively. The run() function, however, can call itself recursively.

Putting the implementation of main() into a header file is often considered rather poor style, but it's not technically disallowed unless (as I said above) the one definition rule is violated.

it doesn't matter where the main function is defined, it's still there
technically, what include does is it replaces the #include line with the code in the file it includes

so what you have here would be

Code:

#include <iostream>
int run(int argc, char **argv);

int main(int argc, char **argv){
    return run(argc, argv);
}

int run(int argc, char **argv){
  std::cout << "Wow! This works?" << std::endl;
  return 0;
}

[edit] got beaten to it... ur explanation makes my post look bad... =(

That header file is perverse, because it has a function definition in it -- the definition of main(). I can't even count how many levels at which that's wrong. It happens to work presumably because it is only included from a single source file. If it were included anywhere else in the same project, there would be a symbol redefinition error.

As for having a source file without a main() function -- not the case here, but you asked -- that's actually the norm. Most large programs are split into many smaller source modules. Only ONE of those modules will have the main() function in it.

Thanks. It was just so perverse that I couldn't come to my senses for a while. Anyway, a make target isn't even defined for the "main.h" header in the make file, so linker troubles are all precluded. Glad to know it wasn't just me who thinks it's unorthodox.

Anyway, a make target isn't even defined for the "main.h" header in the make file, so linker troubles are all precluded.

No, they aren't. They're just postponed, until the moment you write a second .cpp file that includes main.h.