Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > .h and .cpp

Reply
Thread Tools

.h and .cpp

 
 
Christopher
Guest
Posts: n/a
 
      11-28-2011
If you were on a team of developers that had little C++ experience,
how would you go about explaining the reasoning as to why the
following rules should be followed? (Or why they shouldn't)

1) Class defintions go in their own .h (or .hpp for templates) file
named after the class
1a) Every class should have its own .h (or .hpp for templates) file
1b) A .h file should never contain class implementation (except for
inline functions or methods)

2) Class implementations go in their own .cpp file (except for
templates)
2a) A .cpp should never contain a class definition

3) One should not define multiple classes in a single .h file
3a) Nested class defintions should be avoided without good reason
(what's good reason?)

6) Variables should never be defined in a .h file
7) Globals should not be defined in a .h file
Every .cpp file should compile into a .obj file without error or
warning on its own.
i.e In Visual Studio, you should be able to right click a .cpp in
the source tree and choose compile, without error or warning in the
output.
----

Sadly, I find myself having to justify these things. (of course
someone might point out I am wrong or exceptions to the above), but
these are things that I've always had drilled into my head throughout
the years and have rarely come acorss other developers that didn't do
the same. I am finding it frustrating to work on a project where 30
classes defintions reside in the .h same .h file, a single .cpp file,
or worse a precompiled header. There is discussion, but I have to
explain reasoning.

So far, I've come up with the testability argument:
When unit testing one frequently wants to test a single class. A proxy
class may need to be created to test its protected or privare methods.
Proxies may have to be created for its input and outputs. I should be
able to include a single .h file, link in the appropriate .obj files
and compile a unit test without the added clutter of satisfying
includes or linkage needed by unrelated classes.

I don't know what else to say aside from, "just do it, its the thing
to do." and noone is going to buy that.




 
Reply With Quote
 
 
 
 
ralph
Guest
Posts: n/a
 
      11-28-2011
On Mon, 28 Nov 2011 09:20:13 -0800 (PST), Christopher
<(E-Mail Removed)> wrote:

>If you were on a team of developers that had little C++ experience,
>how would you go about explaining the reasoning as to why the
>following rules should be followed? (Or why they shouldn't)
>
>1) Class defintions go in their own .h (or .hpp for templates) file
>named after the class
>1a) Every class should have its own .h (or .hpp for templates) file
>1b) A .h file should never contain class implementation (except for
>inline functions or methods)
>
>2) Class implementations go in their own .cpp file (except for
>templates)
>2a) A .cpp should never contain a class definition
>
>3) One should not define multiple classes in a single .h file
>3a) Nested class defintions should be avoided without good reason
>(what's good reason?)
>
>6) Variables should never be defined in a .h file
>7) Globals should not be defined in a .h file
> Every .cpp file should compile into a .obj file without error or
>warning on its own.
> i.e In Visual Studio, you should be able to right click a .cpp in
>the source tree and choose compile, without error or warning in the
>output.
>----
>
>Sadly, I find myself having to justify these things. (of course
>someone might point out I am wrong or exceptions to the above), but
>these are things that I've always had drilled into my head throughout
>the years and have rarely come acorss other developers that didn't do
>the same. I am finding it frustrating to work on a project where 30
>classes defintions reside in the .h same .h file, a single .cpp file,
>or worse a precompiled header. There is discussion, but I have to
>explain reasoning.
>
>So far, I've come up with the testability argument:
>When unit testing one frequently wants to test a single class. A proxy
>class may need to be created to test its protected or privare methods.
>Proxies may have to be created for its input and outputs. I should be
>able to include a single .h file, link in the appropriate .obj files
>and compile a unit test without the added clutter of satisfying
>includes or linkage needed by unrelated classes.
>
>I don't know what else to say aside from, "just do it, its the thing
>to do." and noone is going to buy that.
>


Sounds like a group out-of-control.

