Boost logo

Boost :

From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2006-03-29 12:36:36


Thank you for your email. Please see my comments inline.

> 1. only the meta information that is really used should end up in the
> (can be done via template instantiations)

I am in the process of completely rewriting the library to make it more boost-
like, as well as adding some of the features on my wish list and to make it
more robust and configurable.
The idea is to do what you describe. The enum is policy driven and allows you
configure the features you want/need. For example, you can disable/enable the
string to enum functionality, configure the internal representation etc.

> 2. use a more intuitive name than "smart enum"
> something like "reflective enum" or so

I quite like the name "smart_enum" but if there is a negative response to the
name I will change it. I hope you don't mind me saying so but I don't
like "reflective_enum" much. Perhaps we can find a compromise?

> 3. the implementation should store the values in a structure like that
> struct enum_name
> {
> enum type { [... values ...] };
> private:
> // [...friend declaration & accessors for meta information...]
> };

This is exactly what my original implementation did as I prefer that practice,
too. However, I realised that there are people out there that would perhaps
like to use this facility but don't want to/can't to go throught all of their
code and change all of the uses of unqualified enum names to qualified ones.
My rewrite provides a facility to create both "free" and "wrapped" enums.

> 3.1. the storage type should be a real enum

Yes, unless the user specifies otherwise. The user can override the base size
of the enum, to e.g. facilitate binary compatibility between shared libraries.
(but this is compile time checked to ensure values will fit). In some rare
cases, if using some of the features of the enum you may also end up with an
integer larger than the one needed just to hold the enum values but again,
this is all user controled. The basic point is that the internal
representation is always just an integer. In fact, you can configure the enum
to actually use storage smaller than may be required to store the actual
enum ;) Probably not very useful but the feature just kind of falls out of
the design so I allow you to enable it.

> 3.2. its name should be "type" so the enclosing structure can act as a

Yes, the internal name is called type.
But I have more than that. You can e.g. use the enum as an mpl bidirectional
sequence, so you can traverse it at compile time.

> 3.3. no public members, access is implemented via freestanding functions

There are some public members which I believe are generally useful. I thought
about this and was undecided between the two approaches: members of free
functions? In the end I decided on providing both. You can then take your

Thanks for the suggestions. I should be able to post something soon.


Boost list run by bdawes at, gregod at, cpdaniel at, john at