In article
<63240327-8865-42c8-a705-31805eced...@u7g2000yqm.googlegroups.com>,
Paul N <gw7...@aol.com> wrote:
I'm using inheritance - this particular case is to provide a linked
list of attributes of a piece of text (text colour, italic etc) so
that different parts of it can be shown in different ways.
class Attrib : public Listable {
public:
// stuff including where in the text the attribute starts to take
effect
};
class Col_Attrib : public Attrib {
public:
COLORREF col;
// plus more stuff
};
class Ink : public Col_Attrib {
public:
// stuff
};
class Paper : public Col_Attrib {
public:
// stuff
};
Now, if I include a constructor:
Col_Attrib::Col_Attrib(COLORREF incol) : col(incol) { }
then this doesn't, by itself, create constructors for Ink and Paper
taking a COLORREF, does it?
No, it doesn't.
If I did want such constructors, would it be best to include a
constructor as above and then do:
Ink::Ink(COLORREF incol) : Col_Attrib(incol) { }
or would it be better to do:
Ink::Ink(COLORREF incol) : col(incol) { }
directly? The first form seems more natural in terms of the hierarchy,
but the second seems more efficient.
The former. The latter won't compile. (yes, full stop.)
Maybe if you included all the optional stuff that happens automatically
in the code, things might make more sense to you:
Ink::Ink(COLORREF incol)
: Col_Attrib()
, col(incol)
{ }
The above doesn't work. You are trying to initialize 'col' but it was
already initialized in the Col_Attrib() constructor. The Col_Attrib()
constructor call happens, even if you don't include the code.
So you have to:
Col_Attrib::Col_Attrib(COLORREF incol)
: Attrib()
, col(incol)
{ }
Ink::Ink(COLORREF incol)
: Col_Attrib(incol)
{ }
Hope that helps.
Thanks. Yes, it does help. I was getting confused between actual