Boost logo

Boost :

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2002-04-26 10:37:58

> Bjorn.Karlsson_at_[hidden] wrote:
> > From: Markus Schöpflin [mailto:markus.schoepflin_at_[hidden]]
> >


> Yes, implicit conversions are generally considered dangerous/harmful. Why? Because of introduced ambiguities, and errors; for example resulting in that a function call succeeds (at least compiles) although it shouldn't. To some extent, this can (and therefore will) happen with any, but because of the typical use cases for any, the problem (AFAICT) is not common.

The example I gave in my first post shows such a case and it's not a contrieved example.

> > This works because any_print can be implicitly constructed
> > from any. Even an
> > explicit constructor for any allows this to work.
> Absolutely, but you're missing the point - with an explicit constructor for any, the hack would be totally useless; however, for a user who's looking for a solution to a problem it's hopefully worth something.

Ok, you're right. I did miss the point.

> > So nothing changes for this compiler.
> Sure it does. The change makes it easier to write illegal code that works with this compiler.

I don't follow you here.

> > So something improves (IMHO) for this compiler.
> Agreed, if viewed without the context of other compilers.


> > Could you give an example, please?
> With an explicit templated constructor for any, on a popular compiler, the following doesn't compile:
> boost::any a(5);
> std::vector<boost::any> vec;
> vec.push_back(a); // doesn't work - cannot convert from const boost::any etc...

Could you name the compiler? My usual suspect (MSVC) does the right thing in this case.

> My wording was questionable, as is the error...
> I think it would be a big mistake to let compiler deficiencies rule the design of the Boost libraries, equal in size to the mistake of not considering them at all.

We're in violent agreement here.

> The bottom line is this: There's nothing wrong with legal C++ (duh), but unfortunately, reality bites back hard when it means that behavior of a library differs substantially across different compilers. I find that a potent argument although it's a sad fact.

Ok, agreed.

> Bjorn


Boost list run by bdawes at, gregod at, cpdaniel at, john at