Archived

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

Agape

Constructors...in the header or cpp file?

Recommended Posts

quote:
Original post by Agape
What''s the difference between defining the implementation of a constructor in a header or cpp file?




Readability and consistancy.

Share this post


Link to post
Share on other sites
quote:
Original post by Agape
What''s the difference between defining the implementation of a constructor in a header or cpp file?




What''s the difference between defining the implementation of ANY function in a header or cpp file?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
if defined inside class => unreadable
outside class but in .h => link errors (with more than one .cpp refering to the class which often occurs)
in .cpp => readable, no recompilation, no errors.. perfect

Share this post


Link to post
Share on other sites
If the method is only a return statment, I define the method inline i.e. in the .h file:

float getSpeed() const { return _fSpeed; }

That's the only time it simpifies code reading, I think.

[edited by - Enselic on October 14, 2003 10:09:11 AM]

Share this post


Link to post
Share on other sites
Putting the implementation in the header file creates unnecessary dependencies between classes. Keep the header file limited to interface, and put the implementation in the .cpp file. Do a Google search on "pimpl idiom" for a preferred way to do this.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

Share this post


Link to post
Share on other sites
quote:
Original post by dmikesell
Putting the implementation in the header file creates unnecessary dependencies between classes. Keep the header file limited to interface, and put the implementation in the .cpp file. Do a Google search on "pimpl idiom" for a preferred way to do this.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

Even in my case? In what way does it become unnucessary dependencies?

Share this post


Link to post
Share on other sites
quote:
Original post by Enselic
quote:
Original post by dmikesell
Putting the implementation in the header file creates unnecessary dependencies between classes. Keep the header file limited to interface, and put the implementation in the .cpp file. Do a Google search on "pimpl idiom" for a preferred way to do this.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

Even in my case? In what way does it become unnucessary dependencies?



I''m assuming it has to do with the fact that it''s no longer just a class declaration, but contains actual code now. So, now that it actually contains sources, it is created extra dependancies for each file that includes it.

Share this post


Link to post
Share on other sites
I second dmikesell on this: Read the pImpl idiom to learn a pleasant way to reduce inter-class dependencies.

It''s really hard to -explain- how bad header dependencies can become in a big project, unless you''ve actually lived in one (like me). But let''s just say that as the project progresses, compile times explode when class coupling and dependencies aren''t kept to a minimum. And it makes modifications of existing code harder too.
That last part is true even if it''s just because the header is less readable!


If you don''t understand how useful it is -now- and in your case. I invite you to adopt this way of working regardless (and get used to it) just because it is ''good practice''. And in the future when you -do- happen on a situation when it saves on compile time / modifs ease, you''ll smile and tell yourself you learnt the right way -before- the problem hit you on the head.

My two cents

=^.^= Leaders and teachers should remember: It is best to offer others what they Need, not what they Want.

Share this post


Link to post
Share on other sites
quote:
quote:
--------------------------------------------------------------------------------
Original post by dmikesell
Putting the implementation in the header file creates unnecessary dependencies between classes. Keep the header file limited to interface, and put the implementation in the .cpp file. Do a Google search on "pimpl idiom" for a preferred way to do this.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com
--------------------------------------------------------------------------------


Even in my case? In what way does it become unnucessary dependencies?


For one, if your constructor changes, then every file that includes that header must recompile. Furthermore, if your constructor implementation requires including other header files, then all files that include your header depend on them as well.

If it''s just a one line constructor that won''t change, maybe not a big deal. By the way, Lakos'' book /Large Scale C++ Software Design/ touches on this and other issues. Good book.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

Share this post


Link to post
Share on other sites
Thanks for the help guys. Dumb question, but can I still implement constructors in the cpp file as such:


Virus(Company c): Attack(c), attackType("VIRUS"), attackClass(0) {};




edit:: "Virus" is derived from "Attack"...which is why I wanted to use this notation.


[edited by - agape on October 14, 2003 8:22:57 PM]

Share this post


Link to post
Share on other sites
quote:
Thanks for the help guys. Dumb question, but can I still implement constructors in the cpp file as such:


Virus(Company c): Attack(c), attackType("VIRUS"), attackClass(0) {};



Absolutely, but you need to specify the class name and you don't need the semi-colon after the {}:

Virus::Virus(Company c): Attack(c), attackType("VIRUS"), attackClass(0) {}


--
Dave Mikesell Software & Consulting

[edited by - dmikesell on October 15, 2003 8:11:58 AM]

Share this post


Link to post
Share on other sites
Another question: If I''m creating a base class that all other classes inherit from but isn''t actually used, is it more efficient to just define all the functions in that header file? For example, an Object class that lets all derived classes have linked list functionality.

Share this post


Link to post
Share on other sites
quote:
Another question: If I''m creating a base class that all other classes inherit from but isn''t actually used, is it more efficient to just define all the functions in that header file? For example, an Object class that lets all derived classes have linked list functionality.


Is there a good reason for having an Object class? I''ve used Java and find all of the type casting to be a real pain and a killer to type-safety. Check out what the C++ FAQs have to say about inheritance:

http://www.parashift.com/c++-faq-lite/proper-inheritance.html

--
Dave Mikesell Software & Consulting

Share this post


Link to post
Share on other sites
To answer Agape:

It is never more efficient to put code in a header file, but it always causes more hassle to keep code updated, and lengthens compile times.
So the bottom line might be to ''never'' put code in a header file, but there are two overriding reasons (that I know of):

Reason 1: Templated classes.
Template classes can''t be coded in a .cpp, all their code goes in a header file. It is unavoidable so more care must be put on making templates ''solid''.

Reason 2: Wanting inlined code for a performance reason.
If you''ve profiled your code and determine that a certain call needs to be called faster. You can put the code in the header and define it inline. Don''t do this without profiling first and determining that it is needed! Early optimization tends to cause problems.


Your full question is about a base ''object'' class common to all. My full answer is that no, it isn''t more efficient to put code in the header. No gain in performance, but more coupling will make compiles longer and alterations more difficult.
Also, keep in mind that using polymorphism has a cost: Every time you use a member function of an inherited object, there will be an extra table lookup to find which member function should really be called.
That table lookup doesn''t happen on a plain object, so there''s good things to be said about neat non-inherited objects placed in managers/containers.

Share this post


Link to post
Share on other sites