Gabriel Dos Reis wrote:
[...]
> | I suggest an Occam's razor change to template template parameters:
>
> Whether your proposed change  is an application of Occam's razor
> principle is debatable ;-)

Well, not necessarily Occam's, but a razor is certainly being applied...

Best regards,
Nicola Musatti

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau wrote in message <8ie1u4$sti$1@panix6.panix.com>...

<SNIP>

>>I like this a lot - makes things crystal-clear. So I think it would be
>>great to allow this as an alternate syntax for template template
>>parameters.
>
>I have not been able to get to all the points in this thread, so
>I'll make a guess that the intention of the above is to allow
>template template parameters where ...what?
>C's parameters are variadic?  If so, what would you do with C?
>If not, can you highlight the premise of the above?
>
>- Greg


I feel in your response the impression that so much freedom may not be
useful at first, because if you consider the "canonical" use of template
template parameters (the one presented in every book dealing with that
subject), it looks like there is no possibility to actually settle the exact
type of the template template parameter without knowing its structure, that
is, knowing at least the number of its parameters.

But as mentioned earlier in this thread, the idea is to decide only at
instantiation if a particular use is allowed or not.

Let's attempt to explain what could be done with the exposed proposal that
could not be done with the actual rules (new proposed syntax used)

template< typename K, typename T, template Cont >    // Container type here
with no further precision
struct Interesting
{
        void useVectorLike
        {
            K var;
            Cont< T > tempContainer;
            tempContainer.pushback( T( var ) );
            /* Do something particularly well suited for a vector-like
container */
            sort( tempContainer.begin(), tempContainer.end(), less<T>() );
        }

        void useMapLike( K key )
        {
            Cont< K,  T > tempContainer;
            tempContainer.insert( Cont< K, T>::value_type( key, T() ) );
            /* Do something with map-like container */
        }
};

int main()
{
    Interesting< char, string, MyRandomContainer > i1;
    i1.useVectorLike();

    Interesting< double, string, map > i2;
    i2.useMapLike( 3.5 );
};

Because an actual method will not get instantiated until actually used, the
above code should compile. This is analog to the following example with a
usual (but imaginary) container template defining a sort method, like this:

template< typename T >
class MyContainer
{
    /* All the usual stuff */
    void sort
    { /* Your favorite sort algorithm here, using operator <() */ }
};

int main
{
    MyContainer< int > c1;
    c1.sort;

    MyContainer< Unsortable > c2;
    // Cannot use sort here, because the "Unsortable" class does not support
operator <()
};

You cannot use the sort method if your base type does not fulfill some
conditions (here supporting operator <()) and any attempt will be flagged by
the compiler during instantiation.

Now, if you come back to the original exmample, the similarity should be
clear. The designer of the "Interesting" struct template does not want to
constrain too much the template template parameter, because the resulting
struct should be usable in various contexts, depending on the actual user
choice. This is what I wanted to express when saying that forcing the
declaration of the structure of the template template parameter is done at
the wrong place. It should not be done during the declaration, but only at
instantiation, where the actual structure may vary and, moreover, be chosen
by the client (not the implementor!), much the same way as I can decide to
support an operator <() or not, depending on my user needs, and not on an
arbitrary constraint imposed by the designer of the MyContainer class above.

Things become uglier yet if you compose things further, i.e. allowing a
template template parameter having itself  template template parameters
(what is allowed by the actual syntax). The actual syntax imposes a lot of
constraints on the designer, because it really must know beforehand a lot of
things about the structure of parameters of a template class he does not
know about in the first place! It will only be known with certainty when the
client decides to instantiate the template with parameters of its choice.

I agree that the "Interesting" example may look a little weird at first and
that there are probably much better ways to design something similar, but
this is not the point. One could also argue that recursive template template
parameters are not very common nowadays, but this is again irrelevant.
Generative template programming will need it sooner than you may think, for
the same reason that recursive templates were totally strange five years ago
and are routinely used today, at least by people dealing with the generative
paradigm.

Sorry again for the lengthy development, but this recursive things always
get a little complicated.

