On Sat, May 12, 2012 at 10:30 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> 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