Re: smarter enums
From: Victor Bazarov (v.Abazarov_at_comAcast.net)
Date: 07/15/04
- Next message: Victor Bazarov: "Re: libstdc++.so.5 vs. libstdc++.so.6 and externa libraries"
- Previous message: Thomas Matthews: "Re: newbie code question"
- In reply to: Mark A. Gibbs: "Re: smarter enums"
- Next in thread: Mark A. Gibbs: "Re: smarter enums"
- Reply: Mark A. Gibbs: "Re: smarter enums"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 15 Jul 2004 21:56:11 GMT
Mark A. Gibbs wrote:
> i got a lot of replies during my hiatus, but unfortunately, none of them
> seem to be thinking the same way as me with regards to what a smarter
> enum type would be like.
>
> Victor Bazarov wrote:
>
>>> mostly it prevents the enum member names [...]
>>
>>
>>
>> Thank you for your explanation and your psychology (and not psychiatry)
>> lesson (do you know the difference? I probably don't, I only pretend
>> I do). However, I just wanted to point out that you may have started
>> with a wrong premise. Enums don't have members.
>
>
> semantics. whatever you want to call them, i was clearly referring to
> the constituent entities of an enumeration.
They are not entities of an enumeration, and that's the whole point.
Each _enumerator_ (yes, that's what they are called) exist in the
same scope as the enumeration they are declared in. It has its own
type, yes. The same type as the other enumerators declared in the
same enum declaration. The difference between enum declarations is
designated by the _name_ of the enumeration.
>
> btw, you were incorrect, psychiatry was the correct term for what i was
> doing. and yes, i am quite familiar with the difference. this may aid
> you the next time you get confused: if a man says to a psychiatrist, "i
> want to kill everyone i know", the psychiatrist will ask him to tell him
> more, and in the course of their conversation help the man understand
> why he feels so much anger, and help him work it out non-agressively.
>
> if the same man were to say the same thing to a psychologist, the
> psychologist would say, "wow, thanks for telling me that", and note it
> in his journal.
Nope. The difference is in what they treat and how they treat it.
By mentioning a psychiatrist you implied that low self-esteem is
a mental disease or disorder. By correcting you I implied that low
self-esteem is nothing more than a character trait. Diseases and
disorders are treated by psychiatrists, and treated with medication,
while psychologists help people understand and change character traits.
In most cases psychiatrists are also psychologists, i.e. they can talk
people into or out of something, but the inverse is not true, no
psychologist has a right to prescribe any drugs (unless he/she is also
a medical doctor).
> [...] i was more concerned with
> musing out a potential starting point for a solution than explaining
> what i was after. one of the things i am really hoping to prevent is this:
>
> typedef enum { a, b, c } A;
> typedef enum { x, y, z } Z;
>
> A foo = a;
> Z bar = x;
>
> a == x; // will test true, though it is obviously not
Why is it not? Both are declared right after the curly brace without
a special initialiser. Both are declared inside an enumeration with
the same name (no name is a unique name). Why shouldn't they compare
equal?
BTW, 'A' and 'Z' here are just two synonyms for the same type.
>
> and this:
>
> // foo.hpp
> typedef enum { a, b, c } foo_enum;
> // changed to typedef enum { a, e, i } foo_enum;
>
> // bar.hpp
> typedef enum { d, e, f } bar_enum;
> // changed to typedef enum { b, c, d } bar_enum;
Again, 'foo_enum' and 'bar_enum' are but the same type, only two
different names for it. Drop the 'typedef' nonsense.
>
> // file.cpp
> #include "foo.hpp"
> #include "bar.hpp"
> void func(foo_enum foo)
> {
> // will break silently with the changes
And you propose that it should say what?
> switch (foo)
> {
> case c: // it's a c
> case b: // it's a b
> default: // must be an a
> }
> }
> [...]
Perhaps what you're trying to get to is this:
enum ABC { a,b,c };
enum XYZ { x,y,z };
int main()
{
ABC abc = a;
XYZ xyz = y;
return abc == xyz;
}
'abc' and 'xyz' should not just compare non-equal, but an attempt to
compare them should not compile since they are of two different types.
That's not [yet] how the language works. The comparison causes both
values to be promoted to ints. Perhaps they shouldn't, but that's
how it is, and to change that, go to comp.std.c++ and make your case.
BTW, you cannot assign 'xyz' to 'abc', they are of different types.
You can convert between them, though, a static_cast<> is enough.
Introducing a separate type to handle those things the way _you_ want
them handled is just fine. Call them "smart enums", I have no problem
with that. I am still not sure what you mean by "more in line with
the rest of the language", though. Prevention from inserting them
into the surrounding scope is definitely _not_ an improvement. Besides,
how many people have relied on the enumerators being in the scope? I
have no idea, but I'd guess, millions.
Try posting to (and talking to smart people in) comp.std.c++. See what
they say. That's "the rest of the language" crowd. They know more, and
they will pick up on what you are proposing quicker.
Victor
- Next message: Victor Bazarov: "Re: libstdc++.so.5 vs. libstdc++.so.6 and externa libraries"
- Previous message: Thomas Matthews: "Re: newbie code question"
- In reply to: Mark A. Gibbs: "Re: smarter enums"
- Next in thread: Mark A. Gibbs: "Re: smarter enums"
- Reply: Mark A. Gibbs: "Re: smarter enums"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
