Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > deriving a class - extending enum

Reply
Thread Tools

deriving a class - extending enum

 
 
Christopher
Guest
Posts: n/a
 
      12-05-2007
I have run into this dilemma enough to ask about it now.

Say I have a base class:

class BaseClass
{
public:
enum BaseClassEnumType
{
firstEnum,
secondEnum,
num_enumtypes
}
....
BaseClassEnumType m_something;
};

Down the road I make a derived class:

class DerivedClass : public BaseClass
{
....
};

I also have some routine(s) somewhere:

void Foo(BaseClass * ptr)
{
if( ptr->m_something == BaseClass::secondEnum)
{
// do something
}
...
}

Now the situation arises, when I make my derived class, where I want
to "extend" the enumerations in the base class. In this example, I
want to add the value "thirdEnum". In the Real World, perhaps I need
to add more error codes specific to derived class in an error type
enumeration that was part of the base class, or something similar. How
do you accomplish that whether it be through redesign or some existing
concept I am not familiar with?

Of course, the thought of breaking the enumeration out of BaseClass
occured to me, but it has the same result: Every time you need a new
value in the enumeration, you have to edit preexisting code that
"lives" in the BaseClass, in order to accomplish something that is
specific to the derived class. This is especially problematic to me
when the BaseClass and the enumeration are part of a separate library.

This must be a common problem. Any thoughts?

 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      12-05-2007
* Christopher:
> I have run into this dilemma enough to ask about it now.
>
> Say I have a base class:
>
> class BaseClass
> {
> public:
> enum BaseClassEnumType
> {
> firstEnum,
> secondEnum,
> num_enumtypes
> }
> ...
> BaseClassEnumType m_something;
> };
>
> Down the road I make a derived class:
>
> class DerivedClass : public BaseClass
> {
> ...
> };
>
> I also have some routine(s) somewhere:
>
> void Foo(BaseClass * ptr)
> {
> if( ptr->m_something == BaseClass::secondEnum)
> {
> // do something
> }
> ...
> }
>
> Now the situation arises, when I make my derived class, where I want
> to "extend" the enumerations in the base class. In this example, I
> want to add the value "thirdEnum". In the Real World, perhaps I need
> to add more error codes specific to derived class in an error type
> enumeration that was part of the base class, or something similar. How
> do you accomplish that whether it be through redesign or some existing
> concept I am not familiar with?


Represent errors as a hierarchy of class types.

Use exceptions instead of error codes.

Don't use enums.


Cheers, & hth.,

- Alf

--
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?
 
Reply With Quote
 
 
 
 
werasm
Guest
Posts: n/a
 
      12-05-2007
On Dec 5, 10:39 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:


> Don't use enums.


Never?

Werner
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      12-05-2007
werasm wrote:
> On Dec 5, 10:39 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
>
>
>> Don't use enums.

>
> Never?


Of course never.


 
Reply With Quote
 
werasm
Guest
Posts: n/a
 
      12-05-2007
On Dec 5, 10:53 pm, "Victor Bazarov" <(E-Mail Removed)> wrote:
> werasm wrote:
> > On Dec 5, 10:39 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:

>
> >> Don't use enums.

>
> > Never?

>
> Of course never.


Well, care to give some reasons and alternatives?

W
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      12-05-2007
werasm wrote:
> On Dec 5, 10:53 pm, "Victor Bazarov" <(E-Mail Removed)> wrote:
>> werasm wrote:
>>> On Dec 5, 10:39 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:

>>
>>>> Don't use enums.

>>
>>> Never?

>>
>> Of course never.

>
> Well, care to give some reasons and alternatives?


Read Alf's response. I totally agree with him on his suggestions.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


 
Reply With Quote
 
werasm
Guest
Posts: n/a
 
      12-05-2007
On Dec 5, 10:59 pm, "Victor Bazarov" <(E-Mail Removed)> wrote:
> werasm wrote:
> > On Dec 5, 10:53 pm, "Victor Bazarov" <(E-Mail Removed)> wrote:
> >> werasm wrote:
> >>> On Dec 5, 10:39 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:

>
> >>>> Don't use enums.

>
> >>> Never?

>
> >> Of course never.

>
> > Well, care to give some reasons and alternatives?

>
> Read Alf's response. I totally agree with him on his suggestions.


I've read his response, hence my question (Never, or never for
the particular problem). The question still remains.

Regards,

Werner
 
Reply With Quote
 
Andrey Tarasevich
Guest
Posts: n/a
 
      12-05-2007
werasm wrote:
> On Dec 5, 10:39 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
>> Don't use enums.

>
> Never?
> ...


