std::fill and containers of pointers

Discussion in 'C++' started by red floyd, Aug 6, 2004.

  1. red floyd

    red floyd Guest

    I got an error by using std::fill to set an array of pointers to 0.

    e.g.:

    class XXX;
    XXX* v[30];

    std::fill(v, v+30, 0); // <-- ERROR -- cant' match template type

    I have to either explicitly instantiate std::fill<> or cast 0 to XXX*.
    I've been using th latter:

    std::fill(v, v+30, static_cast<XXX*>(0));

    I understand the issue, that template instantiation processing is
    interpreting the 0 as an integer rather than a pointer value (and thus
    I have to help it along with the cast). Is there any other workaround
    for this? Will the proposed "nullptr" be handled properly in this sort
    of case?
    red floyd, Aug 6, 2004
    #1
    1. Advertising

  2. red floyd wrote:
    > I got an error by using std::fill to set an array of pointers to 0.
    >
    > e.g.:
    >
    > class XXX;
    > XXX* v[30];
    >
    > std::fill(v, v+30, 0); // <-- ERROR -- cant' match template type
    >
    > I have to either explicitly instantiate std::fill<> or cast 0 to XXX*.
    > I've been using th latter:
    >
    > std::fill(v, v+30, static_cast<XXX*>(0));


    You could use a C-style cast, it basically means the same

    std::fill(v, v+30, (XXX*)0);

    > I understand the issue, that template instantiation processing is
    > interpreting the 0 as an integer rather than a pointer value (and thus
    > I have to help it along with the cast). Is there any other workaround
    > for this?


    If there is, I don't know it.

    > Will the proposed "nullptr" be handled properly in this sort
    > of case?


    It's a good question. The function template std::fill is specified as

    template<class FwdIter, class T>
    void fill(FwdIter first, FwdIter last, const T& value);

    or

    template<class OutIter, class Size, class T>
    void fill_n(OutIter first, Size n, const T& value);

    which would require that T is derived from the third argument in a call,
    and that's possible because 'nullptr' has a distinct type. But there is
    a catch: binding an r-value to a const reference requires copy semantics
    to be defined for the type T, and in the proposal 'decltype(nullptr)' is
    such that no additional objects with that type can be created. 8.5.3 is
    the relevant section of the Standard.

    Perhaps along with 'nullptr' proposal, they will fix (relax) the
    requirement that a copy has to be _creatable_ even in the case when no
    copy is actually made...

    A good topic for comp.std.c++ (but I've not been following that newsgroup
    closely).

    Victor
    Victor Bazarov, Aug 6, 2004
    #2
    1. Advertising

  3. Victor Bazarov wrote:
    > red floyd wrote:
    >
    >> I got an error by using std::fill to set an array of pointers to 0.
    >>
    >> e.g.:
    >>
    >> class XXX;
    >> XXX* v[30];
    >>
    >> std::fill(v, v+30, 0); // <-- ERROR -- cant' match template type
    >>
    >> I have to either explicitly instantiate std::fill<> or cast 0 to XXX*.
    >> I've been using th latter:
    >>
    >> std::fill(v, v+30, static_cast<XXX*>(0));

    >
    >
    > You could use a C-style cast, it basically means the same
    >
    > std::fill(v, v+30, (XXX*)0);
    >
    >> I understand the issue, that template instantiation processing is
    >> interpreting the 0 as an integer rather than a pointer value (and thus
    >> I have to help it along with the cast). Is there any other workaround
    >> for this?

    >
    >
    > If there is, I don't know it.
    >
    > > Will the proposed "nullptr" be handled properly in this sort

    >
    >> of case?


    Yes. I know better now.

    > It's a good question. The function template std::fill is specified as
    >
    > template<class FwdIter, class T>
    > void fill(FwdIter first, FwdIter last, const T& value);
    >
    > or
    >
    > template<class OutIter, class Size, class T>
    > void fill_n(OutIter first, Size n, const T& value);
    >
    > which would require that T is derived from the third argument in a call,
    > and that's possible because 'nullptr' has a distinct type. But there is
    > a catch: binding an r-value to a const reference requires copy semantics
    > to be defined for the type T, and in the proposal 'decltype(nullptr)' is
    > such that no additional objects with that type can be created. 8.5.3 is
    > the relevant section of the Standard.


    I just read the second revision of the proposal (duh!) and they changed
    the requirement. Now it allows variables of that type created, so there
    will be no problem with copying of 'nullptr' if necessary. That takes
    care of the 'const T&' issue, and the answer to your question is "yes".

    You can see the second revision of the proposal here:
    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1601.pdf

    Victor
    Victor Bazarov, Aug 6, 2004
    #3
  4. red floyd

    red floyd Guest

    red floyd, Aug 6, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anton
    Replies:
    1
    Views:
    368
    Peter van Merkerk
    Aug 6, 2003
  2. Replies:
    1
    Views:
    292
    Alf P. Steinbach
    Oct 16, 2006
  3. Replies:
    7
    Views:
    553
    Pete Becker
    Jan 25, 2008
  4. Gennaro Prota
    Replies:
    1
    Views:
    267
  5. Sebastian Mach
    Replies:
    5
    Views:
    311
Loading...

Share This Page