|
Boost : |
From: Alexander Nasonov (alnsn_at_[hidden])
Date: 2005-02-18 06:43:25
Vladimir Prus wrote:
> Alexander Nasonov wrote:
> I think you're right, and trying gcc +
> BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION confirms that.
> I've committed this part of the patch.
Great!
One question. How to make sure that we don't break existing code on broken
compilers?
My plan is to extend existing testcase with more exotic use of _old_
functionality (details
below) and to put _new_ functionality into separate testcase. Does it sound good
to you?
> > const is already stripped because ctor's argument is 'const ValueType &
> > value'.
> > So, it's only for volatile. remove_cv is used only to avoid inclusion of
> > remove_volatile.hpp.
> Does this use case matters, btw?
I don't know. Even if it matters to some, I never saw their complains.
Presumably, because this code snipset compiles and runs nicely:
// candidate for inclusion into _old_ test
int volatile i = 0;
any a_i(i);
any_cast<int>(a_i);
int r = any_cast<int>(a_i);
r = any_cast<int const>(a_i);
r = any_cast<int volatile>(a_i);
r = any_cast<int const volatile>(a_i);
If not patched, it has a suble bug. a_i owns holder<int volatile> but any_cast
function treats it as
holder<int>, holder<int const>, holder<int volatile> and holder<int const
volatile>, respectively.
If you're going to fix this, please do it on both ends: in ctor and in any_cast.
If you fix only any_cast end, you may end up with unsafe down cast over base
pointer from holder<int volatile> to holder<int>.
If you disable volatile at ctor end, some users (better if tests) will complain.
Correct type for storing 'int cv' value in a_i is holder<int> (without cv!).
> > Quoting myself:
> >
> >> I forgot to mention that the original version has small problem with
> >> any_cast
> >> to const type. If any stores T and you cast it to T const you're
> > trying
> >> this sequence of static_casts:
> >>
> >> holder<T>* -> (in ctor) -> placeholder* -> (in any_cast) -> holder<T>
> > const>*
> >>
> >> Obviously, it's not getting back to original holder<T> type.
> What about declaring that 'T' in all variants should have *no*
> cv-qualification? It's a bit strange that the user can cast to volatile
> type, and the any_cast will just throw that away. And cast *from* volalite
> any does not work, i.e.
> volatile boost::any a = 1;
> volatile int& i = boost::any_cast<volatile int&>(a);
> does not compile. So what's the point of allowing volatile type at all?
Why do you need volatile any? Safe casts to cv types and proper construction
from volatile variable are things I was trying to fix.
-- Alexander Nasonov
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk