On 02/27/2011 04:20 AM, Nick Sabalausky wrote:
"Nick Sabalausky"<a@a.a> wrote in message
news:ikcepj$248p$1...@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.
Very interesting solution, indeed: enum composition via union. I think as well
it's safe because --per definition-- each 'code' of a discriminating enum must
have a distinct value. (They are nominals:
http://en.wikipedia.org/wiki/Nominal_number).
Denis
--
_________________
vita es estrany
spir.wikidot.com
