I was looking at DR 1234 "Do the right thing" and NULL where

#include <vector>
void foo() { std::vector<int*> v(500L, NULL); }

gives an error when NULL is 0L because you get the iterator range
version and illegal conversions from long to int*.

Wouldn't this be cleared up if
#define NULL nullptr
as requested by the (now NAD) DR 1314.

The type of the second argument is then nullptr_t not long and you get
the size + value version.

Ed


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

Ed Smith-Rowland wrote:
> I was looking at DR 1234 "Do the right thing" and NULL where
>
> #include <vector>
> void foo() { std::vector<int*> v(500L, NULL); }
>
> gives an error when NULL is 0L because you get the iterator range
> version and illegal conversions from long to int*.
>
> Wouldn't this be cleared up if
> #define NULL nullptr
> as requested by the (now NAD) DR 1314.
>

Probably. But given the amount of code that (rightly or wrongly) relies
on NULL being an integer 0, that change would be a disaster.

--
    Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

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

Pete Becker wrote:
> Ed Smith-Rowland wrote:
> > I was looking at DR 1234 "Do the right thing" and NULL where
>
> > #include <vector>
> > void foo() { std::vector<int*> v(500L, NULL); }
>
> > gives an error when NULL is 0L because you get the iterator range
> > version and illegal conversions from long to int*.
>
> > Wouldn't this be cleared up if
> > #define NULL nullptr
> > as requested by the (now NAD) DR 1314.
>
> Probably. But given the amount of code that (rightly or wrongly) relies
> on NULL being an integer 0, that change would be a disaster.

AFAICT, this can be fixed (without redefining NULL). I'm just not sure
about whether it's too late in the game. As an alternative one could
say that the containers' constructor templates taking pair of Iter-
values 'a' and 'b' shall not participate in the overload resolution in
case decltype(*a) is ill-formed. I'm not sure about the correct
wording here but I've the following implementation in mind:

  template<[...]>
  class vector
  {
      [...]
     template<class Iter, class = decltype(*declval<Iter>())>
     vector(Iter begin, Iter end);
      [...]
  };

Cheers,
SG

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