Sadly you either have the authority to enforce coding standards, or
you do not. If you do then "just do it, its the thing to do" OR *its
your job* is the only reliable answer. Otherwise, live with it chewing
away as opportunities present themselves, or seek other employment.

Number 8 above
" Every .cpp file should compile into a .obj file without error
or warning on its own"
can be corrected with daily builds and penalties for "breaking the
build".

-ralph
 
Reply With Quote
 
 
 
 
Christopher
Guest
Posts: n/a
 
      11-28-2011
> It seems irrational to me to have classes in .h and templates in .hpp;
> either use .h for all C++ code; .hpp for all C++ code.
>
> It seems popular to use .hpp for C++ code and .h for C code these days.
>
> /Leigh


That would be fine with me.
I am looking for some explanation I can give though for why not to put
a class definition in a .cpp file. What would you say?

 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      11-28-2011
On 28.11.2011 18:20, Christopher wrote:
> If you were on a team of developers that had little C++ experience,
> how would you go about explaining the reasoning as to why the
> following rules should be followed? (Or why they shouldn't)
>
> 1) Class defintions go in their own .h (or .hpp for templates) file
> named after the class
> 1a) Every class should have its own .h (or .hpp for templates) file


Instead of such mechanical rules, have a rule about clarity and possibly
about testability.

Two or more classes may be strongly coupled and belong in the same header.

Many classes are just implementation details and do not deserve their
own headers.


> 1b) A .h file should never contain class implementation (except for
> inline functions or methods)


The "except" makes this rule self-contradictory.

Perhaps the author intended to write a rule about always making sure
that a function definition in a header file is `inline`, whether
explicitly or implicitly by being defined in a class definition.



> 2) Class implementations go in their own .cpp file (except for
> templates)


That might help to reduce build times for a complex system.

But note that "complex" is an euphemism for "spaghetti".

Better, IMO, to instead avoid the spaghetti.


> 2a) A .cpp should never contain a class definition


That's incredibly restricting.

For example, it would preclude the ordinary PIMPL idiom, or else force
an extra header file for that.


> 3) One should not define multiple classes in a single .h file
> 3a) Nested class defintions should be avoided without good reason
> (what's good reason?)


These two rules contradict each other.


> 6) Variables should never be defined in a .h file


That's idiotic, it precludes defining constants.


> 7) Globals should not be defined in a .h file


It's a good idea to avoid global variables in general.

But this connection with .h files is meaningless.


> Every .cpp file should compile into a .obj file without error or
> warning on its own.


Good idea, and I do agree, although many people disagree.

Those who disagree find it more work to structure the code so as to get
rid of warnings, than to merely ignore the warnings, and they argue that
it is futile to try to shut up future compiler versions.

For example, building the Boost library produces a lot of warnings.


> i.e In Visual Studio, you should be able to right click a .cpp in
> the source tree and choose compile, without error or warning in the
> output.


Yes, I think that's a good ideal.

Also, with any compiler, remember to enable a higher warning level than
default, but not so extreme as to be impractical.

For example, with Visual C++ use at least /W4, and with g++ use at least
-Wall


> ----
>
> Sadly, I find myself having to justify these things. (of course
> someone might point out I am wrong or exceptions to the above), but
> these are things that I've always had drilled into my head throughout
> the years and have rarely come acorss other developers that didn't do
> the same.


Oh, you've been unfortunate.


> I am finding it frustrating to work on a project where 30
> classes defintions reside in the .h same .h file, a single .cpp file,
> or worse a precompiled header.


Yes, that's bad, but I think not solvable by mechanical rules that are
just as bad (in the other direction).


> There is discussion, but I have to
> explain reasoning.
>
> So far, I've come up with the testability argument:
> When unit testing one frequently wants to test a single class. A proxy
> class may need to be created to test its protected or privare methods.
> Proxies may have to be created for its input and outputs. I should be
> able to include a single .h file, link in the appropriate .obj files
> and compile a unit test without the added clutter of satisfying
> includes or linkage needed by unrelated classes.
>
> I don't know what else to say aside from, "just do it, its the thing
> to do." and noone is going to buy that.


