• chris (28/28) Nov 14 2005 I've been looking over the DTL (and D as well in general, as the two
• Don Clugston (5/36) Nov 14 2005 My guess: because D doesn't have implicit template instantiation yet.
• Sean Kelly (18/43) Nov 14 2005 I think Don's answer is the right one--without implicit template
• Hasan Aljudy (17/50) Nov 16 2005 ((Sorry, this rant/post maybe a bit OT.))
• Dejan Lekic (18/21) Nov 17 2005 If You ever used STDC++ map You would not write this paragraph above...
• Matthew (27/55) Nov 21 2005 I just wanted to post a comment to let you all know that I'm aware of th...
• Ivan Hernandez (8/13) May 02 2006 asserting that D Templates are not instantiated like in C++ and that's w...
• Don Clugston (5/21) May 02 2006 When DTL was written, there was no implicit template function

chris <caj dcs.st-and.ac.uk> writes:

I've been looking over the DTL (and D as well in general, as the two 
can't be easily seperated), coming as someone who knows more about the 
STL's algorithms and containers than I think any sane man should do..

Generally, I would say it looks quite good. Just a couple of tiny 
comments, which might just be my misunderstanding..

1) It seems like things like sort, reverse, etc. are being attached as 
member functions rather than seperate functions. One of the nicest 
things about the STL is that you only have to write sort once, rather 
than attach it to every container. This seems more like a step backwards 
than a step forwards.. any particular reason?

2) In my opinion (other people can disagree with me of course), the 
single biggest problem with the STL was having functions take a pair of 
iterators rather than a single "container", for example making people 
write "sort(v.begin(), v.end());" instead of just "sort(v)". If you want 
to make a container from a random pair of iterators, you could make a 
wrapper function. This kind of thing is now appearing in boost and other 
places, usually under the name range-lib. I'd hope that the DTL might 
get this correct from the start.

3) Has there been much thought or work on a D-equivalent of "swap", or 
the upcoming "move semantics" of C++? swap (where you want to define a 
general swap function which can be overloaded, to make your algorithms 
easily extendable) is something which for a very long time C++ didn't 
really get right, so it would be nice if it was got right stright away 
this time :) Of course if the aim of the DTL isn't to try to seperate 
algorithms and containers in the same way as the STL did, this becomes 
less important (but it is still useful if you want to allow, for 
example, vectors of vectors or lists of lists, etc.)

Chris

Don Clugston <dac nospam.com.au> writes:

chris wrote:
 I've been looking over the DTL (and D as well in general, as the two 
 can't be easily seperated), coming as someone who knows more about the 
 STL's algorithms and containers than I think any sane man should do..
 
 Generally, I would say it looks quite good. Just a couple of tiny 
 comments, which might just be my misunderstanding..
 
 1) It seems like things like sort, reverse, etc. are being attached as 
 member functions rather than seperate functions. One of the nicest 
 things about the STL is that you only have to write sort once, rather 
 than attach it to every container. This seems more like a step backwards 
 than a step forwards.. any particular reason?

My guess: because D doesn't have implicit template instantiation yet.
(OTOH I think D has improved greatly since the last update of DTL.
It now has more metaprogramming power than C++, there may be some other 
D-specific alternatives).

 2) In my opinion (other people can disagree with me of course), the 
 single biggest problem with the STL was having functions take a pair of 
 iterators rather than a single "container", for example making people 
 write "sort(v.begin(), v.end());" instead of just "sort(v)". If you want 
 to make a container from a random pair of iterators, you could make a 
 wrapper function. This kind of thing is now appearing in boost and other 
 places, usually under the name range-lib. I'd hope that the DTL might 
 get this correct from the start.

 3) Has there been much thought or work on a D-equivalent of "swap", or 
 the upcoming "move semantics" of C++? swap (where you want to define a 
 general swap function which can be overloaded, to make your algorithms 
 easily extendable) is something which for a very long time C++ didn't 
 really get right, so it would be nice if it was got right stright away 
 this time :) Of course if the aim of the DTL isn't to try to seperate 
 algorithms and containers in the same way as the STL did, this becomes 
 less important (but it is still useful if you want to allow, for 
 example, vectors of vectors or lists of lists, etc.)
 
 Chris

Sean Kelly <sean f4.ca> writes:

chris wrote:
 
 1) It seems like things like sort, reverse, etc. are being attached as 
 member functions rather than seperate functions. One of the nicest 
 things about the STL is that you only have to write sort once, rather 
 than attach it to every container. This seems more like a step backwards 
 than a step forwards.. any particular reason?

