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