Cheers & hth.,

- Alf
 
Reply With Quote
 
Christopher
Guest
Posts: n/a
 
      11-28-2011
> Sounds like a group out-of-control.
>
> Sadly you either have the authority to enforce coding standards, or
> you do not. If you do then "just do it, its the thing to do" OR *its
> your job* is the only reliable answer. Otherwise, live with it chewing
> away as opportunities present themselves, or seek other employment.


I am beginning to think that might be the case, but if the boss says
"I beleive you, you just have to give some reasoning aside from I said
so." Then I wanted to at least try before joining the "I am looking
for employment" group again.

> Number 8 above
> " Every .cpp file should compile into a .obj file without error
> *or warning on its own"
> can be corrected with daily builds and penalties for "breaking the
> build".


Not really, because the build in its entirety brings in other .cpp
and .h files as well as precompiled headers, in which things were
defined in the wrong places, but the compiler remains happy. It just
ends up being a fragile build that breaks often, because standards
weren't followed. When compiling just one .cpp by itself, everything
has to be defined and correct.

 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      11-28-2011
On Nov 28, 6:20*pm, Christopher <(E-Mail Removed)> wrote:
> If you were on a team of developers that had little C++ experience,
> how would you go about explaining the reasoning as to why the
> following rules should be followed? (Or why they shouldn't)
>
> 1) Class defintions go in their own .h (or .hpp for templates) file
> named after the class


Don't know about hpp for templates. It's *.h or *.hpp for everything
if you ask me. If there is only one class ion the file, or if it's
clearly the "main" class in it, then class_name.h is only natural.

> 1a) Every class should have its own .h (or .hpp for templates) file


Not so sure about that. All sorts of auxiliary artifacts can just as
well be tagged along their principal stuff.

> 1b) A .h file should never contain class implementation (except for
> inline functions or methods)


Purely mechanically, this doesn't work due to C compilation model: if
the class parts are defined in a header, and said header is included
in more than one translation unit (source file), linker will encounter
duplicate symbols.

> 2) Class implementations go in their own .cpp file (except for
> templates)


Same as above

> 2a) A .cpp should never contain a class definition


Disagreed. There's classes that will only be used in one translation
unit. What can one gain by making another trivial header?

> 3) One should not define multiple classes in a single .h file
> 3a) Nested class defintions should be avoided without good reason
> (what's good reason?)


Good reason: nested class is used exclusively in context of the
nesting class, possibly as a helper.

Private nested classes should be avoided. They are better off in
implementation file, as not to create additional compile-time
dependency where there's no logical one.

> 6) Variables should never be defined in a .h file


Same as for classes - duplicate symbols galore. Exception: literal
constants. If these are not constants, there should ideally be 0 of
those in any given codebase.

> 7) Globals should not be defined in a .h file


I am not sure to understand the difference between a variable and a
global?

> Every .cpp file should compile into a .obj file without error or
> warning on its own.
> * * *i.e In Visual Studio, you should be able to right click a .cppin
> the source tree and choose compile, without error or warning in the
> output.


Except for precompiler header, which one should be using to save
compilation time. IOW, if precompiled header is used and compiled,
then any translation unit should compile.

Otherwise, if you can't compile without errors, you can't compile, end
of, so that's a given. As for warnings... When compiler emits a
warning, it does it for a reason. Coder isn't smarter than compiler as
far as formal verification goes. If there's a warning, coder should
first try to change the code so that compiler has no reason for
nagging. That usually ends in a better design. Casting or other
compiler-gagging come distant second as idea.

> Sadly, I find myself having to justify these things.


Sadly is a good word. What, do directory entries cost these people
money?

