In article <CLAExH.DE7@megatest.com> djones@megatest.com (Dave Jones) writes:
>Here's the problem that prompted this proposal: I want to abstract the
>notion of a pointer, so that I can write templates that can use
>"smart pointers" of various types.
>
>As it stands, class-arguments to templates must be fully qualified types,
>not parameterized types. Therefore a template that was abstracted over
>smart-pointer-types would need a class parameter for every kind of
>object it keeps pointers to, even those objects whose existence otherwise
>need not be known by the user.

 I agree completely and will propose this extension to
the language if no one else does first. In a box in the
working paper the Project Editor Andrew Koenig also notes that
failing to support passing of templates to templates is probably
an oversight or restriction introduced when Bjarne wasnt
100% sure of all the details.

 I believe its appropriate to add this feature,
templated typedefs, and member templates, because these
facilities will round off the template system to a coherent
whole.


>Adding a new kind of object in the
>implementation would cause the parameterization of the template to change,
>thus breaking code.
>
>What is wanted is something like this:
>
>template< class T, template Ptr >
>class containter {
> private:
>  Ptr<Link<T> > goodies; // pointer to "invasive" linked list
>           // of T's, linked by whatever kind
>           // of smart pointer the user specifies
> public:
>
>  // etc...
>};

 Exactly the idea. Now, I suspect this should read:

 template< class T, template<class T> Ptr >

so that use of "Ptr" in the template can be checked:

 .. Ptr<A,B> .. // error: wrong number of arguments
 ..
.....

 container<A, dynarray> // OK: dynarray has one argument

However, I'm baffled on what to do with template FUNCTIONS.
Note that these can be overloaded. Does one pass the whole
family of templates, or just one of the function templates?

In other words, what information must be supplied to support
checking, as for classes? Or should we just forget about
checking?
>
>The user need not know that the representation uses linked lists, and
>he need not be bothered if the implementation is changed.
>
>What say you all?

 I agree with you. I consider this feature essential.

>runtime -- bound vs. unbound variables and all that. If functions can
>take functions as parameters, why not have the same capability at compile
>time, and a allow templates to take templates as parameters? It shouldn't
>be too much trouble to add the feature, I should think.

 Agreed.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

Here's the problem that prompted this proposal: I want to abstract the
notion of a pointer, so that I can write templates that can use
"smart pointers" of various types.

As it stands, class-arguments to templates must be fully qualified types,
not parameterized types. Therefore a template that was abstracted over
smart-pointer-types would need a class parameter for every kind of
object it keeps pointers to, even those objects whose existence otherwise
need not be known by the user. Adding a new kind of object in the
implementation would cause the parameterization of the template to change,
thus breaking code.

What is wanted is something like this:

template< class T, template Ptr >
class containter {
 private:
  Ptr<Link<T> > goodies; // pointer to "invasive" linked list
           // of T's, linked by whatever kind
           // of smart pointer the user specifies
 public:

  // etc...
};

The user need not know that the representation uses linked lists, and
he need not be bothered if the implementation is changed.

What say you all? The situation is exactly equivalent to functions at
runtime -- bound vs. unbound variables and all that. If functions can
take functions as parameters, why not have the same capability at compile
time, and a allow templates to take templates as parameters? It shouldn't
be too much trouble to add the feature, I should think.

  -- Dave


BTW: I have thought of a way around the problem, but I thought I would
post the idea anyway.

  - D.