December 18, 2009
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
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
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
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
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
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
== 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
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
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
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 6 7 8
Top | Discussion index | About this forum | D home