View mode: basic / threaded / horizontal-split · Log in · Help
December 18, 2009
What's wrong with D's templates?
In a reddit reply: "The concept of templates in D is exactly the same as 
in C++. There are minor technical differences, syntactic differences, 
but it is essentially the same thing. I think that's understandable 
since Digital Mars had a C++ compiler."

http://www.reddit.com/r/programming/comments/af511/ada_programming_generics/c0hcb04?context=3

I have never touched ada but I doubt it is really has that much that 
can't be done in D. I thought most (if not all) the problems with C++ 
were absent in D as this summary of the most common ones points out 
http://www.digitalmars.com/d/2.0/templates-revisited.html.

Your thoughts?
December 18, 2009
Re: What's wrong with D's templates?
On 18/12/2009 02:49, Tim Matthews wrote:
> In a reddit reply: "The concept of templates in D is exactly the same as
> in C++. There are minor technical differences, syntactic differences,
> but it is essentially the same thing. I think that's understandable
> since Digital Mars had a C++ compiler."
>
> http://www.reddit.com/r/programming/comments/af511/ada_programming_generics/c0hcb04?context=3
>
>
> I have never touched ada but I doubt it is really has that much that
> can't be done in D. I thought most (if not all) the problems with C++
> were absent in D as this summary of the most common ones points out
> http://www.digitalmars.com/d/2.0/templates-revisited.html.
>
> Your thoughts?

I don't know Ada but I do agree with that reddit reply about c++ and D 
templates. D provides a better implementation of the exact same design, 
so it does fix many minor issues (implementation bugs). An example of 
this is the foo<bar<Class>> construct that doesn't work because of the 
">>" operator.
However, using the same design obviously doesn't solve any of the deeper 
design problems and this design has many of those. An example of that is 
that templates are compiled as part of the client code. This forces a 
library writer to provide the source code (which might not be acceptable 
in commercial circumstances) but even more frustrating is the fact that 
template compilation bugs will also happen at the client.

There's a whole range of designs for this and related issues and IMO the 
C++ design is by far the worst of them all. not to mention the fact that 
it isn't an orthogonal design (like many other "features" in c++). I'd 
much prefer a true generics design to be separated from compile-time 
execution of code with e.g. CTFE or AST macros, or other designs.
December 18, 2009
Re: What's wrong with D's templates?
Fri, 18 Dec 2009 10:50:52 +0200, Yigal Chripun wrote:

> There's a whole range of designs for this and related issues and IMO the
> C++ design is by far the worst of them all. not to mention the fact that
> it isn't an orthogonal design (like many other "features" in c++). I'd
> much prefer a true generics design to be separated from compile-time
> execution of code with e.g. CTFE or AST macros, or other designs.

There won't be AST macros in D2, yet. Maybe in D3. You forgot to mention 
executable bloat inherent to the template design.
December 18, 2009
Re: What's wrong with D's templates?
Fri, 18 Dec 2009 10:50:52 +0200, Yigal Chripun wrote:

> There's a whole range of designs for this and related issues and IMO the
> C++ design is by far the worst of them all. not to mention the fact that
> it isn't an orthogonal design (like many other "features" in c++). I'd
> much prefer a true generics design to be separated from compile-time
> execution of code with e.g. CTFE or AST macros, or other designs.

There won't be AST macros in D2, yet. Maybe in D3. You forgot to mention 
executable bloat inherent to the template design.
December 18, 2009
Re: What's wrong with D's templates?
Yigal Chripun:
> There's a whole range of designs for this and related issues and IMO the 
> C++ design is by far the worst of them all.

My creativity is probably limited, so I think that while C++/D templates have some well known problems, they are better than the strategies used by Java, C#, Ada, Haskell, Object-C, Scala, and Delphi to define generic code. They produce efficient code when you don't have a virtual machine at run time, and allow to write STL-like algorithms. If you need less performance and/or you accept worse algorithms/collections then I agree there are designs simpler to use and cleaner than C++/D templates.
If you are able to design something better I'd like to know about your ideas.

Bye,
bearophile
December 18, 2009
Re: What's wrong with D's templates?
Fri, 18 Dec 2009 08:53:33 -0500, bearophile wrote:

