Boost logo

Boost :

Subject: Re: [boost] Latest changes to scoped enum emulation break existing code
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-05-12 18:21:57


On Sat, May 12, 2012 at 10:30 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 12/05/12 17:58, Vicente J. Botet Escriba a écrit :
>
>> Le 12/05/12 17:09, Jürgen Hunold a écrit :
>>
>>> Hi Vicente,
>>>
>>> On Saturday, 12. May 2012 13:09:56 Vicente J. Botet Escriba wrote:
>>>
>>>> Le 12/05/12 03:17, Hartmut Kaiser a écrit :
>>>>
>>>>> Hey all,
>>>>>
>>>>> The latest commit to the scoped enumerator emulation breaks existing
>>>>> code
>>>>> using the previous version of this functionality.
>>>>> Please see the Spirit regression tests for examples.
>>>>>
>>>>
>>> Hi,
>>>>
>>>> I have rolled back so that we can take the time to analyze what was
>>>> wrong
>>>>
>>> I think I ran into this one yesterday. There is a name clash between an
>>> internal scoped enum helper function "native()" and a spririt enum
>>> containing
>>> an enum value of "native". Changing the scoped enum implementation to use
>>> "native_()" fixed the problem for me.
>>> Patch attached.
>>>
>>> Oh, I didn't though about this possible issue. Thanks for the analysis.
>>
>> Do you think that as these functions are not part of the interface a
>> longer name could be enough to avoid future clashes?
>>
>> I have changed the names of the native and underlying functions to
> get_native_value_ and get_underlying_value_. I hope that these names will
> not be used as names for literals of an enum type.
>
> svn ci boost/detail -m "ScopedEnum: Fix issue with native() function clash"
> Sending boost/detail/scoped_enum_**emulation.hpp
> Transmitting file data .
> Committed revision 78437.
>

If these functions are indeed not exposed to the interface (are they
brought into user code via a macro or something?), then why not something
really specialized like _boost_scoped_enum_native and
_boost_scoped_enum_underlying?

- Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk