www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dtl - What all is in DTL?

reply Gold Dragon <dragonwing dragonu.net> writes:
What are you including in the DTL or (I'm guessing) D Template Library? 
Are you going to create a iostream STL clone because the one in Phobos 
isn't finished and it is mostly C in a class which is mostly worthless.
Jul 09 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 What are you including in the DTL or (I'm guessing) D Template Library?


DTL will be two things:

1. A description of concepts & protocols for collections in D, that may be
applied throughout the D world, along with supporting mixins and interfaces.
These protocols are influenced by STL, Java, Ruby and D itself, and they may all
be supported in a maximally efficient manner.
2. An implementation of specific container template classes, e.g. List, Map,
SList, Queue, Deque, Stack etc. according to the protocol.

There will also be a variety of algorithms, although I expect that that side of
the library will mostly grow from demand/submission after it's being used.


 Are you going to create a iostream STL clone because the one in Phobos
 isn't finished and it is mostly C in a class which is mostly worthless.


No. I don't think the IOStream model is one that anyone should try and ape, and
I
have no intention of doing so myself.

In terms of the implementation of the collection concepts in container classes,
DTL will restrict itself to *containers only*. (I think keeping a single mission
will make it more easy to create, use, digest, maintain.) But its concepts,
protocols, mixins, and interfaces will lend themselves to any manipulation of
collections (in the broadest sense), so it may well be that others may reuse
them
for work in the areas of streaming, or any other area. (I myself plan to borrow
peices from DTL to enhance std.recls once it's ready.)

As for what one should be using for streaming, I can't answer that, but I can
tell you I plan to dig deep into Mango in the next week or so, as soon as my
schedule frees up.

Matthew
Jul 09 2004
parent reply Gold Dragon <dragonwing dragonu.net> writes:
Well, I'm not happy with std.stream class and I'm glad that some one is 
making a list, queue, deque, etc since the crap I would make would be 
well, crap and that would suck with projects that I'm working on. Are 
all of these classes going to be available at release or are you just 
supplying the container classes and making the rest of us create the rest?

 From what I read, I would say yes but I have a feeling that I may be 
wrong. You are going to include operator overloading along with the 
function? Java has a way of being extremely typeful at all times and 
using operators would save space and be easier to program with.

Good luck and I can't wait until you finish.
Jul 09 2004
next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Gold Dragon" <dragonwing dragonu.net> wrote in message
news:ccm1ar$284l$1 digitaldaemon.com...

 Well, I'm not happy with std.stream class and I'm glad that some one is
 making a list, queue, deque, etc since the crap I would make would be
 well, crap and that would suck with projects that I'm working on. Are
 all of these classes going to be available at release or are you just
 supplying the container classes and making the rest of us create the rest?

  From what I read, I would say yes but I have a feeling that I may be
 wrong. You are going to include operator overloading along with the
 function? Java has a way of being extremely typeful at all times and
 using operators would save space and be easier to program with.

 Good luck and I can't wait until you finish.


What don't you like about std.stream? Walter doesn't work on it so it really
seems to be up to us users to add features to it or "fix" it. There have
been several recent threads in digitalmars.D about streams and i/o so you
might want to check those out, too.

-Ben
Jul 09 2004
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Gold Dragon" <dragonwing dragonu.net> wrote in message
news:ccm1ar$284l$1 digitaldaemon.com...

 Well, I'm not happy with std.stream class and I'm glad that some one is
 making a list, queue, deque, etc since the crap I would make would be
 well, crap and that would suck with projects that I'm working on.


Well, don't get your hopes up. Mine might be crap as well.


 Are
 all of these classes going to be available at release or are you just
 supplying the container classes and making the rest of us create the rest?


When I worked on this in March, I wrote List, Map, Queue, Set, Stack and Vector,
and that's the current state-of-play.

Nothing much has changed since then, as I was waiting for some advance of
technology (mixins) and then bugs and other work has held me up since. But I
will
be getting down to it again next week, as my deadline for the current work is
next monday.

The first release will likely contain just those five containers, as I'd rather
focus on getting the quality right initially.

My guess/hope is that people will work with the initial suite of classes, and
from the feedback some classes will be altered and new ones will be born,
created
either by me or anyone else who wants to contribute.

But as I said, my intention is that things that reside in std.dtl.* are either
bona-fide containers, or mixins or interfaces or algorithms. Pseudo-containers,
like the myriad ones in STLSoft (http://stlsoft.org/) will not be part of DTL
per-se. The reason for this is to keep it clean, efficient, small, maintainable
and, most importantly, comprehensible by the vast majority of users. That last
quality is very much lacking in STL.

But DTL will _absolutely_ support the provision of STL-compliant/compatible
pseudo-containers, by prescribing concepts/models and by providing interfaces
and
mixins. The ethos is to enable compatibility, but not demand it. (I'm a big fan
of low coupling and leaving decisions with the developer, just like Walter, so I
don't expect this ethos to be unwelcome.)


  From what I read, I would say yes but I have a feeling that I may be
 wrong. You are going to include operator overloading along with the
 function?


Depends on which operators you mean. I'm not going to have any counter-intuitive
operators (e.g. << !!)


 Java has a way of being extremely typeful at all times and
 using operators would save space and be easier to program with.


Java-like containers are one of four containment models supported. They'll be
available to those who need/want them, but have no overhead for those that want
to use another model.


 Good luck and I can't wait until you finish.


ha! Well, yes, it would be nice to get the first version out soon. To whit, I
must get on with what I'm currently working on, so I am indeed free next week.

But, as I've said all along, it'll be ready in time for D 1.0, and there's no
change in that intention/likelihood.

Cheers (and thanks for the interest)


-- 
Matthew Wilson

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)

-----------------------------------------------------
Jul 09 2004
parent reply Gold Dragon <dragonwing dragonu.net> writes:
 From what I heard a Set is like a tree or it could be a hash. If I want 
a tree than I want to define its behavior myself. As such I would rather 
like to have a Set or tree of objects as from a struct or another class. 
If a Set is not a tree then there probably should be one.

Well, I only have less than a year of C++ so whatever you can make would 
be better than anything I can do. I was actually planning on hacking STL 
and porting the code over to D but it is much to difficult to understand 
the C++ code. You doing all the work saves me a lot of time, which makes 
for more time editing, recreating, destroying, molding, and do whatever 
I like to your code as long as there isn't a copyright preventing me to 
do so.

Where will you post the Package when you are done?
Jul 12 2004
parent "Matthew Wilson" <dmd synesis.com.au> writes:
"Gold Dragon" <dragonwing dragonu.net> wrote in message
news:ccv4bb$cgp$1 digitaldaemon.com...

 From what I heard a Set is like a tree or it could be a hash. If I want
 a tree than I want to define its behavior myself. As such I would rather
 like to have a Set or tree of objects as from a struct or another class.
 If a Set is not a tree then there probably should be one.


I think we'll define Set to have its internals implementation-dependent.

I agree that an explicit Tree would be good.


 Well, I only have less than a year of C++ so whatever you can make would
 be better than anything I can do.


You might be right. Time will tell ...


 I was actually planning on hacking STL
 and porting the code over to D but it is much to difficult to understand
 the C++ code. You doing all the work saves me a lot of time, which makes
 for more time editing, recreating, destroying, molding, and do whatever
 I like to your code as long as there isn't a copyright preventing me to
 do so.


It's all being written under the "D" license. There'll be no particular
license restrictions preventing you, or anyone else, from modifying it, but
only approved changes will be rolled back into Phobos.


 Where will you post the Package when you are done?


Not sure yet. We'll make sure it's well publicised before posting.

Cheers

Matthew
Jul 13 2004