comp.lang.c++

* Howard Hinnant:
> In article <1202608309.31136.9.camel@maihem>,
> Tristan Wibberley wrote:
>
>> On Sat, 2008-02-09 at 19:36 -0500, Howard Hinnant wrote:
>>
>>> Fwiw, the current C++0X working paper
>>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf) has
>>> wording that will allow:
>>>
>>> std::unique_ptr my_data(new char[size]);
>>> memcpy(my_data.get(), data, size);
>>
>> will this work as expected in c++0x:
>>
>> template
>> std::unique_ptr make_unique_ptr(T&& initval)
>> {
>> return std::unique_ptr initval;
>> }
>>
>> ...
>> auto my_data = make_unique_ptr(new char[size]);
>> ...
>
> No. The problem is that new char[size] returns a char*, not a char[].

No, char[] would also lose crucial type information.

The problem is loss of associated type information.

A solution would have to provide a mechanism to pick up the otherwise
lost type information.

That could also solve the problem of detecting literals.

What was the proposed solution for detecting literals?


> Therefore in make_unique_ptr T is deduced as char*. After that you'll
> need unique_ptr::type> instead of
> unique_ptr to make things work (except for the array business).
>
>> If not, I wonder how many decades till they fix the whole auto_ptr
>> concept enough for the name of a class of that style to even appear in a
>> program without serious risk of totally invisible U/B.
>
> We're open to suggestions and participation.

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?