c++0x enum class inheritance / extension

[Frank Bergemann]

Hi,

does the c++0x 'enum class' support state/value extension by
inheritance?
I.e. can i have a base enum class, which can be extended (also
overidden?) by inheritance?

- thanks!

rgds,
Frank

 

[Alf P. Steinbach]

* Frank Bergemann:

does the c++0x 'enum class' support state/value extension by
inheritance?
I.e. can i have a base enum class, which can be extended (also
overidden?) by inheritance?

If it does (I haven't checked but I very much doubt it), and if that kind of
inheritance works approximately like class inheritance, then that would be a
defect in the draft standard.

For with an enum, an extension is not a sub-type, it is a super-type, which
means that inheritance "goes the wrong way".

For example, if F is an extension of enum type E, and you have a routine that
expects an E and relies (e.g. in a 'switch') on knowing all possible values of
E, then if you could pass an F, that is if F worked type-wise as a sub-type,
then you would break the routine's assumption of knowing all possible values.

This is not to say enum inheritance can't be made to work.

But the rules for type compatibility are topsy-turvy and counter-intuitive,
almost like member pointers versus ordinary pointers.


Cheers & hth.,

- Alf

 

[Saeed Amrollahi]

Hi,

does the c++0x 'enum class' support state/value extension by
inheritance?
I.e. can i have a base enum class, which can be extended (also
overidden?) by inheritance?

- thanks!

rgds,
Frank

Hi Frank

I don't think so. The new enumeration or strong enumeration was added
to C++
for three reasons:
1. to avoid implicit enum to int
2. to surrond enumerators in a scope
3. using other fundamental types for underlying type as int
May be you can implement such mechanism indirectly.

Regards,
-- Saeed Amrollahi

 

[Frank Bergemann]

For with an enum, an extension is not a sub-type, it is a super-type, which
means that inheritance "goes the wrong way".

For example, if F is an extension of enum type E, and you have a routine that
expects an E and relies (e.g. in a 'switch') on knowing all possible values of
E, then if you could pass an F, that is if F worked type-wise as a sub-type,
then you would break the routine's assumption of knowing all possible values.

This is not to say enum inheritance can't be made to work.

But the rules for type compatibility are topsy-turvy and counter-intuitive,
almost like member pointers versus ordinary pointers.

you're right - there is no equivalent to slicing the F extensions for
E
and to still have a valid E object.
Interesting - but it sounds like 'enum class' itself is already a kind
of 'black sheep'
- if it doesn't support what we expect from a class.
At least the naming is a bit sloppy.

Actually for me it started with:
there should be a way to support enum extensions.
I hoped, anum class will do so :-(

rgds,
Frank

 

[Frank Bergemann]

For example, if F is an extension of enum type E, and you have a routine that
expects an E and relies (e.g. in a 'switch') on knowing all possible values of
E, then if you could pass an F, that is if F worked type-wise as a sub-type,
then you would break the routine's assumption of knowing all possible values.

This is not to say enum inheritance can't be made to work.

But the rules for type compatibility are topsy-turvy and counter-intuitive,
almost like member pointers versus ordinary pointers.

thinking once more about it:
How about requiring, that a enum class, which is intended/defined to
be extended MUST have a dedicated DEFAULT in it's enumerations - as a
surrogate for the extensions of deriving classes.
(I mean other classes, which are intended to be used as base classes
are also required to "prepare" for this - e.g. to provide a virtual
destructor.)

Then base enum class evaluation could use
case DEFAULT:
or just
default:
For this.

And it could be defined, that using a ptr or reference to base enum
class will be "converted" to DEFAULT for enum values/states of sub-
classes, which are extended by sub-classes, but are NOT included in
the definition of the base enum class itself.

That sounds consistent for me.

rgds,
Frank

 

[James Kanze]

On 3 Jul., 11:43, "Alf P. Steinbach" <[email protected]> wrote:

[...]

Interesting - but it sounds like 'enum class' itself is
already a kind of 'black sheep'
- if it doesn't support what we expect from a class.

That's because it has nothing to do with a class. It's an enum
which doesn't pollute the surrounding namespace.

At least the naming is a bit sloppy.

The "naming" is just a question of adopting a syntax which
doesn't require a new keyword.

Actually for me it started with:
there should be a way to support enum extensions. I hoped,
anum class will do so :-(

That's not what it's there for.