> (of course
> someone might point out I am wrong or exceptions to the above), but
> these are things that I've always had drilled into my head throughout
> the years and have rarely come acorss other developers that didn't do
> the same. I am finding it frustrating to work on a project where 30
> classes defintions reside in the .h same .h file, a single .cpp file,
> or worse a precompiled header. There is discussion, but I have to
> explain reasoning.


Ugh. That's a clear-cut sign that someone doesn't know how to work
with C compilation model.

Goran.
 
Reply With Quote
 
Tobias Müller
Guest
Posts: n/a
 
      11-28-2011
Christopher <(E-Mail Removed)> wrote:
>> It seems irrational to me to have classes in .h and templates in .hpp;
>> either use .h for all C++ code; .hpp for all C++ code.
>>
>> It seems popular to use .hpp for C++ code and .h for C code these days.
>>
>> /Leigh

>
> That would be fine with me.
> I am looking for some explanation I can give though for why not to put
> a class definition in a .cpp file. What would you say?


Generally, you don't #include .cpp files (this is what .h files are made
for), so a class defined in a cpp file is really only visible in that
single file.

Normally you want a class to be reusable in other files, but there are rare
cases where it makes sense to have a class that is "private" to some .cpp
file and you don't want it to be used by others.

Tobi
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      11-28-2011
On 28.11.2011 20:03, Leigh Johnston wrote:
> On 28/11/2011 18:45, Alf P. Steinbach wrote:
>> On 28.11.2011 18:20, Christopher wrote:
>>
>>> 6) Variables should never be defined in a .h file

>>
>> That's idiotic, it precludes defining constants.

>
> Traditionally constants are called constants not variables.


You got a point.

I was associating too strongly to formal terminology.


Cheers, & thanks,

- Alf


 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      11-28-2011
Christopher wrote:

> If you were on a team of developers that had little C++ experience,
> how would you go about explaining the reasoning as to why the
> following rules should be followed? (Or why they shouldn't)
>
> 1) Class defintions go in their own .h (or .hpp for templates) file
> named after the class
> 1a) Every class should have its own .h (or .hpp for templates) file
> 1b) A .h file should never contain class implementation (except for
> inline functions or methods)
>
> 2) Class implementations go in their own .cpp file (except for
> templates)
> 2a) A .cpp should never contain a class definition
>
> 3) One should not define multiple classes in a single .h file
> 3a) Nested class defintions should be avoided without good reason
> (what's good reason?)
>
> 6) Variables should never be defined in a .h file
> 7) Globals should not be defined in a .h file
> Every .cpp file should compile into a .obj file without error or
> warning on its own.
> i.e In Visual Studio, you should be able to right click a .cpp in
> the source tree and choose compile, without error or warning in the
> output.
> ----
>
> Sadly, I find myself having to justify these things. (of course
> someone might point out I am wrong or exceptions to the above), but
> these are things that I've always had drilled into my head throughout
> the years and have rarely come acorss other developers that didn't do
> the same. I am finding it frustrating to work on a project where 30
> classes defintions reside in the .h same .h file, a single .cpp file,
> or worse a precompiled header. There is discussion, but I have to
> explain reasoning.


Separating declarations from implementations and mandating that each class
should be defined and implemented in separate source files are a couple of
practices which help track what changes were made to each individual
component and who made those changes. With this, auditing the code becomes
a bit simpler.

This practice also reduces the amount of potential merging conflicts any
commit might induce.


Rui Maciel
 
Reply With Quote
 
Geoff
Guest
Posts: n/a
 
      11-28-2011
I disagree with your rule 6. It precludes #define.

Also, rule number 6: there is no rule 6!
(Obligatory Monty Python reference.)

For some very interesting coding standards referenced by no less
authority than Stroustrup himself:

http://www2.research.att.com/~bs/JSF-AV-rules.pdf

via his page:
http://www2.research.att.com/~bs/C++.html
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
if and and vs if and,and titi VHDL 4 03-11-2007 05:23 AM



Advertisments