Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2000-11-01 13:43:48

> > To clarify, you felt that this example is an argument in favour of
> > allowing std:: overloading and not allowing partial specializations?
> Not exactly. I felt that it showed that mixing specialization and
> overloading can produce confusing results, at least to someone without
> deep understanding of what's going on. Certainly, quite a few
> members were surprised.

Yes; this argument goes both ways, really. It's either specializations
(including partial ones) or overloads.

> > base b;
> > derived d;
> >
> > std::swap(b, d);
> >
> > An overload in this case cannot satisfy, "meets the
> > library requirements for the original template" - the original
> > does not work for different types.
> I think you're reading the standard too broadly. The language above
> prohibit the overload from having additional functionality (e.g.
> with different types). But in any case the language you quote isn't
> for overloading, but for specialization.

"Additional functionality" as in "letting bugs go undetected?" :-) The
language may be interpreted to allow this, granted, but is this what we

> An advantage, to be sure, and not to be understated. A big
disadvantage of
> using function template specialization is that the most obvious syntax
> use makes it order-dependent:
> template <class T> void f(T); // #1
> template <> void f<int*>(int*); // #2
> template <class T> void f(T*); // #3
> #2 specializes #1, but:
> template <class T> void f(T); // #1
> template <class T> void f(T*); // #3
> template <> void f<int*>(int*); // #2
> Now #2 specializes #3.

No, I don't think so. #2 can never specialize #3. The signature does not

template<> void f<int*>(int**); would specialize #3.

template<> void f(int*); would specialize #3 if you choose to read the
standard in this way, but the existing implementations choose to report
an ambguity in this case, and I think they are correct.

(The issue is whether an explicit specialization with deduced template
parameters that matches more than one primary template uses partial
ordering; 14.7.3/12 says that it does not, says that it does.
I'm with 14.7.3/12 on this one, 'cause it has a clear example.)

> Since the specialization for a user-defined type is
> likely to live in a header with the user-defined type declaration,
> become subject to the vagaries of #include order.

Only if you use the "feature" of not providing the template parameters
explicitly. This should be deprecated. And banned. :-)

Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at, gregod at, cpdaniel at, john at