On Thu, 26 Feb 2004 14:32:53 +0300 Vladimir Prus <ghost@cs.msu.su> wrote:

That's right. I used my case, where convenience was not hurt, to illustrate the the decision that ctor should not be explicit is not entirely obvious.

Obviously, Kelvin does not want to make the ctor explicit, and even if he did, the change would most likely break existing code. However, some users may desire the pedantic behavior of an explicit constructor. What would be wrong with changing the ctor to be something like this... template<typename ValueType> #if defined(BOOST_ANY_HAS_EXPLICIT_CTOR) explicit #endif any(const ValueType & value) : content(new holder<ValueType>(value)) { } then users can get the functionality if they want it, but, by default, you get the same behavior. Since the implementation is an inline member template, there should be no linking issues. Of course, it is yet another macro... -- Jody Hagins Power corrupts. And atomic power corrupts atomically.

On Thu, 26 Feb 2004 15:20:46 +0000 (UTC) Joaquin M Lopez Munoz <joaquin@tid.es> wrote:

I'd say (I could be wrong, though) that this would cause much trouble. You have two options for using your proposed solution:

1. Define BOOST_ANY_HAS_EXPLICIT_CTOR globally in your project, thus possibly breaking existing code (which might lie deep inside Boost itself.)

This is what I was thinking. Oddly enough, while I have several libraries that use boost::any, it is not used that much in the boost library itself, and it may be reasonable to change any library code to support the tighter scope of the explicit ctor. It would mean that library code would have to code as if the ctor were explicit, but users could use it either way (so long as the use is consistent). -- Jody Hagins