On Apr 2, 9:19 am, j...@pusspaws.net wrote:
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.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
