On Sat, Mar 19, 2011 at 1:10 AM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Jeffrey Lee Hellrung, Jr.-2 wrote:
[...]
I don't know why the template parameter of the trait disappears each time. Is the second time I have problems with < and >.
:( My email client (just switched to using gmail) may be removing them... Your "corrections" you had given look exactly the same as before :/ [...]
On C++0x there is already the trait underlying_type that is associated to the storage. The same trait is used on the Opaque.Strong Types proposal. So i will prefer to maintain underlying_type us such. The names I'm not happy with are scoping and native.
Fair enough.
So what's with scoping_type? In one case, it's the scoped enum, and in the other case, it's the emulated scoped enum, but in both it looks like an identity operation. I don't get the point.
It is not the identity when the scoped enum is emulated. In any case is the type giving scope to the enumerators, this was the reason for the name.
In the emulation scoping of the nested enum is the identity.
This seems to contradict your earlier statement: "It is not the identity when the scoped enum is emulated." Can you elaborate? Do you mean that the scoping_type maps the "native enum" type of the (emulated) scoped enum back to the (emulated) scoped enum? I.e., native_type and scoping_type are inverse metafunctions?
With scoped enums scoping and enum_type/native_type are identities.
I'm conscientious that this alternative emulation of enums has a major drawback: the emulating type is not an enum and I can understand why others have abandoned the idea. I just wanted to explore it in depth to see if the whole design had more advantages than liabilities, but I suspect that I've not reached it yet.
Actually, what I've seen of the design so far seems very reasonable. I will try to take a closer look at the documentation to get a better sense of the limitations of the emulation. I guess the thing I'd be worried about is how necessary or in-demand scoped enums are. There are clear benefits to them, as evident by their inclusion in the standard, but emulating it doesn't seem like such a big deal as, for example, the move/rvalue reference emulation that Boost.Move provides. As the emulation is not an enum we need some traits to
get the enum type and vice versa. The same is applicable for the value conversion of these type.
Sure, makes sense. - Jeff