push_back of NULL

[Magnus F]

Using the definition of push_back from from n2461 the following code
seems to result in an invalid conversion:

vector<char*> v;

v.push_back(0);

Is this an intended consequence of the changes to push_back or am I
misreading the proposal?

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

[Alberto Ganesh Barbati]

Magnus F ha scritto:

> Using the definition of push_back from from n2461 the following code
> seems to result in an invalid conversion:
>
> vector<char*> v;
>
> v.push_back(0);
>
> Is this an intended consequence of the changes to push_back or am I
> misreading the proposal?
>

Well spotted!

I'm afraid the answer is no to both questions: this is not an intended
change and your are not misreading the proposal. It's true that the
correct code in C++0X would rather be

v.push_back(nullptr);

but I believe we agree that legacy code using 0 (or NULL) must still be
supported. The first "emplace" proposal added two new functions
emplace_front() and emplace_back() rather than replacing push_front()
and push_back(), but that changed in a later revision. The rationale
was: "I believe there is considerable merit to this because it provides
the user with a single “push” that always does the right thing." It
seems that the authors overlooked the pointer case.

The first thing that comes to my mind is to require the old signature
instead of the new signature when value_type is a pointer type. The new
signature would be overkill anyway, as pointers cannot be constructed
using more than one parameter and won't benefit from the move semantic.
Notice that several library implementations already provide a
specialization of the containers when value_type is a pointer type in
order to reduce code bloat (such a container can easily be implemented
as a thin wrapper over a container of void*) so having a special case
should not be a problem.

Just my opinion,

Ganesh

[Howard Hinnant]

In article <SjZ9j.202045$U01.1...@twister1.libero.it>,

This is now LWG issue 767:

http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active
.html#767

-Howard