Re: [boost] Scoped Enum Emulation

Subject: Re: [boost] Scoped Enum Emulation
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2012-01-25 07:26:14

Vicente J. Botet wrote:
> Le 24/01/12 22:51, Beman Dawes a écrit :
> >
> > What do others think? Should
> /boost/detail/scoped_enum_emulation.hpp
> > functionality be moved to config?
> >
> > Are there any improvements that would make the emulation
> > better, without turning something simple into something
> > complex?
>
> I'm working with a different emulation which uses classes.
> For example
>
>    // enum class cv_status;
>    BOOST_DECLARE_STRONG_ENUM_BEGIN(cv_status)
>    {
>      no_timeout,
>      timeout
>    };
>    BOOST_DECLARE_STRONG_ENUM_END(cv_status)
>
> The macros are defined as follows:
>
> #ifdef BOOST_NO_SCOPED_ENUMS
> #define BOOST_DECLARE_STRONG_ENUM_BEGIN(x) \
>    struct x { \
>      enum enum_type
>
> #define BOOST_DECLARE_STRONG_ENUM_END(x) \
>      enum_type v_; \
>      inline x()  {} \
>      inline x(enum_type v) : v_(v) {} \
>      inline operator int() const {return v_;} \
>      friend inline bool operator ==(x lhs, int rhs) \
>                         {return lhs.v_==rhs;} \
>      friend inline bool operator ==(int lhs, x rhs) \
>                         {return lhs==rhs.v_;} \
>      friend inline bool operator !=(x lhs, int rhs) \
>                         {return lhs.v_!=rhs;} \
>      friend inline bool operator !=(int lhs, x rhs) \
>                         {return lhs!=rhs.v_;} \
>    };
>
> #define BOOST_STRONG_ENUM_NATIVE(x) x::enum_type
> #else  // BOOST_NO_SCOPED_ENUMS
> #define BOOST_DECLARE_STRONG_ENUM_BEGIN(x) enum class x
> #define BOOST_DECLARE_STRONG_ENUM_END(x)
> #define BOOST_STRONG_ENUM_NATIVE(x) x
> #endif  // BOOST_NO_SCOPED_ENUMS
>
> While this is not yet a complete emulation of scoped enums,
> it has the advantage of that there is no need to use a macro to
> name the strong type.

It looks decent, but shouldn't int be a computed type based upon the size and signed-ness of enum_type?  Of course, you could also provide macros to specify the underlying type and use that, instead of enum_type, as the type of v_.  That would increase compatibility with strongly typed enums in C++11.

Why convert implicitly to int rather than to enum_type?  You could convert to the computed type I mentioned above, but converting to enum_type would ensure the most appropriate conversions, wouldn't it?

It might also be good to put the semicolon closing the enumerated type definition into the _END macro.  That would increase symmetry and more strongly tie the _END macro to the construct:

   BOOST_DECLARE_STRONG_ENUM_BEGIN(cv_status)
   {
      no_timeout,
      timeout
   }
   BOOST_DECLARE_STRONG_ENUM_END(cv_status)

It would be nice if the macros would produce strongly typed enums, when available, and devolve to emulation when not.

It might also prove useful to have a macro to forward declare them: BOOST_FORWARD_DECLARE_STRONG_ENUM(name).  That would forward declare a normal class, when emulating, and forward declare the enum class otherwise.

_____
Rob Stewart                           robert.stewart_at_[hidden]
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.