switch statement to detect handling of ALL derived classes

[Hicham Mouline]

Imagine we have an abstract base class ABC and derived classes D1, D2, ...
Dn

I am being told a code pattern to "enforce" all cases are handled is such:


enum ABCTypes { D1Tag, D2Tag, .... DnTag };

const ABC& base

ABCTypes t = base.getTag();
swich(t)
{
case D1Tag:
...
case DnTag:
}

without the default branch.


If you add a Dnplus1 derived class and its tag Dnplus1Tag in the enum
ABCTypes ,
all code patterns with the switch-case will generate an error if you forget
to handle the Dnplus1 case.

1) Does the standard "require" handling all cases of the enum? Or does it
only say a conforming implementation should print a warning?
2) Are there opinions on this style? I don't like the use of the getTag()
method in the ABC class to facilitate this style.

3) Is there a way to use boost::mpl and/or boost:reprocessor to generate
the switch-case statement?

rds,

 

[Ian Collins]

Imagine we have an abstract base class ABC and derived classes D1, D2, ...
Dn

I am being told a code pattern to "enforce" all cases are handled is such:


enum ABCTypes { D1Tag, D2Tag, .... DnTag };

const ABC& base

ABCTypes t = base.getTag();
swich(t)
{
case D1Tag:
...
case DnTag:
}

without the default branch.


If you add a Dnplus1 derived class and its tag Dnplus1Tag in the enum
ABCTypes ,
all code patterns with the switch-case will generate an error if you forget
to handle the Dnplus1 case.
Eh?

1) Does the standard "require" handling all cases of the enum? Or does it
only say a conforming implementation should print a warning?
Neither.

2) Are there opinions on this style? I don't like the use of the getTag()
method in the ABC class to facilitate this style.

It's horrible, why not just use virtual functions?

 

[Hicham Mouline]

Neither.

g++ prints a warning when not all enum values are handled in the switch
case.
That is a choice made but that implementation then.

It's horrible, why not just use virtual functions?

I also don't like it.... But I need to show an alternative.The processing done in the switch case is not inherently related to the ABC.
I'd rather not put that processing in a member virtual function of ABC, but
rather some external function that takes ABC
In that function, I could use

if (dynamic_cast<D1*>( base ))
///
if (dynamic_cast<D2*>( base ))
///
....
if (dynamic_cast<Dn*>( base ))
///
but with this, I can't even get a warning if I am missing Dnplus.

Is there a different way of using the virtuality without writing member
virtual functions?

rds,

 

[Alf P. Steinbach]

* Hicham Mouline:

I could use

if (dynamic_cast<D1*>( base ))
///
if (dynamic_cast<D2*>( base ))
///
...
if (dynamic_cast<Dn*>( base ))
///
but with this, I can't even get a warning if I am missing Dnplus.

Is there a different way of using the virtuality without writing member
virtual functions?

Instead of dynamic cast just use a virtual member routine, and call that.


Cheers & hth.,

- Alf

 

[Ian Collins]

g++ prints a warning when not all enum values are handled in the switch
case.
That is a choice made but that implementation then.

I also don't like it.... But I need to show an alternative.
Why?

The processing done in the switch case is not inherently related to the ABC.
I'd rather not put that processing in a member virtual function of ABC, but
rather some external function that takes ABC
In that function, I could use

if (dynamic_cast<D1*>( base ))
///
if (dynamic_cast<D2*>( base ))
///
....
if (dynamic_cast<Dn*>( base ))
///
but with this, I can't even get a warning if I am missing Dnplus.

That's even worse.

Is there a different way of using the virtuality without writing member
virtual functions?

What's wrong with

struct ABC {
virtual void doSomething() = 0;
};

struct D1 : ABC {
void doSomething() { // does something }
};

....

base.doSomething();

All derived classes must provide doSomething(), so no case can be left
out by mistake.

 

[Hicham Mouline]

* Hicham Mouline:

Instead of dynamic cast just use a virtual member routine, and call that.


Cheers & hth.,

- Alf

that's what I don't want to use. a "member" virtual function.

 

[Hicham Mouline]

That's even worse.


What's wrong with

struct ABC {
virtual void doSomething() = 0;
};

struct D1 : ABC {
void doSomething() { // does something }
};

...

base.doSomething();

All derived classes must provide doSomething(), so no case can be left out
by mistake.

Because doSomething is not immediately relevant to ABC.
It's 3rd party code using my hierarchy that I provide for them.

 

[Ian Collins]

that's what I don't want to use. a "member" virtual function.

Why? That's what they are for.

 

[Hicham Mouline]

Are you in search of something like the visitor pattern by any chance?

http://en.wikipedia.org/wiki/Visitor_pattern

Stu

That's what it looks like. It is non intrusive.
Thanks

 

[James Kanze]

g++ prints a warning when not all enum values are handled in
the switch case.

It doesn't when I use it. You can (and should) turn such stupid
warnings off; it's quite frequent to use a switch to catch just
a couple of the cases (which have special treatment).

That is a choice made but that implementation then.

Yep. Most implementations have one or two really stupid
warnings.

I also don't like it.... But I need to show an alternative.

Virtual functions, like Ian said.

The processing done in the switch case is not inherently
related to the ABC. I'd rather not put that processing in a
member virtual function of ABC, but rather some external
function that takes ABC In that function, I could use

Check out the visitor pattern. Or if worse comes to worse, a
map of type_info to functional objects. (The visitor pattern
does require some support in the hierarchy, but it is a very
generic support, with no real processing.)

if (dynamic_cast<D1*>( base ))
///
if (dynamic_cast<D2*>( base ))
///
...
if (dynamic_cast<Dn*>( base ))
///
but with this, I can't even get a warning if I am missing
Dnplus.

Is there a different way of using the virtuality without
writing member virtual functions?

Without any member virtual functions, you'll have to implement
the virtuality yourself, using std::map. But the virtual
functions necessary for the visitor pattern are quite trivial.
And you'll get a compile time error if you fail to handle one of
the derived classes. (Using std::map, you won't get an error
until runtime.)

 

[Hicham Mouline]

A feature is designed for the language and later we have someone say,
"I dont want to use this feature, how do I emulate it? "

They then discover that the emulation has drawbacks (switch statement
missing a case label). That drawback was the raison d'etre for virtual
functions.

Stephen Howe

I don't have a choice. The classes cannot be changed. 3rd party.

 

[Tim Hockin]

"Stephen Howe" <sjhoweATdialDOTpipexDOTcom> wrote in message

>that's what I don't want to use.   a "member" virtual function.




I don't have a choice. The classes cannot be changed. 3rd party.

You only have a base-class pointer, and you want to operate on the
derived class. Yep. dynamic_cast or enum. You've got to manage it
manually. Keep a table of function pointers and jump into it based on
the enum?