Enums: naming question?
Hi, I'm developing a scoped enum library that use an emulation wrapping the native enum on a class to get scoped enumerators. I need some traits, to get the native type from the emulation, and the coping class from the native one. In addition there is an underlying type that is used to store the enumerators. Next follows the names I have use in the library: native_type::type underlying_type::type scoping_type::type In addition I have defined some functions that make the conversions from these types template native_type::type native_value(ScopedEnum e); template underlying_type::type underlying_value(ScopedEnum e); I have defined all these under the boost::enums namespace. Do you have a better proposal for these (meta-)functions? If you need more details you can take a look in the sandbow/enums directory http://svn.boost.org/svn/boost/sandbox/enums/libs/enums/doc/html/index.html Best, Vicente P.S. Note native-type and native_value are yet in the doc as enum_type and enum_value. The tutorial is really in a very draft state :( -- View this message in context: http://boost.2283326.n4.nabble.com/Enums-naming-question-tp3388473p3388473.h... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Fri, Mar 18, 2011 at 2:10 PM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Hi,
I'm developing a scoped enum library that use an emulation wrapping the native enum on a class to get scoped enumerators.
I need some traits, to get the native type from the emulation, and the coping class from the native one. In addition there is an underlying type that is used to store the enumerators. Next follows the names I have use in the library:
native_type::type underlying_type::type scoping_type::type
In addition I have defined some functions that make the conversions from these types
template native_type::type native_value(ScopedEnum e);
template underlying_type::type underlying_value(ScopedEnum e);
I have defined all these under the boost::enums namespace.
Do you have a better proposal for these (meta-)functions?
If you need more details you can take a look in the sandbow/enums directory http://svn.boost.org/svn/boost/sandbox/enums/libs/enums/doc/html/index.html
Best, Vicente
P.S. Note native-type and native_value are yet in the doc as enum_type and enum_value. The tutorial is really in a very draft state :(
Perhaps you can summarize what these types and (meta-)functions are suppose to be/do? I trolled through the documentation but...it's kind of long for me to go through the whole thing at the moment :/ - Jeff
Jeffrey Lee Hellrung, Jr.-2 wrote:
On Fri, Mar 18, 2011 at 2:10 PM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Hi,
I'm developing a scoped enum library that use an emulation wrapping the native enum on a class to get scoped enumerators.
I need some traits, to get the native type from the emulation, and the coping class from the native one. In addition there is an underlying type that is used to store the enumerators. Next follows the names I have use in the library:
native_type::type underlying_type::type scoping_type::type
In addition I have defined some functions that make the conversions from these types
template native_type::type native_value(ScopedEnum e);
template underlying_type::type underlying_value(ScopedEnum e);
I have defined all these under the boost::enums namespace.
Do you have a better proposal for these (meta-)functions?
If you need more details you can take a look in the sandbow/enums directory http://svn.boost.org/svn/boost/sandbox/enums/libs/enums/doc/html/index.html
Best, Vicente
P.S. Note native-type and native_value are yet in the doc as enum_type and enum_value. The tutorial is really in a very draft state :(
Perhaps you can summarize what these types and (meta-)functions are suppose to be/do? I trolled through the documentation but...it's kind of long for me to go through the whole thing at the moment :/
Yes of course. When scoped enum classes are available we can use enum class EnumClass : short {E1, ... En}; In this case the scoped enum class is already an enum. is_enum::value is true typedef EnumClass EnumClassNative; native_type::type is EnumClass underlying_type::type is short scoping_type::type is EnumClass When scoped enum classes is not supported the emulation uses the well known schema template class EnumClass { public: //! c++98 enum type typedef enum {E1, ... En} type; //! underlying type typedef short underlying_type; private: underlying_type val_; ... }; and of course EnumClass is not an enum :( is_enum::value is false typedef EnumClass::type EnumClassNative; native_type::type is EnumClassNative underlying_type::type is short scoping_type::type is EnumClass Let me know if you need more details. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Enums-naming-question-tp3388473p3388818.h... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Fri, Mar 18, 2011 at 5:55 PM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Jeffrey Lee Hellrung, Jr.-2 wrote:
On Fri, Mar 18, 2011 at 2:10 PM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Hi,
I'm developing a scoped enum library that use an emulation wrapping the native enum on a class to get scoped enumerators.
I need some traits, to get the native type from the emulation, and the coping class from the native one. In addition there is an underlying type that is used to store the enumerators. Next follows the names I have use in the library:
native_type::type underlying_type::type scoping_type::type
[...]
If you need more details you can take a look in the sandbow/enums directory
http://svn.boost.org/svn/boost/sandbox/enums/libs/enums/doc/html/index.html
[...]
Perhaps you can summarize what these types and (meta-)functions are suppose
[...]
When scoped enum classes are available we can use
enum class EnumClass : short {E1, ... En};
In this case the scoped enum class is already an enum.
is_enum::value is true typedef EnumClass EnumClassNative; native_type::type is EnumClass underlying_type::type is short scoping_type::type is EnumClass
When scoped enum classes is not supported the emulation uses the well known schema
template class EnumClass { public: //! c++98 enum type typedef enum {E1, ... En} type; //! underlying type typedef short underlying_type; private: underlying_type val_; ... };
and of course EnumClass is not an enum :(
is_enum::value is false typedef EnumClass::type EnumClassNative; native_type::type is EnumClassNative underlying_type::type is short scoping_type::type is EnumClass
Let me know if you need more details.
Thanks, that helps, I think: So native_type is an enum type; why did you change the name from enum_type? Maybe native_enum_type would be better? I get underlying_type. Consider underlying_integral_type, to distinguish it from the "underlying enum" type...although it's longer :/ It just seems that native_type and underlying type almost sound like the same thing, and I could imagine easily getting confused. So what's with scoping_type? In the 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. - Jeff
Jeffrey Lee Hellrung, Jr.-2 wrote:
On Fri, Mar 18, 2011 at 5:55 PM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Jeffrey Lee Hellrung, Jr.-2 wrote:
On Fri, Mar 18, 2011 at 2:10 PM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Hi,
I'm developing a scoped enum library that use an emulation wrapping
the
native enum on a class to get scoped enumerators.
I need some traits, to get the native type from the emulation, and the coping class from the native one. In addition there is an underlying type that is used to store the enumerators. Next follows the names I have use in the library:
native_type::type underlying_type::type scoping_type::type
[...]
If you need more details you can take a look in the sandbow/enums directory
http://svn.boost.org/svn/boost/sandbox/enums/libs/enums/doc/html/index.html
[...]
Perhaps you can summarize what these types and (meta-)functions are suppose
[...]
When scoped enum classes are available we can use
enum class EnumClass : short {E1, ... En};
In this case the scoped enum class is already an enum.
is_enum::value is true typedef EnumClass EnumClassNative; native_type::type is EnumClass underlying_type::type is short scoping_type::type is EnumClass
I don't know why the template parameter of the trait disappears each time. Is the second time I have problems with < and >. What I wanted to say was is_enum::type is true typedef EnumClass EnumClassNative; native_type::type is EnumClass underlying_type::type is short scoping_type::type is EnumClass
When scoped enum classes is not supported the emulation uses the well known schema
template class EnumClass { public: //! c++98 enum type typedef enum {E1, ... En} type; //! underlying type typedef short underlying_type; private: underlying_type val_; ... };
and of course EnumClass is not an enum :(
is_enum::value is false typedef EnumClass::type EnumClassNative; native_type::type is EnumClassNative underlying_type::type is short scoping_type::type is EnumClass
And is_enum::type is false typedef EnumClass::type EnumClassNative; native_type::type is EnumClassNative underlying_type::type is short scoping_type::type is EnumClass
Let me know if you need more details.
Thanks, that helps, I think:
So native_type is an enum type; why did you change the name from enum_type? Maybe native_enum_type would be better?
What I wanted to say by native was the enum type supported by the compiler. Maybe be native_enum_type or simply enum_type are clearer, yes. What others thing?
I get underlying_type. Consider underlying_integral_type, to distinguish it from the "underlying enum" type...although it's longer :/ It just seems that native_type and underlying type almost sound like the same thing, and I could imagine easily getting confused.
I understand you and other can be confused. This was the reason of the post, try to avoid the possible confusions ;-) 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.
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. 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. 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. Thanks a lot, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Enums-naming-question-tp3388473p3389239.h... Sent from the Boost - Dev mailing list archive at Nabble.com.
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
Jeffrey Lee Hellrung, Jr.-2 wrote:
On Sat, Mar 19, 2011 at 1:10 AM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Jeffrey Lee Hellrung, Jr.-2 wrote:
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?
Yes.
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.
I agree partially. I'm concerned by the scoped enums that are already defined by the standard C++ and that have an equivalent on Boost. Without an emulation there is no way to write portable programs that can adapt to the whether the scoped enum is supported by the compiler. Beman has created his scoped enum emulation just for this purpose, but it lacks some scoped enum features as it is implicitly convertible to the underlying type.
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.
Thanks for your interest, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Enums-naming-question-tp3388473p3389454.h... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Sat, Mar 19, 2011 at 4:20 AM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Jeffrey Lee Hellrung, Jr.-2 wrote:
[...]
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?
Yes.
Then all I can suggest as a better name is *maybe* scoped_type or scoped_enum_type. But scoping_type might be fine.
Beman has created his scoped enum emulation just for this purpose, but it lacks some scoped enum features as it is implicitly convertible to the underlying type.
How is it otherwise different from your implementation? Does it use simpler syntax or fewer (meta-)functions? - Jeff
Jeffrey Lee Hellrung, Jr.-2 wrote:
On Sat, Mar 19, 2011 at 4:20 AM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Jeffrey Lee Hellrung, Jr.-2 wrote:
[...]
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?
Yes.
Then all I can suggest as a better name is *maybe* scoped_type or scoped_enum_type. But scoping_type might be fine.
Hmm, scoping_type and scoped_enum_type seems reasonable, but I prefer yet the use of native_type. What do others think?
Beman has created his scoped enum emulation just for this purpose, but it lacks some scoped enum features as it is implicitly convertible to the underlying type.
How is it otherwise different from your implementation? Does it use simpler syntax or fewer (meta-)functions?
Extracted from the file boost/detail/scoped_enum_emulation.hpp: // Caution: only the syntax is emulated; the semantics are not emulated and // the syntax emulation doesn't include being able to specify the underlying // representation type. // // The emulation is via struct rather than namespace to allow use within classes. // Thanks to Andrey Semashev for pointing that out. // // Helpful comments and suggestions were also made by Kjell Elster, Phil Endecott, // Joel Falcou, Mathias Gaunard, Felipe Magno de Almeida, Matt Calabrese, Vincente // Botet, and Daniel James. // // Sample usage: // // BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END // ... // BOOST_SCOPED_ENUM(algae) sample( algae::red ); // void foo( BOOST_SCOPED_ENUM(algae) color ); // ... // sample = algae::green; // foo( algae::cyan ); and here the emulation code # define BOOST_SCOPED_ENUM_START(name) struct name { enum enum_type # define BOOST_SCOPED_ENUM_END }; # define BOOST_SCOPED_ENUM(name) name::enum_type The syntax is similar, but the used type is BOOST_SCOPED_ENUM(name) for Beman design and name in mine. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Enums-naming-question-tp3388473p3390196.h... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 19.03.2011 23:12, Vicente Botet wrote:
Jeffrey Lee Hellrung, Jr.-2 wrote:
Then all I can suggest as a better name is *maybe* scoped_type or scoped_enum_type. But scoping_type might be fine.
Hmm, scoping_type and scoped_enum_type seems reasonable, but I prefer yet the use of native_type. What do others think?
I like scoped_enum_type name :) -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
Max Sobolev wrote:
On 19.03.2011 23:12, Vicente Botet wrote: > > Jeffrey Lee Hellrung, Jr.-2 wrote: >> >> Then all I can suggest as a better name is *maybe* scoped_type or >> scoped_enum_type. But scoping_type might be fine. >> > > Hmm, scoping_type and scoped_enum_type seems reasonable, but I prefer yet > the use of native_type. What do others think?
I like scoped_enum_type name :)
Sorry, I think I misunderstood Jeffrey. were you proposing to replace scoping_type by scoped_enum_type or or scoped_type and let native_type as now? Thanks, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Enums-naming-question-tp3388473p3392828.h... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 21.03.2011 10:42, Vicente Botet wrote:
Max Sobolev wrote:
I like scoped_enum_type name :)
were you proposing to replace scoping_type by scoped_enum_type or or scoped_type and let native_type as now?
on my taste, scoped_enum_type is preferable to scoping_type -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
On Mon, Mar 21, 2011 at 12:42 AM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Max Sobolev wrote:
On 19.03.2011 23:12, Vicente Botet wrote: > > Jeffrey Lee Hellrung, Jr.-2 wrote: >> >> Then all I can suggest as a better name is *maybe* scoped_type
>> scoped_enum_type. But scoping_type might be fine. >> > > Hmm, scoping_type and scoped_enum_type seems reasonable, but I
or prefer
yet > the use of native_type. What do others think?
I like scoped_enum_type name :)
Sorry, I think I misunderstood Jeffrey.
were you proposing to replace scoping_type by scoped_enum_type or or scoped_type and let native_type as now?
The quote referred to replacing scoping[_type] with either scoped[_type] or scoped_enum[_type] (I like the latter better). I had already commented that I think native_enum[_type] would be clearer than native[_type] and underlying_integer[_type] clearer than underlying[_type] (although this latter case is already called underlying_type in the standard, right?). Robert Stewart brought up a good point on the redundancy of the "_type" suffix, so although the above alternatives to your current metafunction names are longer, that will be mostly mitigated by removing the redundant "_type" suffix. However, we do have free function analogues of these metafunctions, correct? Maybe you can put the metafunctions in a result_of namespace, as Boost.Fusion does? [I'm hoping the angle brackets get preserved...] namespace result_of{ template< class E > struct native_enum; template< class E > struct underlying_integer; template< class E > struct scoped_enum; } // namespace result_of template< class E > typename result_of::native_enum<E>::type native_enum(const E e); // etc. - Jeff
Message du 21/03/11 16:32 De : "Jeffrey Lee Hellrung, Jr." Robert Stewart brought up a good point on the redundancy of the "_type" suffix, so although the above alternatives to your current metafunction names are longer, that will be mostly mitigated by removing the redundant "_type" suffix. However, we do have free function analogues of these metafunctions, correct? Maybe you can put the metafunctions in a result_of namespace, as Boost.Fusion does?
[I'm hoping the angle brackets get preserved...]
Me too. Lately I was using the Nabble web interface. I have no had any problems in the past, but it seems not be the case now.
namespace result_of{ template< class E > struct native_enum; template< class E > struct underlying_integer; template< class E > struct scoped_enum; } // namespace result_of template< class E > typename result_of::native_enum::type native_enum(const E e); // etc.
I like the result_of trick. What I don't like too much is underlying_integer :( Best, Vicente
On Mon, Mar 21, 2011 at 10:49 AM, Vicente BOTET <vicente.botet@wanadoo.fr>wrote:
I like the result_of trick. What I don't like too much is underlying_integer :(
Fortunately, my feelings aren't hurt *too* much :) I will point out, with {native_enum, underlying_integer, scoped_enum}, that I like the consistency of them all being "things" (i.e., nouns), rather than adjectives. Robert Stewart suggested "underlying_storage", which I think is still better than just plain "underlying", but (to me) less descriptive than "underlying_integer". At least now you have some alternatives to consider, though. - Jeff
Jeffrey Lee Hellrung, Jr. wrote:
On Mon, Mar 21, 2011 at 10:49 AM, Vicente BOTET <vicente.botet@wanadoo.fr>wrote:
I like the result_of trick. What I don't like too much is underlying_integer :(
I will point out, with {native_enum, underlying_integer, scoped_enum}, that I like the consistency of them all being "things" (i.e., nouns), rather than adjectives. Robert Stewart suggested "underlying_storage", which I think is still better than just plain "underlying", but (to me) less descriptive than "underlying_integer".
Actually, my suggestion was for just "storage," not "underlying_storage." _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Vicente Botet wrote:
Jeffrey Lee Hellrung, Jr.-2 wrote:
<vicente.botet@wanadoo.fr>wrote:
I need some traits, to get the native type from the emulation, and the coping class from the native one. In addition there is an underlying type that is used to store the enumerators. Next follows the names I have use in the library:
native_type::type underlying_type::type scoping_type::type
In addition I have defined some functions that make the conversions from these types
template native_type::type native_value(ScopedEnum e);
I receive your message as plain text and the <'s and >'s are missing. I'm not using gmail as my client, so it would seem to be something on your end.
template underlying_type::type underlying_value(ScopedEnum e);
I have defined all these under the boost::enums namespace.
Do you have a better proposal for these (meta-)functions?
Perhaps you can summarize what these types and (meta-) functions are suppose to be/do?
When scoped enum classes are available we can use
enum class EnumClass : short {E1, ... En};
In this case the scoped enum class is already an enum.
is_enum::value is true typedef EnumClass EnumClassNative; native_type::type is EnumClass underlying_type::type is short scoping_type::type is EnumClass
Your use of "*_type::type" is redundant. Why not "underlying::type" instead of "underlying_type::type," for example? In this case, EnumClass is the "scoped enumeration" type, just based upon the standard's naming, right? Thus, "scoped_enum::type" (or "scoped_enumeration::type") would seem right. "underlying" is a reasonable term for the storage type, though "storage type" seems more to the point. From the grammar, it is the enum-base and "enum_base::type" would work very well. That leaves "native_type." More on that below.
When scoped enum classes is not supported the emulation uses the well known schema
template class EnumClass { public: //! c++98 enum type typedef enum {E1, ... En} type; //! underlying type typedef short underlying_type; private: underlying_type val_; ... };
and of course EnumClass is not an enum :(
is_enum::value is false typedef EnumClass::type EnumClassNative; native_type::type is EnumClassNative underlying_type::type is short scoping_type::type is EnumClass
Since "native_type" is a fabrication to account for the implementation distinction between the emulation and native scoped enums, "native" hardly seemed the right adjective at first. Upon reflection, it occurs to me that it refers to the native enumerated type within the two mechanisms, so perhaps it works well after all. Since the point is to determine the enumerated type in the scoped enumeration, "enum::type" would follow the pattern of my earlier suggestions using "enum" in the name, but that, of course, won't do. BTW, "underlying" may be an appropriate adjective for this aspect. Here are two options, summarized from the previous discussion: Your Names Option 1 Option 2 ----------------------------------------------- native_type enumeration native_enum underlying_type enumeration_storage enum_base scoping_type scoped_enumeration scoped_enum Obviously, Option 2 uses shorter names which are preferable all others things being equal, and it uses the term from the grammar (enum_base). _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (5)
-
Jeffrey Lee Hellrung, Jr. -
Max Sobolev -
Stewart, Robert -
Vicente Botet -
Vicente BOTET