Re: Inheritance Issue
Dave Harris wrote:
two@haik.us (Al) wrote (abridged):
Now, I dislike downcasts and avoid them as much as possible. So another
approach is to change the classes to something like:
class Base { public: boost::optional<int> Field; };
class Derived : public Base { ... };
That way, I can do the slightly cleaner:
void foo(Base* base) {
if (base->Field)
std::cout << *base->Field;
}
I realize that this doesn't really fix the problem, but the syntax is a
little nicer :). Anyway, between these two, which seems better? Are
there other approaches?
I generally prefer the downcast. You have the invariant that the field is
only present if the class is a Derived, and putting the field into Derived
expressed that simply and directly. It avoids cluttering Base with
something which only belongs in Derived.
As Victor Bazarov mentions, another approach is to give Base an extra
virtual function instead of an extra instance variable. In my view that's
only slightly better because Base is still cluttered with a feature that
only makes sense for Derived. (But it's better to clutter with virtual
functions than with variables.)
In either case, it would seem wierd to me for the base class to
contain something that has no meaning for some instances. From
a logical point of view, the derived class here is offering an
extended interface, i.e. more functionality. It thus seems
logical for the user to start by asking for that functionality,
if he wants to use it: in C++, the generic way to do this is
dynamic_cast.
In some cases, it may make sense for the Base class to know that
some derived classes may provide a specific functionality,
others not. In such cases, one can define a separate interface
for the additional functionality, and add a virtual function to
the base to return this interface; the default implementation in
the base returns a null pointer, and derived classes
implementing the additional interface return a pointer to it.
And there are cases where it is logical to imagine a value which
may or may not be present in instances. The original poster
mentioned lex/yacc in a follow-up. My own Token class does
recognize the fact that individual token types have values, of
varying types; it requires all value types to derive from a
"labeling" base class, and handles a pointer to the value in the
base class, e.g.:
class Token
{
public:
class Value : public Gabi::UncopiableObject
{
public:
virtual ~Value() {} ;
} ;
Token() ;
Token( TokenId const& id,
std::string const& spelling,
Value* value = NULL )
;
TokenId const& id() const ;
std::string const& spelling() const ;
template< typename T >
T* value() const ;
private:
TokenId myId ;
std::string mySpelling ;
Value* myValue ;
} ;
template< typename T >
T*
Token::value() const
{
return dynamic_cast< T* >( myValue ) ;
}
The type of the value, and whether it is present, is determined
by the id; the value itself is accessed with something like:
currentToken.value< IntConst >()
This probably isn't a good solution generally, but it does seem
appropriate in the case of a parser.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]