It seems the "correct" accepted way of defining a class in C++ is to create the class definition, member vars and function prototypes in a .h file and do all of the member function implimentations in a seperate .cpp file. Why is this? I haven''t been able to get a coherent answer out of my programming teacher... Why can''t you just define the whole class and all it''s functions in one class{ } structure and keep the whole thing in one file? I''ve heard this helps inline the functions, and would make adding classes to a project that much easier, but the general consensus is that doing that isn''t proper practice and will piss off other programmers who want to use your code. Why?

If you''ve got classes which implementation get''s somewhat large (5000+ lines), it''s much easier to read a declaration of it which just defines the methods and vars than having to go through 5000 lines of code to find the actual declarations.

Also, the philosphy of "encapsulation" says that the user of the class (i.e. the person reading the class header) shouldn''t have to worry about the implementation. Really, you want to hide your implementation. Putting it right with the declaration is the opposite of this.

quote: Original post by Stoffel

Also, the philosphy of "encapsulation" says that the user of the class (i.e. the person reading the class header) shouldn''t have to worry about the implementation. Really, you want to hide your implementation. Putting it right with the declaration is the opposite of this.

But what if you separated the implementation from the declaration in some way??? Couldn''t you then add them to the same file?

BeS
It's Da BOMB Baby!!!

And also it will make compiling a lot faster, if you have lot''s of large classes (1st compile generates .obj for each of the classes, then other compiles only have to recompile the .obj for classes that get changed)

You know, I never wanted to be a programmer...

Alexandre Moura

I could be wrong here, but maybe someone else could validate me on this:

If you put the class definition and implementation all in one file, then when that file gets included in another module, a copy of this entire class exists again in the final executable (that is, the module you include gets placed with the .obj you''re currently making, then they all get linked?)

If this were true, and all your classes had full implementation in one file, then the resulting executable would be disastrously large (though in some cases, faster to execute).

By only placing the definitions in the header file, you don''t have to worry about the implementations creating a larger file, but you still have access to the implementations.

Could someone else back this up, or correct me if I''m wrong? this is as far as I understand it, but I mainly do the seperation amongst .h and .cpp files for the sake of readability.


Monday is an awful way to spend one seventh of your life.

re: multiple definitions & declarations

Yes, it happens that way, but that's why we almost always put:
#ifndef __MYFILE_H__
#define __MYFILE_H__

...h file here...
#endif

Which is basically the same as #pragma once

Let me put the whole idea of separating the implementation another way:
Let's say you're in the business of making a 3D engine. You have a bunch of classes for your engine. You make a library out of your engine (.LIB and/or .DLL files), and now you want to sell it. What do you want to give to your customer? The header files that have the entire implementation in them? Then they'd steal your code and write their own engine.

No, you give them the .LIB and .DLL files and the .H files so they can talk to your classes. But the only thing your .H files have are the definitions of the classes and LOTS of documentation.

Make more sense now?

Alex is also correct. If you only have one .H file, or one .CPP file that is small and all of the code in .H files, you'll have to recompile everything every time you make a small change. It takes several minutes to do a full recompile on our programs here, so a lot of effort goes into slicing up code components into .CPP files and NON-INTERDEPENDENT .H files. So if I change one .CPP file, there a small recompile & re-link. If I change one .H file, hopefully only a couple of .CPP files are dependent on it. This is why you want to move away from the "single .H file included by every .CPP file" paradigm.

Edited by - Stoffel on August 1, 2000 6:29:35 PM

Putting them all in the file won''t help compile time. In fact it will be slower. Other classes don''t need to see implementation of class functions\data, they only need to see declarations, which are in the header file. Also file splittinbg will make a really big project half-manageable. If you have a class with 70 functions, you don''t want to have to scroll past ten kinds of crap just to see one thing. I would have at least a header and a source file for every class.
I am however still perplexed as to why your lecturer never explained all this to you!

Lucas

"Computers in the future may weigh no more than 1.5 tons."

--Popular Mechanics, forecasting the relentless march of
science, 1949

Think situation where u have lib files and headers(Clanlib) you check header for functionc declaration and use it in your program
imagine when headers have all the stuff in larger programs it gonna be big mess. Check out Article of writing effective C++ it was very good and says inline should be used there where you really need speed.BTW Inline function may make your exe very big.

quote: Original post by Stoffel

re: multiple definitions & declarations

Yes, it happens that way, but that''s why we almost always put:
#ifndef __MYFILE_H__
#define __MYFILE_H__

...h file here...
#endif

Which is basically the same as #pragma once

Let me put the whole idea of separating the implementation another way:
Let''s say you''re in the business of making a 3D engine. You have a bunch of classes for your engine. You make a library out of your engine (.LIB and/or .DLL files), and now you want to sell it. What do you want to give to your customer? The header files that have the entire implementation in them? Then they''d steal your code and write their own engine.

No, you give them the .LIB and .DLL files and the .H files so they can talk to your classes. But the only thing your .H files have are the definitions of the classes and LOTS of documentation.

Make more sense now?

Alex is also correct. If you only have one .H file, or one .CPP file that is small and all of the code in .H files, you''ll have to recompile everything every time you make a small change. It takes several minutes to do a full recompile on our programs here, so a lot of effort goes into slicing up code components into .CPP files and NON-INTERDEPENDENT .H files. So if I change one .CPP file, there a small recompile & re-link. If I change one .H file, hopefully only a couple of .CPP files are dependent on it. This is why you want to move away from the "single .H file included by every .CPP file" paradigm.

Edited by - Stoffel on August 1, 2000 6:29:35 PM

Thanks, at least for me this makes the most sense as a reasoning for it. I have only started C/C++ stuff and have noticed that this is a good way of writing. Similar to the way BeOS has it done. You can read through their .h files for all of the implementations for every Class in the OS. IT''s pretty neat actually. I think I''m learning quite a bit about the structure of implementations from just from reading their stuff.



BeS
It's Da BOMB Baby!!!