Re: [boost] smart ptr changes

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-20 16:29:33

Greg Colvin wrote:

> At this point I don't care what the syntax is, or whether it
> is a specialization or an overload or something invented just
> for the purpose.  But there has to be some way for users to
> replace performance-critical components of the standard
> library like swap.

        Well, there doesn't necessarily _have_ to be a way,
a fact which can be demonstrated merely by observing
that at present there isn't :-)

        If you mean: 'there is a deficiency in the C++
Standard' you'd like to see corrected, then doesn't
it make sense to _analyse_ possible solutions?

        In particular, a general solution to a 
class of problems is likely to be seen as
better than a hack for a particular problem.
For example, allowing function templates to be 
partially specialised may solve the problem (not sure),
and it may also solve a lot of related problems,
which surely arise in client libraries as well,
for the same reasons.

        So if you really want a solution,
and think partial specialisation of function
templates might be a solution, then you need
to be prepared to analyse the requirements.

        I contend that 

        a) the technology for such specialisations
already exists in C++ compilers, at least to 
some extent

        b) the only issue of any significance
is syntax

        c) there is an obvious syntax, with
an obvious problem: the obvious syntax is:

        template<class X> 
        template<class U=X, class V=X>
        void f(U,V)

and the obvious problem is that by extension the
correct form for a full specialisation is:

        template<>
        template<class U=int, class V=long>
        void f(U,V)

which does not agree with the current <stupid> syntax:

        void f(int,long);

which is, in fact, the correct syntax
for an overload NOT A #$%^&*<g> specialisation.

The obvious fix is to break some existing
code using full specialisations of function templates.
Not all of it will be broken -- overloading will provide
similar semantics in many cases I guess.

Sometimes, if you want to do something right,
you have to accept the need to correct past errors.

Something as important as full generality for
templates shouldn't be plauged with compatibility
hacks which are likely to cause more problems
for generic meta-programming than the problematic benefits
of attempting to save badly structured legacy code.

I note that _exactly_ the same form could work for classes,
but it isn't necessary since classes can't be overloaded:
you can write

        template <class X>
        class F<X,X>

and that can be expanded to 

        template <class X>
        template <class U=X, class V=X>
        class F

and vice versa, since, because there is only one
template F for a class, the order of arguments in

        F<X,X>

is enough to determine the partial specialisation
binding functor

        U-->X
        V-->X

You CANNOT do that for functions, since:

        void f<X,X>(X,X)

STILL isn't enough to determine which template 'f'
you mean, given two templates with signatures

        f(U,V)
        f(V,U)

Unlike overloads, it matters: you really must say
which template you are specialising.

I note that two step resolution is required:
one first decides which template to apply,
THEN decided which specialisation to use to
generate the instance. The first step 
is already done for functions, the second is the
same as is already done for classes.

Upgrading compilers to do both is non-trivial,
but it can't be that hard either.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net