Date: 2002-04-26 05:16:22
> From: Markus Schöpflin [mailto:markus.schoepflin_at_[hidden]]
> I don't agree at all.
> I did think implicit conversions are generally considered dangerous.
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.
> What is so bad if you have to write
> vec.push_back(boost::any(std::string(", this works!")));
Actually, I don't think it's bad at all. There's a 5- or 12-character
penalty, and changing implicit to explicit adds to the requirements on the
client (which I think speaks in favor of the ease-of-use argument) but
that's about it. The safety arguments for explicit are obvious.
> 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.
> > 1) Compiler deficiencies. I gave it a quick try on three
> compilers, and these were the results:
> > * Compiler X didn't care about explicit for templated
> So nothing changes for this compiler.
Sure it does. The change makes it easier to write illegal code that works
with this compiler.
> > * Compiler Y worked!
> So something improves (IMHO) for this compiler.
Agreed, if viewed without the context of other compilers.
> > * Compiler Z understood the explicit part, but couldn't
> even pass a correctly constructed const any& to functions
> Could you give an example, please?
With an explicit templated constructor for any, on a popular compiler, the
following doesn't compile:
vec.push_back(a); // doesn't work - cannot convert from const boost::any
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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk