Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2000-11-07 12:46:03


From: "Kevlin Henney" <kevlin_at_[hidden]>

> In message <019c01c0480f$6ba10d40$4b0524d4_at_pdimov>, Peter Dimov
> <pdimov_at_[hidden]> writes
> [any and comparisons]
> >Well, actually, we did discuss this in length without reaching an
agreement.
> >:-)
>
> But looking on the bright side, I did tighten up the semantics of
> operator const void * as a result :-)

Aha, I missed that... I see. But isn't comparing &typeid(void) and NULL with
op< undefined behaviour?

> >* MSVC_INCLUDE(template<>) is unnecessary in two places; removing it
would
> >make the code clearer.
>
> It would certainly be clearer, but it also would not compile :-( This is
> based on the fix that Ed Brey posted some time back.

This:

#define COMPILING_MSVC
#include <boost/any.hpp>

int main()
{
 boost::any a1(4);

 a1 = 1.0;

 return 0;
}

compiles for me without the MSVC_INCLUDE(template<>) on the constructor and
the assignment operator.

MSVC always assumes that such functions are explicit specializations, even
without the template<> in front.

> >* The implicit conversion to void* still causes comparisons on anys to
> >compile.
>
> Which is fine, but the semantics are now tighter, ie the result behaves
> a lot more like a bool than an arbitrary pointer. In fact, there is even
> now a test for the behaviour.

Is this behaviour useful? This definition of equality is neither value- nor
identity- based in the usual sense.

--
Peter Dimov
Multi Media Ltd.

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