Ben Hinkle wrote:

>>>Anyone want to throw out ideas on collection types that would be cool in
>>>DTL?
>>>      
>>>
>>Although D has many of the basic types in STL I think that not all possible uses will be though of in the language.  I think each type of collection needs a group of supporting functions in the STL under some standardised namespaces (so they are easy to find).  That is probably obvious.
>>    
>>
>
>I agree if you mean DTL should contain supporting functions for
>dynamic arrays and associative arrays instead of writing Vector
>and Map classes. 
>
Exactly but with a name convention that everyone can follow.

>Plus it should contain more "esoteric" containers
>like deque and linked lists (double and possibly single linked)
>and sets, multiset and multimaps.
>Ranges would be nice to throw in because they help with array
>manipulation.
>  
>
Single linked lists are one thing I miss in C++ and end up creating myself.  Please have single linked lists.

>>As far as collections go, what about different types of algorithms for different applications?  Surely the one-shoe-fits-all approach does not work for things like maps/associative arrays.  Users often wish to have a choice about what type of sort they use.  Of course you don't want to go overboard here either.  Parhaps a way of hinting what type of algorithm you want to use and if it is not there STL would use the next best thing.
>>    
>>
>
>seems reasonable. I remember custom sort algorithms for associative
>arrays coming up before.
>

Personally with collections I would like a form with as little overhead as possible.   For example, in C++ to access a vector's element there are always two or three checks just to do that.  I found that it was much faster to extract the array first before access many elements (of course that assumes knowledge that the size does not change).  Also, IMHO exceptions should be used sparingly, only on algorithms that are more then a few lines (of processing).  Contracts should be used in the main as these can be removed from the release.

-- 
-Anderson: http://badmama.com.au/~anderson/

> Hu? I assume your talking about stl. What about hash_map?

I think thats 'unofficial' , depends on the implementation.  I don't think that ever actually made into the standard ( though it seems most STL's still include it ).

( from other post )

> Personally with collections I would like a form with as little overhead as possible.

I agree , and yes (single and double )link list too please!  Sorry did I miss a release date on DTL ?

Thanks,
Charles


On Mon, 22 Mar 2004 23:01:39 +0800, J Anderson <REMOVEanderson@badmama.com.au> wrote:

> Chris Paulson-Ellis wrote:
>
>>
>> I'd like tree *and* hash implementations of the associative containers. It is annoying that C++ doesn't yet provide any hash containers (outside boost) and that other languages use them for everything. Choice please!
>>
> Hu? I assume your talking about stl. What about hash_map?
>
>> Chris.
>
>



-- 
D Newsgroup.

"Matthew" <matthew@stlsoft.org> wrote in message news:c3jqev$tbl$1@digitaldaemon.com...
> > I haven't done much D yet, but...
> > Aren't the typedefs like map_t.key_type and map_t.value_type good for
> > generic programming, instead of hardcoding types using the built in
> arrays?
>
> Yes. All DTL containers will have an appropriate and complete set of
member
> types.

That's exactly my point, can the benefits of having those simple typedefs be achieved with the built in assoc arrays?

My last post was very short-sighted, there's a whole lot more to C++'s STL than just things doing what they're supposed to... I'll explain: you don't rely on a map, just to use it's associative storing capabilities, you might use it knowing that forward traversals give you the collection's items in ascending order, or reverse iterating give's 'em to you in descending order...

Also, there are complexity (time and space) guarantee's which you might want to trade (making the storing policy a template, and have the map work with a tree or hash map) which you can't do with the language's built in types, or have it use a different sorting function, the list can go on!. How about something like C++ map's insert(iterator, value) which guarantee's a certain insertion time?

How would you do a vector's insert at a given point? Using slicing? If so, wouldn't the sintactic commodity be worth writing the wrapper around built in arrays?

And finally, if your so easily coninced that map was a blunder, why do Set then? (that's if you're doing it) I saw a few weeks ago, someone using an assoc array of elements to themselves (sorry for not remembering which post it was, but it stored functions keyed by functions) which as far as I can tell is pretty much a set...

My point is, don't be so easily discouraged just because something can already be half-done.

Pablo Aguilar wrote:

>And finally, if your so easily coninced that map was a blunder, why do Set
>then? (that's if you're doing it)
>
I don't think a set should be done in DTL.  It's basicly supported by assoative arrays.  What should be done (as stated before) is have supporting functions that can easily be improved (added to) as time goes on.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:
> Hu? I assume your talking about stl. What about hash_map?

It never made it into the C++ standard library - apparently the proposals for inclusion came too late.

Chris Paulson-Ellis wrote:

> J Anderson wrote:
>
>> Hu? I assume your talking about stl. What about hash_map?
>
>
> It never made it into the C++ standard library - apparently the proposals for inclusion came too late.

Oh, as C said many stl versions come with it.

-- 
-Anderson: http://badmama.com.au/~anderson/

Matthew,

It's really nice to see work being done on a comprehensive DTL.  And what's better is having the right person doing it.

Just wanted to say thanks.  There's plenty of work in that task, and I, and I'm sure many others, appreciate the time you are putting into it. And for free? Wow! (Or do we have to promise to buy all your books?!)

The thing about working on a library with such important implications is that it takes nerve to put your work out for public critism (or critique as we North Americans like to say ;-D ).  It's great you've got the nerve.  I'm looking forward to seeing it's completion and inclusion in D.

Thanks again,

John