> Yigal Chripun:
>> There's a whole range of designs for this and related issues and IMO
>> the C++ design is by far the worst of them all.
> 
> My creativity is probably limited, so I think that while C++/D templates
> have some well known problems, they are better than the strategies used
> by Java, C#, Ada, Haskell, Object-C, Scala, and Delphi to define generic
> code. They produce efficient code when you don't have a virtual machine
> at run time, and allow to write STL-like algorithms. If you need less
> performance and/or you accept worse algorithms/collections then I agree
> there are designs simpler to use and cleaner than C++/D templates. If
> you are able to design something better I'd like to know about your
> ideas.

Templates are good for parameterizing algorithms and data structures. 
They begin to have problems when they are used extensively for meta-
programming. For instance the lack of lazy evalution in the type world 
forces the language to either have 'static if' or you need to add 
indirection via dummy members. The language is basically purely 
functional, but it's several orders of magnitude more verbose than say 
Haskell.

CTFE solves some of the problems, but as a result the system becomes 
really unorthogonal. Macros on the other hand solve the problem of clean 
meta-programmming but are not the best way to describe generic types.

Java, C#, Scala, Haskell et al only support types as template parameters. 
In addition Java erases this type info on runtime so you get even worse 
performance than on C#/.NET.
December 18, 2009
Re: What's wrong with D's templates?
== Quote from Yigal Chripun (yigal100@gmail.com)'s article
> I don't know Ada but I do agree with that reddit reply about c++ and D
> templates. D provides a better implementation of the exact same design,
> so it does fix many minor issues (implementation bugs).

I think variadics, static if and alias parameters qualify more as a "better
design" than fixing "minor issues".

> An example of
> this is the foo<bar<Class>> construct that doesn't work because of the
> ">>" operator.
> However, using the same design obviously doesn't solve any of the deeper
> design problems and this design has many of those. An example of that is
> that templates are compiled as part of the client code. This forces a
> library writer to provide the source code (which might not be acceptable
> in commercial circumstances)

There's always obfuscation.  I think people underestimate this.  If you strip out
all comments and meaningful names (I won't mention mangling whitespace because
that's programmatically reversible), trade secrets are reasonably well protected.
Remember, people can always disassemble your library.  I don't see obfuscated D
code with names and comments stripped as being **that** much easier to understand
than a disassembly.

> but even more frustrating is the fact that
> template compilation bugs will also happen at the client.
> There's a whole range of designs for this and related issues and IMO the
> C++ design is by far the worst of them all. not to mention the fact that
> it isn't an orthogonal design (like many other "features" in c++). I'd
> much prefer a true generics design to be separated from compile-time
> execution of code with e.g. CTFE or AST macros, or other designs.

Since generics work by basically casting stuff to Object (possibly boxing it) and
casting back, I wonder if it would be easy to implement generics on top of
templates through a minimal wrapper.  The main uses for this would be executable
bloat (for those that insist that this matters in practice) and allowing virtual
functions where templates can't be virtual.
December 18, 2009
Re: What's wrong with D's templates?
Hello Yigal,

> On 18/12/2009 02:49, Tim Matthews wrote:
> 
>> In a reddit reply: "The concept of templates in D is exactly the same
>> as in C++. There are minor technical differences, syntactic
>> differences, but it is essentially the same thing. I think that's
>> understandable since Digital Mars had a C++ compiler."
>> 
>> http://www.reddit.com/r/programming/comments/af511/ada_programming_ge
>> nerics/c0hcb04?context=3
>> 
>> I have never touched ada but I doubt it is really has that much that
>> can't be done in D. I thought most (if not all) the problems with C++
>> were absent in D as this summary of the most common ones points out
>> http://www.digitalmars.com/d/2.0/templates-revisited.html.
>> 
>> Your thoughts?
>> 
> I don't know Ada but I do agree with that reddit reply about c++ and D
> templates. D provides a better implementation of the exact same
> design,
> so it does fix many minor issues (implementation bugs). An example of
> this is the foo<bar<Class>> construct that doesn't work because of the
> ">>" operator.
> However, using the same design obviously doesn't solve any of the
> deeper
> design problems and this design has many of those. An example of that
> is
> that templates are compiled as part of the client code. This forces a
> library writer to provide the source code (which might not be
> acceptable
> in commercial circumstances) but even more frustrating is the fact
> that
> template compilation bugs will also happen at the client.
> There's a whole range of designs for this and related issues and IMO
> the C++ design is by far the worst of them all. not to mention the
> fact that it isn't an orthogonal design (like many other "features" in
> c++). I'd much prefer a true generics design to be separated from
> compile-time execution of code with e.g. CTFE or AST macros, or other
> designs.
> 

