What's wrong with D's templates?

Yigal Chripun yigal100 at gmail.com
Fri Dec 18 14:51:39 PST 2009


On 18/12/2009 17:34, dsimcha wrote:
> == Quote from Yigal Chripun (yigal100 at 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".

actually they qualify as - "even worse design". duplicating the syntax 
like that is butt ugly.

>
>> 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.

this is the least of the problems of that design. The biggest problem 
IMO is the conflation of user-code and library code.

>
>> 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.

generics have nothing to do with casting and/or boxing (except Java's 
poor excuse of a design/implementation).
.Net generics for example work by creating an instantiation for each 
value type (same as c++ templates) and one instantiation for all 
reference types since at the binary level all reference types are simply 
addresses. C++ can't do this since it has no separation between 
"structs" and "classes".
there is no casting involved since the full type info is stored.
so a Foo<Bar> will be typed as Foo<Bar> at the binary level as well and 
you can use APIs to query this at runtime.

in .Net it's part of the IL, in D this can be done by mangling the type 
info into the symbol's name.





More information about the Digitalmars-d mailing list