I think Don's answer is the right one--without implicit template 
instantiation, the algorithm-based approach isn't quite as simple.
 
 2) In my opinion (other people can disagree with me of course), the 
 single biggest problem with the STL was having functions take a pair of 
 iterators rather than a single "container", for example making people 
 write "sort(v.begin(), v.end());" instead of just "sort(v)". If you want 
 to make a container from a random pair of iterators, you could make a 
 wrapper function. This kind of thing is now appearing in boost and other 
 places, usually under the name range-lib. I'd hope that the DTL might 
 get this correct from the start.t

I know there are other prominent people in the C++ community that share 
your view, however, one of the original design goals of iterators was 
that they must mimic pointer semantics exactly.  And this wouldn't work 
using the Java iterator approach.  That said, Matthew (the creator of 
the DTL) pretty much invented the concept of ranges (insofar as 
published works are concerned anyway), and DTL does contain support for 
them.  Iterators are but one way that DTL containers can be used.

 3) Has there been much thought or work on a D-equivalent of "swap", or 
 the upcoming "move semantics" of C++? swap (where you want to define a 
 general swap function which can be overloaded, to make your algorithms 
 easily extendable) is something which for a very long time C++ didn't 
 really get right, so it would be nice if it was got right stright away 
 this time :)

I don't know that it matters as much for D, since D classes have 
reference semantics.  But it would be simple enough to leverage C++ work 
in this area if necessary.

 Of course if the aim of the DTL isn't to try to seperate
 algorithms and containers in the same way as the STL did, this becomes 
 less important (but it is still useful if you want to allow, for 
 example, vectors of vectors or lists of lists, etc.)

Without implicit template support for functions, I don't think the 
algorithm-based approach is particularly practical, even though I like 
it quite a bit.  I know Walter has suggested that this may change at 
some point, but I have the feeling it's a 2.0 feature.


Sean

Hasan Aljudy <hasan.aljudy gmail.com> writes:

((Sorry, this rant/post maybe a bit OT.))

I don't really like the C++ STL at all!! Partially because of the 
template syntax, but most importantly because I got used to the richness 
and organization of the Java API! The STL is very poor/greedy and 
sometimes rediculous.

For example, HashTables!! The STL doesn't have them! well, it has a map 
class, but the syntax is ugly, and java has two alternatives: hashmaps 
and hashtables. the STL only has one!

Also, reading files! Java has many many buffer reader classes and what 
not and they can do all sorts of different things, and for most cases 
you will always find what you need in one of them. C++ on the other 
hand, well .. fstream stuff is pretty poor.

Sorry for not providing good examples, I'm sleepy right now, and my head 
kinda hurts.

Anyway, I just want to say that we shouldn't be comparing D to C++, and 
our goal shouldn't be to 'reach' C++!

chris wrote:
 I've been looking over the DTL (and D as well in general, as the two 
 can't be easily seperated), coming as someone who knows more about the 
 STL's algorithms and containers than I think any sane man should do..
 
 Generally, I would say it looks quite good. Just a couple of tiny 
 comments, which might just be my misunderstanding..
 
 1) It seems like things like sort, reverse, etc. are being attached as 
 member functions rather than seperate functions. One of the nicest 
 things about the STL is that you only have to write sort once, rather 
 than attach it to every container. This seems more like a step backwards 
 than a step forwards.. any particular reason?
 
 2) In my opinion (other people can disagree with me of course), the 
 single biggest problem with the STL was having functions take a pair of 
 iterators rather than a single "container", for example making people 
 write "sort(v.begin(), v.end());" instead of just "sort(v)". If you want 
 to make a container from a random pair of iterators, you could make a 
 wrapper function. This kind of thing is now appearing in boost and other 
 places, usually under the name range-lib. I'd hope that the DTL might 
 get this correct from the start.
 
 3) Has there been much thought or work on a D-equivalent of "swap", or 
 the upcoming "move semantics" of C++? swap (where you want to define a 
 general swap function which can be overloaded, to make your algorithms 
 easily extendable) is something which for a very long time C++ didn't 
 really get right, so it would be nice if it was got right stright away 
 this time :) Of course if the aim of the DTL isn't to try to seperate 
 algorithms and containers in the same way as the STL did, this becomes 
 less important (but it is still useful if you want to allow, for 
 example, vectors of vectors or lists of lists, etc.)
 
 Chris

Dejan Lekic <leka entropy.tmok.com> writes:

 For example, HashTables!! The STL doesn't have them! well, it has a map
 class, but the syntax is ugly, and java has two alternatives: hashmaps
 and hashtables. the STL only has one!

If You ever used STDC++ map You would not write this paragraph above...
Sure, I can understand reasons behind this text - JAVA does not have
generic types, and since JAVA developers are not familiar with it, than
syntax seems awkward...

It is also a matter of taste - I think both (common) Java and STDC++ classes
are well-organized.

