std::fill and containers of pointers

[red floyd]

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?

[Victor Bazarov]

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(nullp tr)' 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]

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(nullp tr)' 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/wg...2004/n1601.pdf

Victor

[red floyd]

Victor Bazarov wrote:
[std::fill, 0, and nullptr discussion redacted]

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

Victor

Thanks, Victor.

red floyd