Re: [boost] Remembering that T(a) can cause dangerous conversion like a C-style cast

Subject: Re: [boost] Remembering that T(a) can cause dangerous conversion like a C-style cast
From: Kazutoshi Satoda (k_satoda_at_[hidden])
Date: 2011-11-04 02:30:56

michi7x7 wrote:
>> I have crafted a general replacement of T(a) as a workaround for
>> dangerous conversions caused by T(a) which may happen in some kinds of
>> templates.
>
> There is already one in boost (Functional/Factory) AFAIK, but it might
> has the same problem:
> http://www.boost.org/doc/libs/1_47_0/libs/functional/factory/doc/html/index.html
>
> boost::value_factory<T>()(arg1,arg2,arg3)
> // same as T(arg1,arg2,arg3)

Thank you for pointing out. It is another example of the problem. I
verified that boost::value_factory<int>()("") compiles, too.

My replacement (unary_initialized) is meant to be used internally to
aid these library codes. For the case of value_factory, something like
pack_initialized, I've shown later in the story about variadic
templates, seems desired.

>> To avoid the unexpected conversion, I first proposed use of T{...} .
>> But it is not a perfect solution because it changes the meaning in some
>> cases like std::vector<int>.
> But this is exactly the use-case T{...} was made for. Of course
> initializer_lists make this approach completely unusable...

FYI, I found a somewhat related paper.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2477.pdf

With pack_initialized, I imagine one can still use initializer_list
constructors explicitly, like this:
   pack_initialized<std::vector<int>>(std::initializer_list<int>{...}).value

> Another possible solution would be to use static_cast<T>(a) for one
> constructor-argument, as static_cast is type-safe.

Unfortunately, static_cast involves base* to derived* conversion which
needs special assumption to be safe.

>> Thinking more, I wonder why such dangerous conversion was explicitly
>> injected to T(a) in the first place.  I first thought of some
>> C-compatibility issues. But now I think it cannot be, because T(a) is a
>> new construct in C++.  Is it possible to remove this dangerous
>> conversion path in a future revision of the standard?
>
> T(a) is a function-style cast which was used in C, removing it would be
> rather difficult.

"function-style cast which was used in C" ?
I still believe that function-style cast is new in C++, meaning that
(T)a is the only syntax of casts in C. Could you please give an example
of valid function-style cast in C code?

-- 
k_satoda