Anyway - the topic here is DTL... My opinion is that DTL, considering how
young is, is going toward right direction... And soon it will beat both
STDC++ and JAVA.

PS. Note that i do not use term STL here - many classes/templates from STL
are now in STDC++, and people do not use STL anymore (most of us don't
better to say). BOOST project has classes/templates which will most likely
go into next revision of STDC++...

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
  

"Matthew" <matthew hat.stlsoft.dot.org> writes:

I just wanted to post a comment to let you all know that I'm aware of this
thread - I manage to check this ng every couple of weeks - but at the moment
I am overblown with work, on my next book: Extended STL. This has turned
into a two-volume beastie, the first one of which must be finished in the
next couple of months. The second volume will be prepared next year, and one
part in it is planned to cover the reanimated DTL, which I will obviously
have to, er, reanimate sometime early next year.

I'm looking forward to getting back into D in a few months' time, and seeing
what new features will be available for realising the DTL vision.

FTR: DTL aimed (and still aims, AFAIAC) to provide the best of the C++ STL
and Java collections with a whole lot of Ruby thrown in for good measure. I
remain confident that that can still be achieved.

Cheers


-- 
Matthew Wilson

Author: "Extended STL", Addison-Wesley, 2006
    (http://www.extendedstl.com)
Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)



"chris" <caj dcs.st-and.ac.uk> wrote in message
news:dla99m$1olp$1 digitaldaemon.com...
 I've been looking over the DTL (and D as well in general, as the two
 can't be easily seperated), coming as someone who knows more about the
 STL's algorithms and containers than I think any sane man should do..

 Generally, I would say it looks quite good. Just a couple of tiny
 comments, which might just be my misunderstanding..

 1) It seems like things like sort, reverse, etc. are being attached as
 member functions rather than seperate functions. One of the nicest
 things about the STL is that you only have to write sort once, rather
 than attach it to every container. This seems more like a step backwards
 than a step forwards.. any particular reason?

 2) In my opinion (other people can disagree with me of course), the
 single biggest problem with the STL was having functions take a pair of
 iterators rather than a single "container", for example making people
 write "sort(v.begin(), v.end());" instead of just "sort(v)". If you want
 to make a container from a random pair of iterators, you could make a
 wrapper function. This kind of thing is now appearing in boost and other
 places, usually under the name range-lib. I'd hope that the DTL might
 get this correct from the start.

 3) Has there been much thought or work on a D-equivalent of "swap", or
 the upcoming "move semantics" of C++? swap (where you want to define a
 general swap function which can be overloaded, to make your algorithms
 easily extendable) is something which for a very long time C++ didn't
 really get right, so it would be nice if it was got right stright away
 this time :) Of course if the aim of the DTL isn't to try to seperate
 algorithms and containers in the same way as the STL did, this becomes
 less important (but it is still useful if you want to allow, for
 example, vectors of vectors or lists of lists, etc.)

 Chris

Ivan Hernandez <Ivan_member pathlink.com> writes:

There was some comments about:

 1) It seems like things like sort, reverse, etc. are being attached as
 member functions rather than seperate functions. One of the nicest
 things about the STL is that you only have to write sort once, rather
 than attach it to every container. This seems more like a step backwards
 than a step forwards.. any particular reason?


asserting that D Templates are not instantiated like in C++ and that's why the
sort() is being implemented on each collection class. But I think that's not a
problem. sort() is a generic fuction, and it should work with any collection
type. Couldn't it be implemented as a mixin?

I'm not really aware of mixin limitations on D, but it should work in other
languages, be theirs typings dynamic like Ruby or Python, or static as Sather
and Eiffel (all four of them allowing for code inclusion within a class).

Don Clugston <dac nospam.com.au> writes:

Ivan Hernandez wrote:
 There was some comments about:
 
 1) It seems like things like sort, reverse, etc. are being attached as
 member functions rather than seperate functions. One of the nicest
 things about the STL is that you only have to write sort once, rather
 than attach it to every container. This seems more like a step backwards
 than a step forwards.. any particular reason?


 
 asserting that D Templates are not instantiated like in C++ and that's why the
 sort() is being implemented on each collection class. But I think that's not a
 problem. sort() is a generic fuction, and it should work with any collection
 type. Couldn't it be implemented as a mixin?
 
 I'm not really aware of mixin limitations on D, but it should work in other
 languages, be theirs typings dynamic like Ruby or Python, or static as Sather
 and Eiffel (all four of them allowing for code inclusion within a class).

When DTL was written, there was no implicit template function 
instantiation (IFTI). Now that we have IFTI, sort could be written 
similarly to how it's done in C++.
In fact, DTL contains many workarounds which are no longer necessary.