Jean-Daniel Nicolet
Software Consultant
Geneva
Switzerland


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <skkrd8kois459@news.supernews.com>,
Andrei Alexandrescu <andrewalex@hotmail.com> wrote:
>Jean-Daniel Nicolet <jdn@llinkvest.ch> wrote in message
>news:8icqhb$e5t$1@pollux.ip-plus.net...
>> template< template C >
>> class X { };
>
>I like this a lot - makes things crystal-clear. So I think it would be
>great to allow this as an alternate syntax for template template
>parameters.

I have not been able to get to all the points in this thread, so
I'll make a guess that the intention of the above is to allow
template template parameters where ...what?
C's parameters are variadic?  If so, what would you do with C?
If not, can you highlight the premise of the above?

- Greg
--
Comeau Computing, Producers of Comeau C/C++ 4.2.42 (4.2.43 BETA starting)
Try Comeau C++ online at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau <comeau@panix.com> wrote in message
news:8ie1u4$sti$1@panix6.panix.com...
> Andrei Alexandrescu <andrewalex@hotmail.com> wrote:
> >Jean-Daniel Nicolet <jdn@llinkvest.ch> wrote in message
> >news:8icqhb$e5t$1@pollux.ip-plus.net...
> >> template< template C >
> >> class X { };
> >
> >I like this a lot - makes things crystal-clear. So I think it would
be
> >great to allow this as an alternate syntax for template template
> >parameters.
>
> I have not been able to get to all the points in this thread, so
> I'll make a guess that the intention of the above is to allow
> template template parameters where ...what?

Below is an executive summary :o).

> C's parameters are variadic?  If so, what would you do with C?

This is true. Basically it allows you to use template template
parameters without the number-of-parameters constraint and syntactic
nightmare. I find both improvements *very* important.

Basically the proposed syntax can support templates with default
arguments with considerable ease. Example:

template <class, class = void> void class A1;
template <class> void class A2;
template <class, class> void class A3;
class A4;

// Proposed syntax
template <template C>
class X
{
    C<int> member_;
};

X<A1> x1;    // works, uses void for the 2nd arg
X<A2> x2;    // works
X<A3> x3;    // doesn't work, not enough args
X<A4> x4;    // doesn't work, A4 must be a template



Andrei


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Andrei Alexandrescu" <andrewalex@hotmail.com> writes:

> I suggest an Occam's razor change to template template parameters:
> ditch the whole template template syntax, and allow regular template
> parameters to bind to templates. For example:

I don't think this is a good idea. Consider the following piece of code:

template <class T, class U = T<T> > class X {};

X<X> x; // Allowed? X<X> Would be the same as X< X,X< X,X< X,... > > >, i.e.
        // an infinite type!

This will be diagnosed as an error with template template parameters,
but I think it would hit the resource limit for nested template
instantiations if this change was made. Since we have specializations,
this kind of code would allow recursive construction of types of size
only bound by the compiler resource limits.
--
 Esa Pulkkinen                        | C++ programmers do it virtually
 E-Mail:  esap@cs.tut.fi              | everywhere with class, resulting
 WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker <petebecker@acm.org> writes:
>Biju Thomas wrote:
>> Pete Becker wrote:
>> > Interesting idea. No backward compatibility problems, since no compiler
>> > currently implements template template parameters.
>>
>> I am aware of at least three compilers that claim to implement template
>> template parameters
[...]
>
>I guess I should have looked around a bit before making such a broad
>statement. Thanks for the information.

I think Pete was right anyway about "no backward compatibility
problems." IIRC, I believe that Andrei's proposed syntactic extension is
a pure extension -- it enables programs that are not currently legal,
but does not change the meaning of any currently legal program. (Caveat:
I have not spent more than two seconds thinking about it, so I may be
missing obvious counterexamples.)

If we ever did something like this, it might leave us with two ways of
doing some things -- one more complex and possibly deprecated, the other
simpler and allowing a superset of the first's functionality -- but
having two ways of doing something isn't a showstopper. We've done that
before (e.g., casts).

Nit: What we have so far is a sketch, not a proposal. I for one would be
very interested in reading a proposal, including more detailed
discussion and an analysis of possible effects on sample currently-legal
programs. Volunteers?

Herb

---
Herb Sutter (mailto:hsutter@peerdirect.com)

