www.digitalmars.com         C & C++   DMDScript  

D - Newbie question - templates v dynamic subclass casting

reply BDP <bapalmer internode.on.net> writes:
Forgive my ignorance but I am new to D, coming from a C and Java
background. (I think Java is a much neater OO implementation than C++, and
much less bug prone as an environment to work in - it has been my preferred
environment for some time). To date, I like what I am seeing in D,
particularly the extent to which it has not adopted some of the more
esoteric elements of C++; and I like its multi-paradigm approach (in Java,
utility classes, for example, are fudges).

Now to my question: what is the better method for generic programming? Is
it templates (an idiom I find less than intuitive, but that might just be
something about me and not the idiom)? Or is dynamic casts from the Object
super class (exemplified when using the Java libraries)? 

Which model would be favoured in the development of a collections library
for D - something like the standard template library used in C++ or the
java library? I know I prefer the latter, that may be familiarity rather
than a genuine measure of conceptual power and utility.






BDP
--
www.ozpolitics.info
Sep 06 2003
next sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
I  have never used Java, can you show me a code example please ?

Charles
"BDP" <bapalmer internode.on.net> wrote in message
news:vmhklvk45qr2se3edseklvrdanpbjntne2 4ax.com...

 Forgive my ignorance but I am new to D, coming from a C and Java
 background. (I think Java is a much neater OO implementation than C++, and
 much less bug prone as an environment to work in - it has been my


preferred

 environment for some time). To date, I like what I am seeing in D,
 particularly the extent to which it has not adopted some of the more
 esoteric elements of C++; and I like its multi-paradigm approach (in Java,
 utility classes, for example, are fudges).

 Now to my question: what is the better method for generic programming? Is
 it templates (an idiom I find less than intuitive, but that might just be
 something about me and not the idiom)? Or is dynamic casts from the Object
 super class (exemplified when using the Java libraries)?

 Which model would be favoured in the development of a collections library
 for D - something like the standard template library used in C++ or the
 java library? I know I prefer the latter, that may be familiarity rather
 than a genuine measure of conceptual power and utility.






 BDP
 --
 www.ozpolitics.info
Sep 06 2003
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
BDP wrote:

 Forgive my ignorance but I am new to D, coming from a C and Java
 background. (I think Java is a much neater OO implementation than C++, and
 much less bug prone as an environment to work in - it has been my preferred
 environment for some time). To date, I like what I am seeing in D,
 particularly the extent to which it has not adopted some of the more
 esoteric elements of C++; and I like its multi-paradigm approach (in Java,
 utility classes, for example, are fudges).
 
 Now to my question: what is the better method for generic programming? Is
 it templates (an idiom I find less than intuitive, but that might just be
 something about me and not the idiom)? Or is dynamic casts from the Object
 super class (exemplified when using the Java libraries)? 


For collections, you'll want to use templates.  There are three big wins 
in doing so.

One is typesafety.  You don't have to do any casting at all if your 
container is parameterized via a template, since the whole container has 
been recompiled specifically to handle that one type.

Secondly, you can use these containers to hold things that do not 
inherit Object. (structs and primitive data types)  This obliviates the 
need for things like Java's type wrappers. (Integer, Character, and so 
forth)

Lastly, templates are resolved purely at compile time; there is no type 
checking going on at runtime.  This means that there is zero CPU 
overhead.  The container is just as fast as if you had hand coded the 
whole thing.

The downside, of course, is that templates are recompiled for every type 
they are used for, which naturally means that executable size increases.

  -- andy
Sep 06 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 One is typesafety.  You don't have to do any casting at all if your
 container is parameterized via a template, since the whole container has
 been recompiled specifically to handle that one type.

 Secondly, you can use these containers to hold things that do not
 inherit Object. (structs and primitive data types)  This obliviates the
 need for things like Java's type wrappers. (Integer, Character, and so
 forth)