Forget it. _DO_ use enums. The hierarchy of exception classes is a good
idea, but _not_ as a replacement for enum constants as exception codes.
An attempt to introduce a separate exception class for every concrete
exception type will only lead to a disaster. In the exception hierarchy
the classes themselves are supposed to serve for a rough division of
various exception types into relatively large groups or..., well...
"classes" of exceptions. The concrete exception type within the class is
still best described with a enum constant.

Your original idea of "extending" the enum in the derived class can be
easily implemented as follows

class BaseException {
public:
enum Type {
firstEnum,
secondEnum,
next_enum_,
};

int m_something;
...
};

class DerivedException : public BaseException {
typedef BaseException BASE;
public:
enum Type {
oneMoreEnum = BASE::next_enum_,
yetMoreEnum,
stillMoreEnum,
next_enum_
};
...
};

class DerivedDerivedException : public DerivedException {
typedef DerivedException BASE;
public:
enum Type {
oneAdditionalEnum = BASE::next_enum_,
anotherAdditionalEnum,
moreAdditionalEnum,
next_enum_
};
...
};

// And so on...

Note how the 'next_enum_' name is used in the above example and how
(together with the 'BASE' typedef) it makes all derived exception
classes to have uniform definitions.

Of course, in this case you are not really "extending" the base enum
type, but rather create another enum type with sequence of constants
that continue the inherited sequence. Of course, each enum is a separate
type, but that shouldn't worry you at all: simply disregard the enum
types entirely and use an 'int' value to describe the concrete exception
instead.

--
Best regards,
Andrey Tarasevich
 
Reply With Quote
 
Howard
Guest
Posts: n/a
 
      12-05-2007

"Andrey Tarasevich" <(E-Mail Removed)> wrote in message
news:fj79bk$tsu$(E-Mail Removed)...
> werasm wrote:
>> On Dec 5, 10:39 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
>>> Don't use enums.

>>
>> Never?
>> ...

>
> Forget it. _DO_ use enums. The hierarchy of exception classes is a good
> idea, but _not_ as a replacement for enum constants as exception codes.
> An attempt to introduce a separate exception class for every concrete
> exception type will only lead to a disaster. In the exception hierarchy
> the classes themselves are supposed to serve for a rough division of
> various exception types into relatively large groups or..., well...
> "classes" of exceptions. The concrete exception type within the class is
> still best described with a enum constant.
>
> Your original idea of "extending" the enum in the derived class can be
> easily implemented as follows
>
> class BaseException {
> public:
> enum Type {
> firstEnum,
> secondEnum,
> next_enum_,
> };
>
> int m_something;
> ...
> };
>
> class DerivedException : public BaseException {
> typedef BaseException BASE;
> public:
> enum Type {
> oneMoreEnum = BASE::next_enum_,
> yetMoreEnum,
> stillMoreEnum,
> next_enum_
> };
> ...
> };
>
> class DerivedDerivedException : public DerivedException {
> typedef DerivedException BASE;
> public:
> enum Type {
> oneAdditionalEnum = BASE::next_enum_,
> anotherAdditionalEnum,
> moreAdditionalEnum,
> next_enum_
> };
> ...
> };
>
> // And so on...
>


There's a potential problem with that: what if at some level of the
hierarchy, you have two or more derived classes, such as DerivedException1
and DerivedException2, both derived from BaseException? Then you'll have
multiple enum values with the same integer value. Of course, that may not
be any problem at all... it depends how you use the enums, I guess.
-Howard


 
Reply With Quote
 
Andrey Tarasevich
Guest
Posts: n/a
 
      12-05-2007
Howard wrote:
> ...
> There's a potential problem with that: what if at some level of the
> hierarchy, you have two or more derived classes, such as DerivedException1
> and DerivedException2, both derived from BaseException? Then you'll have
> multiple enum values with the same integer value. Of course, that may not
> be any problem at all... it depends how you use the enums, I guess.
> ...


The idea is that the concrete exception is supposed to be fully
identified by the pair "class type+enum code", not by enum code alone.
In the scenario you describe the identical enum values would belong to
completely different "classes" (or "scopes") of exceptions. As such,
they are not supposed to cause any conflicts.

--
Best regards,
Andrey Tarasevich
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"enum" vs. "enum class" Ansel C++ 16 08-27-2012 10:34 AM
extending enum Roedy Green Java 18 06-25-2011 01:16 PM
Difference between enum class and enum struct Brian C++ 4 02-27-2010 04:03 PM
deriving a class from a base class markww C++ 1 08-22-2006 11:55 AM
Deriving abstract class from non-abstract class Matthias Kaeppler Java 1 05-22-2005 01:28 PM



Advertisments