CTO, PeerDirect Inc. (http://www.peerdirect.com)
Chair, ANSI SQL Part 12: SQL/Replication
Editor-in-Chief, C++ Report (http://www.creport.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Pete Becker" <petebecker@acm.org> wrote in message news:394652F4.A80D603B@acm.org...
> Marcin 'Qrczak' Kowalczyk wrote:
> >
> > Mon, 12 Jun 2000 22:09:04 CST, Pete Becker <petebecker@acm.org> pisze:
> >
> > > Just as with member function pointers, the obvious way to use things
> > > that don't have exactly specified argument lists in contexts where
> > > exact signatures are required is to wrap them.
> >
> > Except that there are no template typedefs.
>
> If there were, they wouldn't help. They'd just push the problem off into
> the typedef. But there are other ways to wrap a type.

I'velong been of the opinion that this problem, along with the analogous
one for functios, should have been solved by requiring functions and
templates with default arguments to match all of their possible
signatures. I suppose it's too late to fix the current standard this
way, but perhaps it's a possibility for the next round.

Note that g++ already implements this extension for templates (even in
-ansi -pedantic, which it probably shouldn't), so there doesn't seem
to be any implementation problem.

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
   "So that's 2 T-1s and a newsfeed ... would you like clues with that?"
                                                       -- Peter Da Silva


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Esa Pulkkinen wrote:
>
> "Andrei Alexandrescu" <andrewalex@hotmail.com> writes:
>
> > I suggest an Occam's razor change to template template parameters:
> > ditch the whole template template syntax, and allow regular template
> > parameters to bind to templates. For example:
> >
> > template <class T> class A
> > {
> >     ...
> >     T<int> member;
> > };
> >
> > template <class T> class Something { ... };
> >
> > A<Something> obj;
> >
>
> I don't think this is a good idea. Consider the following piece of code:
>
> template <class T, class U = T<T> > class X {};
>
> X<X> x; // Allowed? X<X> Would be the same as X< X,X< X,X< X,... > > >, i.e.
>         // an infinite type!
>
> This will be diagnosed as an error with template template parameters,
> but I think it would hit the resource limit for nested template
> instantiations if this change was made. Since we have specializations,
> this kind of code would allow recursive construction of types of size
> only bound by the compiler resource limits.

Your example shows the same defect (IMHO) as Andrei's:
How do you define a variable of an unknown type? Neither A<Something>
nor X<X> are fully defined, i think. In both cases, the template
parameter lacks parameters which would make it a type of it's own.

Since you're not allowed (IIRC) to define the following variables:
Something s;
X  x;

Why should you be allowed to make the definitions you proposed?

If I'm right, the problem you brought up does not exist.

Regards,
Heinz

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrei Alexandrescu wrote in message ...
<SNIP>
> Come on, let's unify template template parameters with regular template
parameters!
>
>Andrei

Here is some thinking about the mechanisms implied by templates in general
and why I think the proposed idea should be rejected.

Let's start with a mathematical comparison. For me, a template is like an
equation, defined with place-holders that may be substituted at
instantiation. Thus, in C++, we have kind of three semantic levels, to which
I'll give more mathematical names to help better grasp the comparison:

Level                    Math                    C++
----------------------------------------------------

lowest level:        a value                 an object or a number

second level       a variable            a type (class or built-in)

third level            an equation         a template


In the  above comparison, we consider a number as being an instance of a
built-in type, so we make conceptually no real difference between a class
and a built-in type.

In C++, given an item belonging to level 2 or 3, it is possible to go one
level down by instantiating that item. An instantiated template gives you a
class, and an instantiated class gives back an object or a value. In the
mathematical world, the same happens through a substitution mechanism.
Considering an equation, it has associated placeholders (template
parameters) that can get substituted through "concrete" values to go down
one level. The trick is that the place holders can themselves be of one of
the three levels, i.e. it is possible to substitute a place-holder in an
equation through another equation (template template parameters). Hence,
instantiating a template inside a compiler roughly comes out as substituting
a variable within an equation an simplifying it. Thus, the template
machinery requires that the compiler has some subsitution engine within it,
of the kind of an algebra software like Mathematica. It certainly explains
why we had to wait so long for having compilers dealing correctly with
templates.

Now, when declaring a template (equation with its place-holders), the
language in its current form prescribes you to be precise about to which of
the three levels your template arguments belong. For example:

template< int size, typename T, template<class> C >
class X { };

What you are saying here is that the client wishing to instantiate your
template should provide an item of level 1 for the first place-holder (an
integer value), an item of level 2 for the second palce-holder (a class or
built-in type) and an item of level 3 for the third place-holder (a
template).

Note that for the first two, you don't have that much freedom to precise
your wishes further. Any additional constraints on the actual items supplied
to instantiate the template must be documented in text form. You have for
example no way of requiring that the type supplied for the second
place-holder should be, say, a pointer to some other type. Strangely enough,
this is not true for the third case. Besides simply saying that you require
an item of level three, you are forced to describe already at this place the
place-holders of the equation required for substitution.

This is not natural, since that equation may itself have place-holders of
equation type (the question has already arised in this newsgroup), etc., and
you may not expect of the template designer to know all the details of the
place-holders used in a place-holder used in ... etc. The immediate
consequence of it is the problem already mentioned with standard containers,
from which we cannot be sure in a portable way of how many place-holders
they have. The natural reaction is to say: we, as template designers, should
not be forced to know it in advance. Let the compiler decide when the actual
substitution is performed, in the same way as with the other two levels.
After all, if you provide a type lacking some precise feature you need in
the instantiation of some method, you will get an error at the instantiation
place, and this may vary with the precise instantiation context. It is
merely by accident that things are resolved only at instantiation time,
because, as mentioned before, you don't have any standard means to express
more stringent requirements on your place-holders (there have been already
discussion threads about this theme, as if there should be a standard way of
requiring for example that a given typename be copyable, etc.), so there is
simply no other choice.

My point is as follows: for coherence reasons, there should be no more
constraints on place-holders of the third level than on the other two
levels, hence one should not be required to explicitly mention the
place-holders of the equation that should be substituted for one of our
place-holder of the third kind. Hence, the syntax should actually be the
following for template template parameters:

template< template C >
class X { };

That is, just saying that my place-hoder is of the third level and that its
name is "C", nothing more. Being able to be more precise (like it is now
required) should already be regarded as a luxus extension, and the question
remains as if, given the more precise form where the place-holders of the
equation are explicitly mentioned, an actual item given for substitution
should be accepted, provided it has default-values for additional
place-holders. I think it should, for the already mentioned reasons:
- describing place-holders of the equation place-hoder is done at the wrong
place.
- this is only a luxus possibility when compared with the other two levels,
where there is no additional constraint mechanism, so the rejection criteria
should not be too severe.

Now back to the starting point, that is to the idea suggested by Andrei of
allowing templates to be substituted for simple typenames. It should by now
be quite evident that this would lead to a confusion between level two and
three. It is a collapsing between the two. This is a little like saying that
a variable should be regarded as an equation, but as explained at the
begining of this explanation, going down one level requires an explicit
step, i.e. instantiation.

So I definitely think that the disctinction between the three levels should
be maintained, but that the place-holder enforcement on place-holders of the
third level should be suppressed, i.e. that template template parameters
could be declared without further specifying their own parameters, like in
the above example, by simply using the reserved word "template" (level 3)
instead of "typename" (level 2). For compatibility reasons and convenience,
further specification should be allowed, provided a match is possible with
default parameter values for supplemental place-holders in the actual item
being substituted.

Thank you for being patient enough to read this lengthy argumentation, but I
hope having shed some light on that debated topic.

 Jean-Daniel Nicolet
Software Consultant
Geneva
Switzerland




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jean-Daniel Nicolet wrote:

> Here is some thinking about the mechanisms implied by templates in general
> and why I think the proposed idea should be rejected.
>
> Let's start with a mathematical comparison. For me, a template is like an
> equation, defined with place-holders that may be substituted at
> instantiation. Thus, in C++, we have kind of three semantic levels, to which
> I'll give more mathematical names to help better grasp the comparison:
>
> Level                    Math                    C++
> ----------------------------------------------------
>
> lowest level:        a value                 an object or a number
>
> second level       a variable            a type (class or built-in)
>
> third level            an equation         a template
>
> In the  above comparison, we consider a number as being an instance of a
> built-in type, so we make conceptually no real difference between a class
> and a built-in type.


the comparison with maths is not just a nice analogy. It can be made
formally
precise. The Curry-Howard Isomorphism says that programs correspond
exactly
to proofs in logic. Execution of a program corresponds to what logicians
call
Cut-Elimination. Templates correspond to all-quantification (existential
quantification corresponds to modules). There has been a lot
of work in this area in the last two decades. But plenty still to be
done ...

martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8icqhb$e5t$1@pollux.ip-plus.net>,
  "Jean-Daniel Nicolet" <jdn@llinkvest.ch> wrote:
>
> Andrei Alexandrescu wrote in message ...
> <SNIP>
> > Come on, let's unify template template parameters with regular
template
> parameters!
> >
> >Andrei
>
> Here is some thinking about the mechanisms implied by templates in
general
> and why I think the proposed idea should be rejected.
>
> Let's start with a mathematical comparison. For me, a template is like
an
> equation, defined with place-holders that may be substituted at
> instantiation. Thus, in C++, we have kind of three semantic levels, to
which
> I'll give more mathematical names to help better grasp the comparison:
>

[snip]

> Now back to the starting point, that is to the idea suggested by
Andrei of
> allowing templates to be substituted for simple typenames. It should
by now
> be quite evident that this would lead to a confusion between level two
and
> three. It is a collapsing between the two. This is a little like
saying that
> a variable should be regarded as an equation, but as explained at the
> begining of this explanation, going down one level requires an
explicit
> step, i.e. instantiation.

But surely goedel proved that this (attempt at) distinction between
levels is entirely artificial, and doomed to failure?

-------------
Mark Williams
(trying to sound like he knows what hes talking about)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Sat, 17 Jun 2000 00:57:28 CST, Jean-Daniel Nicolet <jdn@llinkvest.ch> pisze:

> My point is as follows: for coherence reasons, there should be no
> more constraints on place-holders of the third level than on the
> other two levels, hence one should not be required to explicitly
> mention the place-holders of the equation that should be substituted
> for one of our place-holder of the third kind.

IMHO it's the opposite. One already specifies an important detail on
the first level: the type of the value. One should be able to specify
constraints on the second level, similarly as is e.g. in Haskell and
Clean, where these constraints completely specify what a template
can do with that type.

I'm afraid it's too late for C++, because interfaces are to loosely
defined and too much rely on syntax.

OTOH a programmer usually needs not to know if a template has default
parameters in order to use it. The exception is passing as a template
parameter. So if it does not create problems, IMHO it should be
possible to pass it as a template parameter for any amount of default
parameters supplied.

A similar thing for function pointers is unfortunately not possible.

--
 __("<    Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/              GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jean-Daniel Nicolet wrote:
>
> Andrei Alexandrescu wrote in message ...
> <SNIP>
> > Come on, let's unify template template parameters with regular template
> parameters!
> >
> >Andrei
>
> Here is some thinking about the mechanisms implied by templates in general
> and why I think the proposed idea should be rejected.
>
> Let's start with a mathematical comparison. For me, a template is like an
> equation, defined with place-holders that may be substituted at
> instantiation. Thus, in C++, we have kind of three semantic levels, to which
> I'll give more mathematical names to help better grasp the comparison:
>
> Level                    Math                    C++
> ----------------------------------------------------
>
> lowest level:        a value                 an object or a number
>
> second level       a variable            a type (class or built-in)
>
> third level            an equation         a template
>
> In the  above comparison, we consider a number as being an instance of a
> built-in type, so we make conceptually no real difference between a class
> and a built-in type.
>
> In C++, given an item belonging to level 2 or 3, it is possible to go one
> level down by instantiating that item. An instantiated template gives you a
> class, and an instantiated class gives back an object or a value. In the
> mathematical world, the same happens through a substitution mechanism.

But instantiating a template doesn't always give you a class,
it also can give you a function.

BTW, would the following be allowed?

template<template<class X> void (*foo)(X const&), class T>
 void twice(T const& t)
{
  foo(t);
  foo(t);
}

template<class T>
 void print(T const& t)
{
  std::cout << t << std::endl;
}

template<class T>
 void validate(T const& t)
{
  if (!t) std::cout << "invalid\n";
}

void f()
{
  twice<print>(5);
  twice<print>("Hello");
  twice<validate>(5);
  twice<validate>("Hello");
}

If this is (and should be) disallowed, your proposal

> template< template C >
> class X { };

is indeed nice. Otherwise, it would have to be modified to
distinguish between classes and functions.

[...]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jean-Daniel Nicolet <jdn@llinkvest.ch> wrote in message
news:8icqhb$e5t$1@pollux.ip-plus.net...
[Occam's razor chops off the lengthy argument]

> template< template C >
> class X { };

I like this a lot - makes things crystal-clear. So I think it would be
great to allow this as an alternate syntax for template template
parameters.

[Occam's razor chops off the lengthy argument]


Andrei


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message
news:fl1z24owye.fsf@sel.cmla.ens-cachan.fr...
> Once more, I'm going to make myself not Andrei's friend ;-)

Fear not, little Andrei is everybody's friend. So I can get to
everybody's private accounts.

> "Andrei Alexandrescu" <andrewalex@hotmail.com> writes:
> | ditch the whole template template syntax, and allow regular
template
> | parameters to bind to templates. For example:
> |
> | template <class T> class A
> | {
> |     ...
> |     T<int> member;
> | };
> |
> | template <class T> class Something { ... };
> |
> | A<Something> obj;
>
> There is a technical problem: Something isn't a type name.

Right, but my point is that, within the proposed framework, it doesn't
have to be. Basically template parameters can be types or templates.
During compilation, the compiler can figure out unambiguously whether
there's a mismatch or not.

I understand there can be a source of confusion: a "typename" or
"class" can actually bind to a template. But I also think it can solve
a bunch of problems, and simplify a lot of things.


Andrei


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3943E9C7.241EE95A@acm.org>,
Pete Becker  <petebecker@acm.org> wrote:
>no compiler currently implements template template parameters.

Comeau C++ has supported TTPs since mid-Dec.   For non-technical
reasons that version's been a beta, and has been made available
to customers on some platforms, and has also been available on
the online version of Comeau C++ withstanding the intense,
but unsuccessful :), "crack-attacks" by conformance geeks.

- Greg
--
Comeau Computing, Producers of Comeau C/C++ 4.2.42 (4.2.43 BETA starting)
Try Comeau C++ online at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote:
>
> Andrei Alexandrescu wrote:
> >
> > I suggest an Occam's razor change to template template parameters:
> > ditch the whole template template syntax, and allow regular template
> > parameters to bind to templates.
>
> Interesting idea. No backward compatibility problems, since no compiler
> currently implements template template parameters.

I am aware of at least three compilers that claim to implement template
template parameters -- Borland's C++ Builder, IBM's VisualAge C++ and
the Comeau compiler. So, any claim for backward compatibility must be
based on some other criteria.

--
Biju Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

comeau@panix.com (Greg Comeau) writes:

| In article <3943E9C7.241EE95A@acm.org>,
| Pete Becker  <petebecker@acm.org> wrote:
| >no compiler currently implements template template parameters.
|
| Comeau C++ has supported TTPs since mid-Dec.

I think Pete was being joking (or sarcastic).

g++ also implements template template parameters.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Biju Thomas wrote:
>
> Pete Becker wrote:
> >
> > Andrei Alexandrescu wrote:
> > >
> > > I suggest an Occam's razor change to template template parameters:
> > > ditch the whole template template syntax, and allow regular template
> > > parameters to bind to templates.
> >
> > Interesting idea. No backward compatibility problems, since no compiler
> > currently implements template template parameters.
>
> I am aware of at least three compilers that claim to implement template
> template parameters -- Borland's C++ Builder, IBM's VisualAge C++ and
> the Comeau compiler. So, any claim for backward compatibility must be
> based on some other criteria.
>

I guess I should have looked around a bit before making such a broad
statement. Thanks for the information.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Mon, 12 Jun 2000 22:09:04 CST, Pete Becker <petebecker@acm.org> pisze:

> Just as with member function pointers, the obvious way to use things
> that don't have exactly specified argument lists in contexts where
> exact signatures are required is to wrap them.

Except that there are no template typedefs.

--
 __("<    Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/              GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marcin 'Qrczak' Kowalczyk wrote:
>
> Mon, 12 Jun 2000 22:09:04 CST, Pete Becker <petebecker@acm.org> pisze:
>
> > Just as with member function pointers, the obvious way to use things
> > that don't have exactly specified argument lists in contexts where
> > exact signatures are required is to wrap them.
>
> Except that there are no template typedefs.
>

If there were, they wouldn't help. They'd just push the problem off into
the typedef. But there are other ways to wrap a type.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]