Excellent point! A "Doh!' for me, please. :)


 Lastly, templates are resolved purely at compile time; there is no type
 checking going on at runtime.  This means that there is zero CPU
 overhead.  The container is just as fast as if you had hand coded the
 whole thing.

 The downside, of course, is that templates are recompiled for every type
 they are used for, which naturally means that executable size increases.


This is an important point. Walter, does DMD (and DMC++ for that matter) use
folding of generated code for templates of the same size, i.e. a POD struct
holding 4 bytes, and a 32-bit int, or for two distinct pointer types? I
believe this is a common optimisation in many C++ compilers.
Sep 06 2003
prev sibling parent reply BDP <bapalmer internode.on.net> writes:
On Sat, 06 Sep 2003 14:50:27 -0700, Andy Friesen <andy ikagames.com> wrote:



One is typesafety.  You don't have to do any casting at all if your 
container is parameterized via a template, since the whole container has 
been recompiled specifically to handle that one type.


Does D dynamically check for typesafety on a cast in the way Java does?

--
www.ozpolitics.info
Sep 06 2003
parent Ilya Minkov <minkov cs.tum.edu> writes:
BDP wrote:

 Does D dynamically check for typesafety on a cast in the way Java does?


Yes. But by relying on it you make yourself quite dependant on 
testing... And eat up your time.

BTW: Templates need not generate more bloat than collection classes, 
since templates can be usually efficiently eliminated to the extent to 
which they stay unused.

