By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,194 Members | 818 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,194 IT Pros & Developers. It's quick & easy.

std::fill and containers of pointers

P: n/a

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?

Jul 22 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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
Jul 22 '05 #2

P: n/a
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/wg...2004/n1601.pdf

Victor
Jul 22 '05 #3

P: n/a
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
Jul 22 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.