Boost logo

Boost :

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-21 23:50:03

Jonathan H Lundquist wrote:
> > From: John Max Skaller <skaller_at_[hidden]>
> > Subject: Re: smart ptr changes
> >
> > 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);
> Why isn't the obvious syntax:
> template<>
> void f<int, long>(int, long)

        Because it fails to correctly identify
which template is being specialised in all cases.
For example:

        template<class U, class V>
        void f(U,V); //1

        template<class U, class V>
        void f(V,U); //2

        void f<int,int>(int,int){} //1 or 2??

The argument that any call:


is ambiguous anyhow is spurious. As is obvious,
now we want partial specialisations. An example
might be another file saying:

        template<class T, class V>
        void f(U,V); //1

        void f<int,int>(int,int);


Now there is no abiguity in the call, nor in the
specification that a manual specialisation exists
and should be used: the right mangled name is generated.
But the definition in the first file has failed.
Yes, you can fix it by specialising
every template in a separate file, so there is
no ambiguity. IF you have control over the file
declaring the templates. But what if it's a system
header eg Standard Library file??

The correct template-id for the specialisation of (1) is

        template<class T=int,class U=int>f(T,U)

and you should be able to disambiguate the call using that
syntax too:

        template<class T=int, class U=int>f(T,U)(1,1)

Note: when I say 'correct' syntax, anything at all will
do that is unique, parseable, and has the same information
in it: its the abstract term constructor and the corresponding
mangled name that count, not the lexemes of the
concrete syntax.

Note that mangled names ALREADY use this syntax.
They have to: scopes and overload resolution don't apply
to external names. Any implementor with half a brain
must already be using this 'syntax' in their ABI:
they have to contend with reality, not ill founded
rules made by a committee, and last I spoke to some
vendors, they agreed the whole signature is required
in the mangled name, as well as the binding.
Pity they couldn't agree in-committee to make the
language syntax reflect the facts :-(

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
Literate Programming tool Interscript

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