If D were to switch to true generics, I for one would immediately start looking 
for ways to force it all back into compile time. I think that this would 
amount to massive use of CTFE and string mixins.

One of the things I *like* about template is that it does everything at compile 
time.

That said, I wouldn't be bothered by optional generics or some kind of compiled 
template where a lib writer can ship a binary object (JVM code?) that does 
the template instantiation at compile time without the text source. (The 
first I'd rarely use and the second would just be an obfuscation tool, but 
then from that standpoint all compilers are)
December 18, 2009
Re: What's wrong with D's templates?
Hello dsimcha,

> Since generics work by basically casting stuff to Object (possibly
> boxing it) and casting back, I wonder if it would be easy to implement
> generics on top of templates through a minimal wrapper.

How about this?

interface Foo { int I(int); }

class CFoo(T) : Foo
{
   T t;
   int I(int i){ return t.I(i); }
}

class CollectionOfFoos_Base(T)
{
   protected:
       Foo opIndex_(int i){ ... }
       Foo opIndex_(int i, Foo f){ ... }
}
class CollectionOfFoos(T) : CollectionOfFoos_Base
{
   public
       T opIndex(int i){ return (cast(CFoo!(T))opIndex(i)).t; }
       T opIndex(int i, Foo f)
       {
          auto b = new CFoo!(T);
          b.t = f;
          return (cast(CFoo!(T))opIndex(i,b)).t;
       }
}

Add opDispatch and it might get even better.
December 18, 2009
Re: What's wrong with D's templates?
On 18/12/2009 16:02, retard wrote:
> Fri, 18 Dec 2009 08:53:33 -0500, bearophile wrote:
>
>> Yigal Chripun:
>>> There's a whole range of designs for this and related issues and IMO
>>> the C++ design is by far the worst of them all.
>>
>> My creativity is probably limited, so I think that while C++/D templates
>> have some well known problems, they are better than the strategies used
>> by Java, C#, Ada, Haskell, Object-C, Scala, and Delphi to define generic
>> code. They produce efficient code when you don't have a virtual machine
>> at run time, and allow to write STL-like algorithms. If you need less
>> performance and/or you accept worse algorithms/collections then I agree
>> there are designs simpler to use and cleaner than C++/D templates. If
>> you are able to design something better I'd like to know about your
>> ideas.
>
> Templates are good for parameterizing algorithms and data structures.
> They begin to have problems when they are used extensively for meta-
> programming. For instance the lack of lazy evalution in the type world
> forces the language to either have 'static if' or you need to add
> indirection via dummy members. The language is basically purely
> functional, but it's several orders of magnitude more verbose than say
> Haskell.
>
> CTFE solves some of the problems, but as a result the system becomes
> really unorthogonal. Macros on the other hand solve the problem of clean
> meta-programmming but are not the best way to describe generic types.
>
> Java, C#, Scala, Haskell et al only support types as template parameters.
> In addition Java erases this type info on runtime so you get even worse
> performance than on C#/.NET.

To bearophile:
you're mistaken on all counts - generics (when properly implemented) 
will provide the same performance as templates. Also, a VM is completely 
orthogonal to this. Ada ain't VM based, is it?

to retard:
different problems should be solved with different tools. Macros should 
be used for meta-programming and generics for type-parameters. they 
don't exclude each other. E.g. Nemerle has an awesome macro system yet 
it also has .net generics too.
As the saying goes -"when all you got is a hammer everything looks like 
a nail" which is a very bad situation to be in.
templates are that hammer while a much better approach is to go and by a 
toolbox with appropriate tools for your problem set.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home