View mode: basic / threaded / horizontal-split · Log in · Help
November 14, 2005
DTL vs. STL
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
November 14, 2005
Re: DTL vs. STL
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
November 14, 2005
Re: DTL vs. STL
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
November 16, 2005
Re: DTL vs. STL
((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
November 17, 2005
Re: DTL vs. STL
> 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
November 21, 2005
Re: DTL vs. STL
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
May 02, 2006
Re: DTL vs. STL - Mixins for sort()?
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).
May 03, 2006
Re: DTL vs. STL - Mixins for sort()?
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.
Top | Discussion index | About this forum | D home