[Bug libstdc++/43813] New: vector<T*>(3, NULL) fails to compile

[Bug libstdc++/43813] New: vector<T*>(3, NULL) fails to compile

[jyasskin at gmail dot com]

-------
#include <vector>
std::vector<double*> v(7, 0);
-------

lands on the

template <class InputIterator> vector(InputIterator first, InputIterator last,
const Allocator& = Allocator()); 

constructor instead of

explicit vector(size_type n, const T& value = T(), const Allocator& =
Allocator()); 

which the user intended. The InputIterator constructor tries to forward to
_M_fill_initialize because both arguments are integral, but the "0" has now
been permanently bound to the int type, stopping it from converting to a null
double*.

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1234 indicates that
the current behavior is conformant, but that the committee seems to want to
require the call to do what the user intended in a future standard.

Passing "NULL" instead of "0" makes the error depend on the build target. For
example, NULL appears to be an int on x86-32 but a long on x86-64, meaning the
error appears on x86-32 but not on x86-64.


-- 
           Summary: vector<T*>(3, NULL) fails to compile
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jyasskin at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813

[Bug libstdc++/43813] [DR1234] vector<T*>(3, NULL) fails to compile

[redi at gcc dot gnu dot org]

------- Comment #1 from redi at gcc dot gnu dot org  2010-04-20 09:40 -------
(In reply to comment #0)
> Passing "NULL" instead of "0" makes the error depend on the build target. For
> example, NULL appears to be an int on x86-32 but a long on x86-64, meaning the
> error appears on x86-32 but not on x86-64.

Right, NULL is 0L on 64-bit to ensure it has the same size as (void*) and can
be used as a sentinel in varargs functions such as execl


-- 

redi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-04-20 09:40:35
               date|                            |
            Summary|vector<T*>(3, NULL) fails to|[DR1234] vector<T*>(3, NULL)
                   |compile                     |fails to compile


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813

[Bug libstdc++/43813] [DR1234] vector<T*>(3, NULL) fails to compile

[redi at gcc dot gnu dot org]

------- Comment #2 from redi at gcc dot gnu dot org  2010-04-20 09:40 -------
Suspending while the issue is open


-- 

redi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813

[Bug libstdc++/43813] [DR1234] vector<T*>(3, NULL) fails to compile

[paolo dot carlini at oracle dot com]

------- Comment #3 from paolo dot carlini at oracle dot com  2010-04-20 16:10 -------
The issue has been discussed a little bit in Pittsburgh and frankly people
(besides Matt) didn't show a huge interest. I think it's well possible that
will not be resolved in time for C++1x (unless, as usual, one or more National
Bodies submit specific comments vs the FCD about it)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813

[Bug libstdc++/43813] [DR1234] vector<T*>(3, NULL) fails to compile

[jyasskin at gmail dot com]

------- Comment #4 from jyasskin at gmail dot com  2010-04-20 16:34 -------
It seems like a QoI issue until the C++ issue is resolved, since the expected
behavior is also allowed by the standard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813

[Bug libstdc++/43813] [DR1234] vector<T*>(3, NULL) fails to compile

[redi at gcc dot gnu dot org]

------- Comment #5 from redi at gcc dot gnu dot org  2010-04-20 16:50 -------
patches welcome :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813

[Bug libstdc++/43813] [DR1234] vector<T*>(3, NULL) fails to compile

[redi at gcc dot gnu dot org]

------- Comment #6 from redi at gcc dot gnu dot org  2010-04-20 16:59 -------
one problem is that it's not trivial to determine if a type "qualifies as an
input iterator" because a non-iterator type could provide private members which
perform some of the operations supported by an iterator (e.g. operator++) and
attempting to test for those members will give an access violation

there's some related discussion starting at Bug 40497 comment 23


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813

[Bug libstdc++/43813] [DR1234] vector<T*>(3, NULL) fails to compile

[jyasskin at gmail dot com]

------- Comment #7 from jyasskin at gmail dot com  2010-04-20 20:04 -------
Patch request acknowledged. :) My plan if I do get around to writing it is to
use enable_if<!is_integral<InputIterator>> since that's the rule
[lib.sequence.reqmts]p9 asks for.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813

[Bug libstdc++/43813] [DR1234] vector<T*>(3, NULL) fails to compile

[paolo dot carlini at oracle dot com]

------- Comment #8 from paolo dot carlini at oracle dot com  2010-04-21 00:33 -------
Note: if the *only* way to change the behevior for the best requires using
enable_if on the user-level member functions (as, if I remember correctly,
pioneered by Howard at Metrowerks quite a few years ago), we have to make sure
we do it consistently over all the dispatchings in the containers, and check
what happens if a binary built with the headers using the old-style dispatching
is linked to a new one. In case, restrict the mechanism to C++0x mode. But
really, I'd rather wait for a resolution anyway, even as NAD but clearly
stating this is a QoI issue.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813