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

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

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

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

> 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

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

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

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.