|
Boost : |
Subject: Re: [boost] [utility/value_init] boost::value_initialized<T> direct-initialized?
From: Niels Dekker - address until 2010-10-10 (niels_address_until_2010-10-10_at_[hidden])
Date: 2010-03-31 18:04:50
>> I'm not entirely sure if the initialized(T const&) constructor
>> would need an "explicit" keyword. What do you think? Should the
>> following be forbidden?
>>
>> boost::initialized<int> i = 42;
>>
>> If so, we might as well make it even more explicit, by adding a "tag"
>> parameter of type direct_initialized_t to the constructor, as I
>> proposed before at https://svn.boost.org/trac/boost/ticket/3472 so
>> that users would have to explicitly specify that they want
>> direct-initialization:
>>
>> boost::initialized<int> i(42, boost::direct_initialized);
Steven Watanabe wrote:
> I'd much prefer boost::initialized to simply forward constructor arguments.
Thanks, Steven. But would it be okay to you if boost::initialized<T>
would just have a initialized(const T&) constructor? Or do you think it
should be a "variadic" one, for example initialized(const U&...). I'm
afraid it's hard to implement such a variadic constructor, perfectly
forwarding its arguments to the internal T object, given current
limitations of a lot of compilers. And personally I think it would be
sufficient to just offer a initialized(const T&) constructor. But please
tell me if you think otherwise.
> The templated constructor should be explicit, because otherwise
> things like
>
> boost::initialized<std::vector<int> > v = 10;
>
> would compile.
Please note that I never suggested to make your example compile. I was
only wondering whether or not the following should compile:
boost::initialized<std::vector<int> > v =
std::vector<int>(10);
So in fact, after initialization by means of initialized(const T&), lhs
and rhs will have the same value. In that case, isn't
copy-initialization appropriate?
Kind regards,
Niels
-- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk