www.digitalmars.com/template.html

Notice how short it is <g>. Ok, what did I miss?

"Walter" <walter@digitalmars.com> wrote in message news:ajvgsb$6gt$1@digitaldaemon.com...
> www.digitalmars.com/template.html
> Notice how short it is <g>. Ok, what did I miss?

First thing I missed was the right url <sigh>

www.digitalmars.com/d/template.html

Looks pretty complete for my needs (although I'm no template expert). Simple yet powerful. Just a few questions.

"
template Foo(T);
 in Foo(int); // T is deduced to be int
 in Foo(char*); // T is deduced to be char*
"
I don't understand this where is the InstanceIdentifier? Or is this some
type of overloaded function call?

I guess this is a stupid question, but will it support operator overloading?

"Walter" <walter@digitalmars.com> wrote in message news:ajvgsb$6gt$1@digitaldaemon.com...
> www.digitalmars.com/template.html
>
> Notice how short it is <g>. Ok, what did I miss?

Walter wrote:

> "Walter" <walter@digitalmars.com> wrote in message news:ajvgsb$6gt$1@digitaldaemon.com...
> > www.digitalmars.com/template.html
> > Notice how short it is <g>. Ok, what did I miss?
>
> First thing I missed was the right url <sigh>
>
> www.digitalmars.com/d/template.html

max() and min() were presented to me as a classic problem that C++
templates were trying to solve.  The beauty was that there only needed
to be one declaration, and all types automatically got a max()
function.  It was a substitute for C's template solution.  I don't see
how D templates can do max and min, unless you explicitly instantiate
them:
    in Max(int) maxint; val3 = maxint.max(val1,val2);
That seems like an ugly solution to me, especially since (as I
understand it), we can't use the same instantiation name for multiple
different instantiations.  If we're going to have to have a "maxint"
template instantiation that's separate from a "maxfloat" and all the
others, we might as well just define functions and save ourselves 4
characters of typing when we call it.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Walter wrote:

> "Walter" <walter@digitalmars.com> wrote in message news:ajvgsb$6gt$1@digitaldaemon.com...
> > www.digitalmars.com/template.html
> > Notice how short it is <g>. Ok, what did I miss?
>
> First thing I missed was the right url <sigh>
>
> www.digitalmars.com/d/template.html

In the "Argument Deduction" section,  I don't understand the Bar(D, D : D[]) example.  Does this mean that you have only one template parameter, "D", and you have to specify it in 2 different ways?  If not, then what does it mean?

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

That sounds more like a functional template then a class template. Parhaps D needs that as well?

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D63793A.93407771@deming-os.org...
> Walter wrote:
>
> > "Walter" <walter@digitalmars.com> wrote in message news:ajvgsb$6gt$1@digitaldaemon.com...
> > > www.digitalmars.com/template.html
> > > Notice how short it is <g>. Ok, what did I miss?
> >
> > First thing I missed was the right url <sigh>
> >
> > www.digitalmars.com/d/template.html
>
> max() and min() were presented to me as a classic problem that C++
> templates were trying to solve.  The beauty was that there only needed
> to be one declaration, and all types automatically got a max()
> function.  It was a substitute for C's template solution.  I don't see
> how D templates can do max and min, unless you explicitly instantiate
> them:
>     in Max(int) maxint; val3 = maxint.max(val1,val2);
> That seems like an ugly solution to me, especially since (as I
> understand it), we can't use the same instantiation name for multiple
> different instantiations.  If we're going to have to have a "maxint"
> template instantiation that's separate from a "maxfloat" and all the
> others, we might as well just define functions and save ourselves 4
> characters of typing when we call it.
>
> --
> The Villagers are Online! http://villagersonline.com
>
> .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
> .[ (a version.of(English).(precise.more)) is(possible) ]
> ?[ you want.to(help(develop(it))) ]
>
>

1. I would prefer something other than 'in' for 'instantiation'.  I realize that 'instance' might be annoying to type, but I will never be able to look at 'in' and see anything except 'the opposite of out'.  I could go with 'inst', which contains enough of the word to suggest 'instance' to me.  (I have similar problems with the standard C++ STL notation of InIt for an Input Iterator -- it just looks like an initializer to me...)

2. How do I make two variables of type Foo(int)?  According to the documentation, this appears to be explicitly disallowed -- "Multiple instantiations of a TemplateDeclaration with the same TemplateParameterList all will refer to the same instantiation."  If I make a RedBlackTree(T), and then find myself needing two separate trees that both hold char[]s, how can I do that?  I *could* typedef two different names for char[]s and make separate instances that way, but that just obscures the issue.  Readers of the code then have to go look up my typedef to find out that it is just a char[] with no additional functionality.

3. It might be useful to have some way to say that some template parameters are "like" or "derived from" other template parameters:

template Cage(Base, Derived like Base) {/*whatever*/}

Then at instantiation:

inst Cage(Bird, Cockateel);    // OK, assuming Cockateel derives from Bird
inst Cage(Bird, Bird);         // OK
inst Cage(Bird, Collie);       // Error - Collie does not derive from Bird
inst Cage(Bird, Animal);       // Error - inheritance order is backwards

I'm not sure how useful this is in practice.  I know Eiffel has a similar system, and Bertrand Meyer gets really excited about it, but I was never certain that I saw the benefit of this over using Base*s and letting vtables handle it.

4. I would really like constrained genericity.  Similar to the above, but when you say a parameter is "like" some base class, the base class doesn't need to be another parameter to the template.

template Calculator(T like NUMERIC) {/*whatever*/}

In this case, NUMERIC is basically an interface.  The standard argument against this is that if someone tries to instantiate the template with a class that is not NUMERIC, something will fail when Calculator tries to use one of the NUMERIC members.  But it is possible (even if unlikely) that a non-NUMERIC class could accidentally implement enough of NUMERIC to let it work, but not work the way Calculator expects.  Calculator is a bad example of this, since anyone providing NUMERIC-style members probably is doing numerical work -- but for other templates and other interfaces, the issue is not as clear.  The other benefit is self-documentation.  By placing it in the code, the developer makes it clear what he/she is requiring for the template parameter.  It becomes part of the contract.

I have no particular attachment to the word "like" in either of the above points.  It just happened to be the first thing I thought of.  "implements" might not be a bad choice, although it is rather wordy ( T implements NUMERIC ). "isa" or "is_a" might work too ( T isa NUMERIC ).

Mac

Mac Reiter wrote:
> 1. I would prefer something other than 'in' for 'instantiation'.  I realize that
> 'instance' might be annoying to type, but I will never be able to look at 'in'
> and see anything except 'the opposite of out'.  I could go with 'inst', which
> contains enough of the word to suggest 'instance' to me.  (I have similar
> problems with the standard C++ STL notation of InIt for an Input Iterator -- it
> just looks like an initializer to me...)

Hear, Hear

> 2. How do I make two variables of type Foo(int)?  According to the
> documentation, this appears to be explicitly disallowed -- "Multiple
> instantiations of a TemplateDeclaration with the same TemplateParameterList all
> will refer to the same instantiation."  If I make a RedBlackTree(T), and then
> find myself needing two separate trees that both hold char[]s, how can I do
> that?  I *could* typedef two different names for char[]s and make separate
> instances that way, but that just obscures the issue.  Readers of the code then
> have to go look up my typedef to find out that it is just a char[] with no
> additional functionality.

As I understand it, the code would be
    in RedBlackTree(char[]) RedBlackTree_of_char_array;
    RedBlackTree_of_char_array var1;
    RedBlackTree_of_char_array var2;

Mac Reiter <Mac_member@pathlink.com> wrote:
> 1. I would prefer something other than 'in' for 'instantiation'.  I realize that 'instance' might be annoying to type, but I will never be able to look at 'in' and see anything except 'the opposite of out'.  I could go with 'inst', which contains enough of the word to suggest 'instance' to me.  (I have similar problems with the standard C++ STL notation of InIt for an Input Iterator -- it

Why not use the keyword "typedef" ?
This is not what is doing ? You are creating a new type based on a
template ?

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D63793A.93407771@deming-os.org...
> max() and min() were presented to me as a classic problem that C++
> templates were trying to solve.  The beauty was that there only needed
> to be one declaration, and all types automatically got a max()
> function.  It was a substitute for C's template solution.  I don't see
> how D templates can do max and min, unless you explicitly instantiate
> them:
>     in Max(int) maxint; val3 = maxint.max(val1,val2);
> That seems like an ugly solution to me, especially since (as I
> understand it), we can't use the same instantiation name for multiple
> different instantiations.  If we're going to have to have a "maxint"
> template instantiation that's separate from a "maxfloat" and all the
> others, we might as well just define functions and save ourselves 4
> characters of typing when we call it.

You are correct that D does not do C++'s implicit instantiation, in D, instantiation must be explicit. The reason is I have come to believe that much of the complexity and problems with C++ templates comes from implicit instantiation - this is complexity in both specification and use. In practice, I find that many programs use typedef's to try and reduce the complexity and approximate explicit instantiation.