Enum "Inheritance"?

Nick Sabalausky a at a.a
Sat Feb 26 19:20:42 PST 2011


"Nick Sabalausky" <a at a.a> wrote in message 
news:ikcepj$248p$1 at digitalmars.com...
>
> I think your main original problem was that there isn't really a way to 
> compose enums additively, only subtractive.
>

That just gave me an idea: I think you should be able to get away with an 
ordinary union:

enum STD {
    STD_ELEMENT_1 = 17,
    STD_ELEMENT_2 = 42,
}

enum AOnly {
    A_ACCESS_1 = 0x80,
}

enum BOnly {
    B_ACCESS_1 = 0x80,
}

union A {
    STD std;
    A a;
}

union B {
    STD std;
    B b;
}

void funcA(A a) {
    if(a.a == A_ACCESS_1) {}
    if(a.std == STD_ELEMENT_1) {}
}

void funcB(B b) {
    if(b.b == B_ACCESS_1) {}
    if(b.std == STD_ELEMENT_1) {}
}

In the general case, I'd be very hesitent to use a non-tagged union like 
this, because it wouldn't provide protection against accidentally having the 
same integer value for a member of STD and a member of A or B (which would 
obviously screw the whole thing up). But in your paricular case it doesn't 
seem that would likely be an issue.

Of course, if you dodn't mind a heavier-weight OO-based solution, you could 
always use classes instead of enums and use static immutable class members 
as the possible values (and make the constructor private to prevent 
additional possible values), but personally I think that would be 
over-engineered compared to either the above or the mixin solution in my 
previous message.





More information about the Digitalmars-d mailing list