"John Reimer" <jjreimer@telus.net> wrote in message news:c3ns62$1fjp$1@digitaldaemon.com...
> Matthew,
>
> It's really nice to see work being done on a comprehensive DTL.  And what's better is having the right person doing it.
>
> Just wanted to say thanks.  There's plenty of work in that task, and I, and I'm sure many others, appreciate the time you are putting into it. And for free? Wow! (Or do we have to promise to buy all your books?!)
>
> The thing about working on a library with such important implications is that it takes nerve to put your work out for public critism (or critique as we North Americans like to say ;-D ).  It's great you've got the nerve.  I'm looking forward to seeing it's completion and inclusion in D.
>
> Thanks again,
>
> John

Yes, even though he's British he is very talented. :o))

Seriously, I dont know where this would be without him, this DTL will definately make D more attractive.

Phill.

"John Reimer" <jjreimer@telus.net> wrote in message news:c3ns62$1fjp$1@digitaldaemon.com...
> Matthew,
>
> It's really nice to see work being done on a comprehensive DTL.  And what's better is having the right person doing it.

You may have cause to eat those words ... ;)

> Just wanted to say thanks.  There's plenty of work in that task, and I, and I'm sure many others, appreciate the time you are putting into it.

Good to hear. I'm looking forward to getting lots of feedback.

FYI: My next step is relying on default template params, which is not yet supported. Big W is working on (or at least thinking about) that at the moment, so it may be a week or so before we get anything coming down the pipe.

That works out well anyway, since I have to research and write an article for a paying client this week. :)

btw, book #1 - "Imperfect C++" - was sent off late last night, and is now sitting in the Addison-Wesley mail-system until they work out how to let me down gently. <G>

I feel 10 years younger this morning. :-)

> And for free? Wow! (Or do we have to promise to buy all your books?!)

Free? Yes. Book purchase? Most assuredly!

> The thing about working on a library with such important implications is that it takes nerve to put your work out for public critism (or critique as we North Americans like to say ;-D ).  It's great you've got the nerve.

Nerve's not something I'm lacking in. Brains? Maybe. Tact? Definitely. Charm? Alas yes. (At least my wife would say so)

As for the ramifications, there are two main features of DTL that will be "different" (can't really say radical) from what's gone before.

First, is focus on/use of Ranges, rather than Iterators, since Iterators is just one of (currently) three types of ranges. (This is, as I've said before, falling out of work in C++ with John Torjo, and will feature in the next C++ book.) I'm still working out the details, but I hope to integrate ranges/filters into D's slice syntax. Things are still blue sky a bit on that, and I'm content for that to wait awhile.

The second aspect is the ability to support Java style runtime polymorphic implementation of container interfaces, and compile-time STL style generic behaviour. I've mentioned some of this to Walter, and must now wait until Walter makes some changes to the compiler. I've done some proof of concept work in C++, and it looks good so far, but there may be D aspects I've not yet thought of, or additions to the language that Walter is unwilling to make.

>  I'm looking forward to seeing it's completion and inclusion
> in D.
>
> Thanks again,

You're most welcome.

"Phill" <phill@pacific.net.au> wrote in message news:c3ok1g$2phm$1@digitaldaemon.com...
>
> "John Reimer" <jjreimer@telus.net> wrote in message news:c3ns62$1fjp$1@digitaldaemon.com...
> > Matthew,
> >
> > It's really nice to see work being done on a comprehensive DTL.  And what's better is having the right person doing it.
> >
> > Just wanted to say thanks.  There's plenty of work in that task, and I, and I'm sure many others, appreciate the time you are putting into it. And for free? Wow! (Or do we have to promise to buy all your books?!)
> >
> > The thing about working on a library with such important implications is that it takes nerve to put your work out for public critism (or critique as we North Americans like to say ;-D ).  It's great you've got the nerve.  I'm looking forward to seeing it's completion and inclusion in D.
> >
> > Thanks again,
> >
> > John
>
> Yes, even though he's British he is very talented. :o))

I'm sure I don't get the contradiction.

Anyway, I'm not British, just a child of the world ... think of me as a well-travelled Yorkshireman, which is an oxymoron all its own.

> Seriously, I dont know where this would be without him, this DTL will definately make D more attractive.

Well, let's just hope we get there. :)

It's not entirely philanthropy, of course. I want to get Ranges accepted in both C++ and D (and maybe .NET) communities, so a bit of cross-correlation is going to go down nicely. It's also good stuff for books. The penultimate chapter of "Imperfect C++" - Chapter 34 "Functors and Ranges" - contains a good description of the Simple (like IntegralRange, i.e. the range is "purely" notional) and Iterable (based on a pair of iterators demarking a "real" range). The next C++ book (on "advanced" STL, if I may be so bold) will take this to the next level, with the introduction of a new range concept that I'm working on, which will encompass most other types of ranges that I can think of, which the STL Iterator concept cannot support (see my Feb 2004 CUJ article for a description of some of the limitations of Iterators.). If/when the D book gets going, I hope that Ranges will be in DTL, and therefore the cross-correlation will be complete! (I had a scary Emporer/Skywalker moment then. <G>)

Once I've got them in D and C++, I want to explore it with .NET, but it's very early days yet, and those guys'll be a lot harder to persuade. (I recently wrote a beautiful little range adapter template, to adapt the .NET mapping of recls to a range, in Managed C++, only to be informed by the compiler that templates may not hold pointers to managed objects. Grrrr. There's a lot of work to be done there, methinks. :(