-eye
Sep 06 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Forgive my ignorance but I am new to D, coming from a C and Java
 background. (I think Java is a much neater OO implementation than C++,


Actually, I think you're wrong, but I don't need to argue the point.

What is important is that C++ is not an OO language. This is a
far-too-common misunderstanding. It is a language that supports many
programming paradigms - procedural, data abstraction, generics, OO
(polymorphic), even declarative to some extent - which is not something that
Java can claim. It is 100% OO, and if you don't like that, or it's not
approrpriate for your requirements for a particular solution, that's stiff
biccies.

D has the advantage (over Java at least) in that it is more able to support
other programming paradigms. (That's not its only advantage, of course.)


 and
 much less bug prone as an environment to work in - it has been my


preferred

 environment for some time). To date, I like what I am seeing in D,
 particularly the extent to which it has not adopted some of the more
 esoteric elements of C++; and I like its multi-paradigm approach (in Java,
 utility classes, for example, are fudges).

 Now to my question: what is the better method for generic programming? Is
 it templates (an idiom I find less than intuitive, but that might just be
 something about me and not the idiom)? Or is dynamic casts from the Object
 super class (exemplified when using the Java libraries)?


The answer would be: it depends. However, efficiency and robustness would
argue in favour of templates in almost all cases. Downcasting is an
egregious hack (I think I downcast in C++ about once a year at most.)


 Which model would be favoured in the development of a collections library
 for D - something like the standard template library used in C++ or the
 java library? I know I prefer the latter, that may be familiarity rather
 than a genuine measure of conceptual power and utility.


I think we'll end up with two types of "collection" behaviour.

The first will be based on the foreach mechanism that Walter has just
implemented. We're hoping to have an actual example of this in the registry
library in the next couple of weeks. (One reason it might take longer is
that I'm attempting to blackmail Walter into giving us static properties. It
doesn't appear to be working yet.)

I'm pretty sure the second will be templates. Most people who've expressed a
preference have come down on this side, and it (the STL) is so successful in
C++ it's hard to imagine that we won't try and leverage that in D.

There's nothing stopping anyone implementing the third type, but downcasting
is so unappealing. Even were you to write a generic Object container, and
then implement type-safe template versions on top of that. There'll still be
the question of the performance costs of downcasting. I don't know if
anyone's done any work on the speed here. If it was fast, then I would not
have any in-principal objections to it, but I suspect there will be a marked
difference in performance.

Matthew
Sep 06 2003
parent reply BDP <bapalmer internode.on.net> writes:
On Sun, 7 Sep 2003 08:02:44 +1000, "Matthew Wilson" <matthew stlsoft.org>
wrote:


I think we'll end up with two types of "collection" behaviour.

The first will be based on the foreach mechanism that Walter has just
implemented. We're hoping to have an actual example of this in the registry
library in the next couple of weeks. (One reason it might take longer is
that I'm attempting to blackmail Walter into giving us static properties. It
doesn't appear to be working yet.)

I'm pretty sure the second will be templates. Most people who've expressed a
preference have come down on this side, and it (the STL) is so successful in
C++ it's hard to imagine that we won't try and leverage that in D.

There's nothing stopping anyone implementing the third type, but downcasting
is so unappealing. Even were you to write a generic Object container, and
then implement type-safe template versions on top of that. There'll still be
the question of the performance costs of downcasting. I don't know if
anyone's done any work on the speed here. If it was fast, then I would not
have any in-principal objections to it, but I suspect there will be a marked
difference in performance.


Again, please excuse my ignorance, but if you have a template, how would
you check for things like 

	in
	{
		assert(object!=null); 
	}
	
This code snippet is valid for class references but not primitive types. 

It seems to me that you pay a price for generality in terms of strong
program type checking and contract programming.

--
www.ozpolitics.info
Sep 06 2003
next sibling parent Andy Friesen <andy ikagames.com> writes:
BDP wrote:

 Again, please excuse my ignorance, but if you have a template, how would
 you check for things like 
 
 	in
 	{
 		assert(object!=null); 
 	}
 	
 This code snippet is valid for class references but not primitive types. 
 
 It seems to me that you pay a price for generality in terms of strong
 program type checking and contract programming.


Would you want a general-purpose collection to do such a thing? 
Collections containing nulls may be desirable in some applications.

If you did desire such a container, there's nothing saying you can't 
extend a template class and add this functionality.

  -- andy
Sep 06 2003
prev sibling next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
BDP wrote:

 Again, please excuse my ignorance, but if you have a template, how would
 you check for things like 
 
 	in
 	{
 		assert(object!=null); 
 	}
 	
 This code snippet is valid for class references but not primitive types. 


Urgh... is it really a usual practice to do such checks in Java?
I think you rather don't need to assert it, since you simply get a null 
dereference exception the next moment.

In general, unless you put a null object into a collection, it may not 
happen that you retrieve one. At least i can't imagine how. And before 
putting it into collection, you may want to make sure you put only valid 
things there - you define what is valid and what not - sometimes null 
might make sense, but some other things might not - by using an assertion.


 It seems to me that you pay a price for generality in terms of strong
 program type checking and contract programming.


Exactly: that's what happens in Java to a further extent than here. :)))))))
You don't have any static type-checking with collection classes, while 
templates are 100% type-safe.

- eye.
Sep 06 2003
prev sibling parent Mike Wynn <mike l8night.co.uk> writes:
BDP wrote:

 
 Again, please excuse my ignorance, but if you have a template, how would
 you check for things like 
 
 	in
 	{
 		assert(object!=null); 
 	}
 	
 This code snippet is valid for class references but not primitive types. 


D allows templates to be specified for use with a heirachy of class/types.
i.e.
template mine( T : Object ) {
	void func( T object )
	in { assert( object!== null ); } // note the "! = ="

	// for object/ref types
	// D "= = =" is eqiv to java "= ="
	// D "a = = b" is eqiv to Java a.equals( b )
	// D "a ! = b" is eqiv to Java !a.equals(b)
	// D "! = = " is eqiv to Java "!="
}

template mine( T : int|uint|short|ushort ) {
	void func( T object )
	in { assert( object != 0 ); } // note the "! = ="
}

you can't make an instance of "mine" with struct or floating point type.
problem solved, (the Generics in Java spec allows this too)


 
 It seems to me that you pay a price for generality in terms of strong
 program type checking and contract programming.
 


I disagree dynamically typed and weakly typed langs handle can template
in some cases  better than strongly typed langs.

everything has a price, in Java you have to cast in any "container" 
class. however with D the price is mainly in the source rather than the 
object files.
Sep 06 2003