Re: ,h * .cpp + dependent class query
* jk@pusspaws.net:
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
<string>. An extreme case is the PIMPL idiom -- look it up.
(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.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?