Why Is form1.h Bigger Than the .cpp File That Includes It

[walter clark]

The .h file traditionally holds declarations and the .cpp file the definitions. The #include inserts the human readable ASCII code that is the .h file, right there at the top before compiling. The main purpose of the .h file was to gather together all the declarations (more even than you need) rather than listing all that are needed at the top of every .cpp file. (This also eliminates the need to go around changing every declaration every time you make a change.)
But in the case of Windows Programming (using Visual C++ Express) why is all the code in the form1.h and the .cpp file that includes it is just a stub?

[athlon32]

The .h file traditionally holds declarations and the .cpp file the definitions. The #include inserts the human readable ASCII code that is the .h file, right there at the top before compiling. The main purpose of the .h file was to gather together all the declarations (more even than you need) rather than listing all that are needed at the top of every .cpp file. (This also eliminates the need to go around changing every declaration every time you make a change.)

That Much is true :)

But in the case of Windows Programming (using Visual C++ Express) why is all the code in the form1.h and the .cpp file that includes it is just a stub?

I don't understand, why don't you post Form1.h???

[walter clark]

I'm talking about generated code in Visual C++. The calling .cpp file is just a few lines long. The header it calls (the Form1.h file) has over a hundred lines and then when you put your own calls to your own functions (in their own .cpp files) it makes the Form1.h file even bigger.

[athlon32]

Sorry, I don't use VC++, i prefer Code::Blocks; but I'm guessing that Form1.h has a bunch of extra declarations that are defined in separate .CPP files that you mustn't get to see, maybe, or maybe not

[walter clark]

That's a simple answer, but I think it's the right one, Mr. Athlon32.
We are accustomed to seeing "our" .h files just having a few declarations with the functions that include them full of source code elsewhere. But as you pointed out, the generated declarations refer to thousands of lines of .cpp code we don't see. The stub that includes the Forms1.h file probably calls the Windows operating system; large enough task that having it's own file isn't a waste. Even if we put hundreds of lines of function definitions in the Form1.h file, that is still small stuff compared to what is behind what is generated there. Still we should limit the logic we put in the Form1.h and for sure move all function definitions out to .cpp files.

[Ancient Dragon]

I just created a new Windows Forms project, and Form1.h is 66 lines, including blank lines. There is no Form1.cpp file, but there is a <project name>.cpp that contains main() with a few lines of startup code.

[walter clark]

And I think the startup code file won't get any bigger, whereas the .h file it includes, will get larger and larger as you develop your program. It seems like the tail wagging the dog, but when you consider what that <projectName>.cpp file does, it makes sense. It must call Windows for your program.

[siddhant3s]

" .h files are smaller than .cpp " is a convention and a strong convention.
There are many well established libraries which do not follow this convention. One of the infamous example is Boosts; they have header-only libraries. (well, mostly)

[walter clark]

Siddhant, AncientDragon, Athlon...
Thank you all for this discussion. I think I can mark it as solved. The answer is, traditionally the .h files we write are usually smaller than the .cpp that includes them but they don't have to be. It does bring up the question, "How much coding do we do inside the Forms1.h file that the wizard creates for us?" I think the answer is only as much as operates all the user interface stuff. When it finally gets down to doing the purpose of the program it should be with code written in .cpp files.
Walt