,h * .cpp + dependent class query

[jk]

Newbe Question ...

I have read "C++ the complete reference" by Herbert Schildt and
understood (most) of it but have a couple of queries.

(1) In real world applications the code is split into .h and .cpp
files not all just one file. The .h files having the class definitions
and prototypes and the .cpp having the methods. OK so when i #include
a file in my program I am including the headers or .h file. Why is
there this split - why not just have one file and include that ?

(2) In real world programs I have found the following construct in
class constructors to set a value to a variable:

in .h file ...

class test {
....
private:
int mHighestMenuId;
}

in .cpp file ...

test::test( )
:mHighestMenuId(6)
{
....

ie using the dependent classes initialise values section of the
constructor to initialise the variable to 6. Why do it this way ? Is
there any advantage over just
setting mHighestMenuId = 6; in the constructor ?

Dave

 

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

(2) In real world programs I have found the following construct in
class constructors to set a value to a variable:

in .h file ...

class test {
...
private:
int mHighestMenuId;

}

in .cpp file ...

test::test( )
:mHighestMenuId(6)
{
...

ie using the dependent classes initialise values section of the
constructor to initialise the variable to 6. Why do it this way ? Is
there any advantage over just
setting mHighestMenuId = 6; in the constructor ?

I'll refer to the FAQ on this one: http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.6

 

[Alf P. Steinbach]

* (e-mail address removed):

Newbe Question ...

I have read "C++ the complete reference" by Herbert Schildt and
understood (most) of it but have a couple of queries.

First you should do a Google search on Herbert Schildt.

(1) In real world applications the code is split into .h and .cpp
files not all just one file. The .h files having the class definitions
and prototypes and the .cpp having the methods. OK so when i #include
a file in my program I am including the headers or .h file. Why is
there this split - why not just have one file and include that ?

Mainly for two reasons.

First, the split allows separate compilation, which means reduced build
times when only the implementation has been changed.

Second, it allows a better logical structure where implementation
dependencies are hidden down in the [.cpp] file and does not affect
client code. E.g. if the implementation uses <string>, but the
interface does not, then the client code is not forced to include

(2) In real world programs I have found the following construct in
class constructors to set a value to a variable:

in .h file ...

class test {
...
private:
int mHighestMenuId;
}

in .cpp file ...

test::test( )
:mHighestMenuId(6)
{
...

ie using the dependent classes initialise values section of the
constructor to initialise the variable to 6. Why do it this way ? Is
there any advantage over just
setting mHighestMenuId = 6; in the constructor ?

For an 'int' it doesn't matter. For a type that is a class with no
default constructor you couldn't do it any other way. There are also
efficiency arguments and those are discussed in the FAQ.

 

[jk]

Thanks for both your replies - that makes sense

Dave

 

[red floyd]

* (e-mail address removed):

First you should do a Google search on Herbert Schildt.

I second Alf's comment. I am an inveterate bookworm. I am
psychologically incapable of throwing away a book. Nevertheless, *EVERY
SINGLE COPY* of the abomination mentioned by the OP should be burned.
And the ashes blessed and sprinkled with holy water. And scattered.
Preferably by being launched into the Sun.

 

[James Kanze]

I have read "C++ the complete reference" by Herbert Schildt and
understood (most) of it but have a couple of queries.

As others have already pointed out, Herbert Schildt is not
considered a reliable reference.

(1) In real world applications the code is split into .h and .cpp
files not all just one file.

This varies enormously. First, of course, the naming
conventions vary, and generally, .h is only used for headers
which are shared between C and C++; a pure C++ header will be
..hpp (or .hh, or in older times, .H or .hxx). In the Unix
world, at least .cc and .hh are at least as frequent as .cpp and
..hpp. And of course, the compiler doesn't care. (Up to a
point, at least; I'm not sure what would happen if you tried to
compile a file toto.exe, e.g.: cl /Tptoto.exe with VC++. OK,
just tried it. It worked like I expected: it compiled the file
as C++ code, and put the generated executable in a file
called... toto.exe. Overwriting the source.) Practically
speaking, of course, it's better to stick with .cpp/.hpp or
..cc/.hh.

Secondly, the breakdown varies. Many of the Boost components
contain only templates, and only use a .hpp file, for example,
whereas more classical libraries classes might have a .cpp per
member function. There's no one absolute rule.

The .h files having the class definitions
and prototypes and the .cpp having the methods. OK so when i #include
a file in my program I am including the headers or .h file. Why is
there this split - why not just have one file and include that ?

Because in a typical production environment, the two files are
written and maintained by two different people (with different
responsibilities). Because you don't want the smallest change
in the implementation of a member function to trigger the
recompilation of all of the user code.

(2) In real world programs I have found the following construct in
class constructors to set a value to a variable:

in .h file ...

class test {
...
private:
int mHighestMenuId;

}

in .cpp file ...

test::test( )
:mHighestMenuId(6)
{
...

ie using the dependent classes initialise values section of the
constructor to initialise the variable to 6. Why do it this way ? Is
there any advantage over just
setting mHighestMenuId = 6; in the constructor ?

There's never any moment when the variable is accessible but not
initialized. If you work with C++ programmers any amount of
time, you'll find that they don't like uninitialized variables.
For good reasons.

It's also a good habit to get into, since sometimes, it's the
only way you can initialize them. Try declaring mHighestMenuId
const, for example. Or using a reference.