www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Are Templates usefull in D?

reply Matthias Becker <Matthias_member pathlink.com> writes:
Isn't D too inconsitent? I'm used to use templates to generate code for
everything the fullfills certain criterias. Normaly I can think of these
criterias on my own, e.g. the object has to be asignable. In D you can't do
that. A lot of behavior is predefined in the language but has different meanings
in different situation. In template-code you can never know, what actualy is
happening. Things are magicaly allowed but don't do any usefull thing. You find
a lot of behavior like that in D.
On very simple examples it's obvious but with more complex structures you soon
will get totaly confused.

Eigther the language has to change a lot to be much more conistent or you should
ban templates.
You already baned multiple inheritance. I never understood people that find MI
complex or hard to understand. But template code in D is complicated.
Aug 09 2004
next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
Matthias Becker wrote:


 Isn't D too inconsitent? I'm used to use templates to generate code for
 everything the fullfills certain criterias. Normaly I can think of these
 criterias on my own, e.g. the object has to be asignable. In D you can't
 do that. A lot of behavior is predefined in the language but has different
 meanings in different situation. In template-code you can never know, what
 actualy is happening. Things are magicaly allowed but don't do any usefull
 thing. You find a lot of behavior like that in D.
 On very simple examples it's obvious but with more complex structures you
 soon will get totaly confused.
 
 Eigther the language has to change a lot to be much more conistent or you
 should ban templates.
 You already baned multiple inheritance. I never understood people that
 find MI complex or hard to understand. But template code in D is
 complicated.


Do you have some examples in mind?
In general one problem with writing generic code for different types is that
different types have different semantics (eg - structs vs classes) so it is
natural that the template code has to be careful. One nice thing about

template parameter list, which gives the template writer a consistent way
of expressing requirements.
Aug 09 2004
prev sibling next sibling parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Matthias Becker wrote:

 Isn't D too inconsitent? I'm used to use templates to generate code for
 everything the fullfills certain criterias. Normaly I can think of these
 criterias on my own, e.g. the object has to be asignable. In D you can't do
 that. A lot of behavior is predefined in the language but has different
meanings
 in different situation. In template-code you can never know, what actualy is
 happening. Things are magicaly allowed but don't do any usefull thing. You find
 a lot of behavior like that in D.
 On very simple examples it's obvious but with more complex structures you soon
 will get totaly confused.


In order for the language to become more consistent, you need to address
the inconsistencies one at a time.  It might truly be an inconsistency
or it might be a misunderstanding.  To simply say there are
inconsistencies isn't enough to get them fixed.  After all, Walter may
fix a dozen inconsistencies, but if it isn't the one you are concerned
about then you will still claim that none of the inconsistencies are
fixed.

Just enumerate them one at a time with examples of why they are
inconsistent, and how you expected them to behave.


 
 Eigther the language has to change a lot to be much more conistent or you
should
 ban templates.
 You already baned multiple inheritance. I never understood people that find MI
 complex or hard to understand. But template code in D is complicated.


RE MI:

The major problem with MI was not it being hard to understand, but when
you have a "diamond" problem, which destructor is called in what order.
The "diamond" problem is where you are doing MI and two or more of your
superclasses have the same base class.  This is a documented problem in
C++.  Now if these classes are nothing but pure virtual base classes
(AKA interfaces) there is no problem to begin with.  So that is the path
that is taken in most modern languages now.
Aug 09 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
The major problem with MI was not it being hard to understand, but when
you have a "diamond" problem, which destructor is called in what order.
The "diamond" problem is where you are doing MI and two or more of your
superclasses have the same base class.  This is a documented problem in
C++.  Now if these classes are nothing but pure virtual base classes
(AKA interfaces) there is no problem to begin with.  So that is the path
that is taken in most modern languages now.


a) How often do diamond structures occure in realty
b) Eiffel doesn't have problems with diamond structures. In C++ you can avoid
problems with virtual base classes, but than you have to know about the whole
inheritece structer
Aug 09 2004
parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Matthias Becker wrote:


The major problem with MI was not it being hard to understand, but when
you have a "diamond" problem, which destructor is called in what order.
The "diamond" problem is where you are doing MI and two or more of your
superclasses have the same base class.  This is a documented problem in
C++.  Now if these classes are nothing but pure virtual base classes
(AKA interfaces) there is no problem to begin with.  So that is the path
that is taken in most modern languages now.


 
 
 a) How often do diamond structures occure in realty
 b) Eiffel doesn't have problems with diamond structures. In C++ you can avoid
 problems with virtual base classes, but than you have to know about the whole
 inheritece structer


The original C++ io system is based on the diamond structure, and the
virtual destructors is the work around for it.  The other name for it is
Fragile Base Class problem.  Anyway, Eiffel has language protection from
these things, though I am not sure what they are.
Aug 09 2004
parent Sean Kelly <sean f4.ca> writes:
In article <cf8i4v$tkb$2 digitaldaemon.com>, Berin Loritsch says...

The original C++ io system is based on the diamond structure, and the
virtual destructors is the work around for it.


Yup.  My stream rewrite follows a similar design to the C++ version and it took
some doing to overcome the lack of MI.  But the fact that it can be overcome
implies that MI is not necessary in D, which I consider a good thing.


Sean
Aug 09 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:cf7l18$hlu$1 digitaldaemon.com...

 Isn't D too inconsitent? I'm used to use templates to generate code for
 everything the fullfills certain criterias. Normaly I can think of these
 criterias on my own, e.g. the object has to be asignable. In D you can't


do

 that. A lot of behavior is predefined in the language but has different


meanings

 in different situation. In template-code you can never know, what actualy


is

 happening. Things are magicaly allowed but don't do any usefull thing. You


find

 a lot of behavior like that in D.
 On very simple examples it's obvious but with more complex structures you


soon

 will get totaly confused.


I'm guessing that most of the problem you're experiencing comes from trying
to handle both structs and classes with the same generic code. But structs,
being value types, and classes, being reference types, behave in
fundamentally different ways. Trying to have the same generic template
handle both is probably going to have problems. It's probably best to do a
specialization for class types:

    template foo(T : Object) { ... } // for reference semantics
    template foo(T) { ... } // for value semantics
Aug 09 2004