Re: [boost] BOSOT_ENUM proposal rev 4

From: Frank Laub (frank.laub_at_[hidden])
Date: 2005-12-13 22:17:58

> static const_iterator begin()
> > static const_iterator end()
> > static boost::optional<const T> get(size_t index)
> > static boost::optional<const T> parse(const char* str)
> > const char* str() const
> > bool operator == (const T& rhs) const
> > bool operator != (const T& rhs) const
> > ostream& operator << (ostream& os, const T& rhs)
>
> 1. What about constructors?

T()
T(domain index) // domain is the name of the embedded enum type

2. What happened to the static 'size' member?

Forgot to mention it, it's still there.

3. The get() and parse() methods can return optional<T> rather than
> optional<const T>. Since everything here is copied-by-value, the const
> doesn't add much, IMO.

OK, I'll buy that.

4. You also need operator< for set/map.

I just added this, thanks for pointing it out.

5. If you have parse() and operator<<, then I guess adding operator>>
> would be logical.

Hrm, yes, but it's hard to write a templated operator>>. Currently I'm able
to template the whole category of enumeration types by just having an
overload for enum_base<T>. In the case of the operator>>, I can't output an
enum_base<T>, it needs to be a T. So my question is, how do I write
operator>> without making it overly generic?

6. People would probably want a value() method as you put in
> BOOST_ENUM_VALUES, in here also.

OK, I got rid of the enum_values_base, and just collapsed it into enum_base.
Therefore, there's really no different between a BOOST_ENUM and a
BOOST_ENUM_VALUES; only the number of columns in the sequence differs.

> static boost::optional<const T> make(size_t value)
> > size_t value() const
>
> As far as I know, C++ allows the numeric value of a enum to be negative,
> so instead of size_t (in both these functions), you need a signed type.

OK, in order to support the stringtable version, I now allow the user to
specify what the datatype of the value portion should be. This makes the
enum_base extermely generic. So now it's:
BOOST_ENUM_VALUES(VirtualKey, size_t,
    (Space)(0x20)
    ...
)

I also think there would be some confusion between get() and make().
> With BOOST_ENUM, get() is naturally the only choice. So users would be
> tempted to use get() also with BOOST_ENUM_VALUES. But this is probably
> not what they are after. With BOOST_ENUM_VALUES, make() is what is most
> useful, and IMO, get() is mostly useless. So maybe get() should do what
> make() does today, and the old get() functionality should be names
> get_by_index() or something similar.

Agreed, I had trouble coming up with a good name for these methods. I like
your suggestion of get_by_index(). So now there is a get() which is an alias
for get_by_value(), and a get_by_index().

Latest updates are now uploaded as enum_rev4.1.zip in the file vault.

-Frank