Archived

This topic is now archived and is closed to further replies.

3dmodelerguy

classes question

Recommended Posts

Guest Anonymous Poster
Other? What was/were the other(s) then?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
hmm...
If you mean is there any benefit from putting the class declarations in .h files and implementations to .cpp files then, yes. Here are two coming to my mind first:
- It''s cleaner (and, after all, the way it''s generally done)
- Reduces compiling time considerably (implementations are compiled once only)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I don''t know. I''ve never tried C# but I''d guess it has a different class-importing system (couldn''t find any more suitable word now). In C++, when you #include the headers to cpp files, the headers are just copied to them and then compiled. If you have the implementations in headers they''ll get compiled too -- every time you compile the cpp file. In C# there might be some sort of import statement (?) or some other system which doesn''t include the implementations to every source file...

Man, this post is a mess...

Share this post


Link to post
Share on other sites
You should, however, weigh the increased compile times against the maintenance times involved in keeping header and implementation files separate.

Share this post


Link to post
Share on other sites
If you use VC++ as an IDE, you can hop straight to the method in like 2 clicks anyway.

Another use of keeping them separate is that you can distribute the headrers with a compiled lib, then you''re not giving your source code away.

Share this post


Link to post
Share on other sites
Rubbish.

There is no benefit in the header/implementation file dichotomy. It is simply a limitation of C and C++''s outdated compilation mechanisms. It could be resolved with a multi-pass compilation and the definition of a per-platform ABI, but the Standards Committee won''t do that, citing the overwhelming volume of existing code that would either be broken or need to be rebuilt.

One day, those limitations will catch up to the languages and (finally) remove them from first contention.

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
Rubbish.

There is no benefit in the header/implementation file dichotomy.


On the contrary, there is a HUGE benefit to doing this. Not least because if you keep implementation out of the header file, it''s SO much easier to see at a glance what a class does by looking at its interface. If I want to know what a class does, I don''t want to scan down the header file 100s of line and try to pick out the member functions, I want to glance at the interface and see how to use it.

Share this post


Link to post
Share on other sites
quote:
Original post by gowron67
quote:
Original post by Oluseyi
Rubbish.

There is no benefit in the header/implementation file dichotomy.


On the contrary, there is a HUGE benefit to doing this. Not least because if you keep implementation out of the header file, it''s SO much easier to see at a glance what a class does by looking at its interface. If I want to know what a class does, I don''t want to scan down the header file 100s of line and try to pick out the member functions, I want to glance at the interface and see how to use it.


Well, usually a decent IDE would solve this problem by providing a list of all functions in the module that is currently being read.

Having two separate files for each class is a hassle I admit. Typing each member function twice (I usually do copy and paste, by I still need to add the ClassName:: ) and adding new functions are just two examples. However, I also dislike having the interface and implementation in one file (Java/C# style) and mainly due to the same reason that you just stated. Second, it gives me the impression that this class is "huge."

There must be reasons why the Standard Committee won''t do that.

Share this post


Link to post
Share on other sites
quote:
Original post by gowron67
On the contrary, there is a HUGE benefit to doing this... If I want to know what a class does, I don''t want to scan down the header file 100s of line and try to pick out the member functions, I want to glance at the interface and see how to use it.
Ever heard of Javadoc?

To expound, the source code is not the sole source of information/documentation about the code. Intelligent use of tools can cause developer information to be automatically generated from the code. Javadoc is inadequate because it is dependent on the developer creating metacode, but extracting interface definitions from a source file is trivial. The class browser could be written such that it regenerates a text or html file if the source file is newer than the documentation file.

This isn''t 1973.

quote:
Original post by alnite
There must be reasons why the Standard Committee won''t do that.
It''s called "legacy," and in the case of C++, it''s a 30-year old one.

Share this post


Link to post
Share on other sites