Re: enum_<T>::value

"Alexander Nasonov" <[email protected]> writes:

>>Alexander Nasonov writes:
>>> Dave Abrahams writes:
>>>> Because on the Python side, enums are derived from int, which is
>>>> represented as a signed long.
>>>
>>> I see.
>>> It's still unclear what kind of warning a user should get in this
>>> case? Python exception or C++ compile-time error? 
>>
>>Technically we should be smarter about it and use a Python long for
>>representation when necessary.  Is compile-time detection even
>>possible?
>
> It's possible to detect at compile-time that some enum values are out of range.
>
>     static_assert( !is_same<unsigned long, promote<SomeEnum>::type>::value );
>     // promote<T> is in a queue for fast track review
>
> If the goal is not to allow such enums at all (even if a user doesn't register big values), then it's fine, otherwise, compile-time detection is useless.
> Though, I prefer automatic switch to other Python type when some enum values are out of [LONG_MIN, LONG_MAX] range.
> There are several approaches to mapping C++ enum to Python type:
> 1. Find smallest Python integer type that can represent any given enum value (value-based mapping)
> 2. Find smallest Python integer type that can represent all _registered_ enum values.
> 3. Find smallest Python integer type that can represent all enum values even unregistered (I'm not sure that it's possible).
> 4. Find smallest Python integer type that can represent all values from a range allowed by C++ (0 - 2^n-1 if all enum values are positive).
> 5. Find smallest Python integer type that can represent all values of promoted C++ type.
> 6. Promote C++ enum and map resulting integral type to Python type.

7. Just use python long for everything.  It's an arbitrary-precision
   integer.

There are only two Python integer types: int and long.

  >>> type(1 << 30)
  <type 'int'>
  >>> type(1 << 31)
  <type 'long'>
  >>> type(1 << 31 >> 1)
  <type 'long'>
  >>> type(1 << 100)
  <type 'long'>
  >>> 1 << 100
  1267650600228229401496703205376L
  >>>


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click