Arcane Jill wrote:

>In article <c9d7va$ejj$1@digitaldaemon.com>, Walter says...
>  
>
>>One way to do it is to derive from the container class type, and override
>>opApply() to access the members in the reverse manner.
>>    
>>
>
>I must have missed the instructions for opApply. It doesn't seem to be listed in
>the Operator Overloads page. Where can I find out about it?
>
>Arcane Jill
>  
>
Well it's not an operator, its a statement overloaded.  See http://www.digitalmars.com/d/statement.html.

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

In article <c9amsm$29f$1@digitaldaemon.com>, Sean Kelly wrote:
> (and slightly different) algorithm model.  But there's currently no support for reverse ranges or for treating library containers with similar semantics to builtin containers, so I have a feeling that something akin to iterators may be necessary.

Indeed. Iterators wouldn't be bad. I've been thinking of integrating streams and iterators, something like:

interface InputStream(T)
{
    bool valid()
    T get();
    void next();
}

class Set(T)
{
    InputStream!(T) iterate() { .. }
    InputStream!(T) iterate_backwards() { .. }
    ..
}

void f(Set!(int) set_of_integers)
{
    InputStream!(int) stream = set_of_integers.iterate();

    // Print "1 2 3 4 ... "
    while (stream.valid)
    {
        printf("%d\n", stream.get());
        stream.next();
    }

    // Print "... 4 3 2 1"
    stream = set_of_integers.iterate_backwards();
    while (stream.valid)
    {
        printf("%d\n", stream.get());
        stream.next();
    }
}

Or, similarly, use streams for whatever you like, for example to iterate over primes or real numbers, to filter data from other streams, read data from standard input or a file, etc.

-Antti


-- 
I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.

> > I'm sure this will come out in a standard lib eventually.  Note that stl is a lib not part of C++ itself.  However for simple things D does maps and arrays in a much neater-to-use way (I'm looking at this from the client side rather then from the implementation side as you are).  It shouldn't be hard to map these into your own libraries if you so wish.
>
> No. There is no "STL" nowadays, really. It is all just ISO C++.

Depends on your viewpoint. STL is still clearly identifiable, but it is a subset of what is the C++ standard library.

> std::vector<T> is just as much a first class citizen as T[]. The same with
> std::sort() and qsort().

Again, it depends. In several important ways std::vector<T> is not the same as T[]. For a start, std::vector<T> can be represented differently by different compilers and/or libraries on the same operating environment. T[] is far more consistent, packing pragmas notwithstanding.

> D is evolving, so there is no need to defend absense of certain things. I may be wrong, but the D map looks more like an associative array, which is a different beast from the map. Anyone looked into it?

"Sean Kelly" <sean@f4.ca> wrote in message news:c9als7$q7$1@digitaldaemon.com...
> Sarat Venugopal wrote:
> >
> > Of course, creating a vector like class in D shouldn't be a problem. The OP's premise was that sorting with custom criteria was not supported by the language or existing libraries. That is a fact. qsort clearly cannot understand classes, so that's not an option. Of course, you could do a myriad of things to get the effect. What C++  provides is a std::sort() (and other algorithms) with guarantees. The user can specify their own sorting criterion. IOW, abstractions are not quite there yet.
> >
> > I do agree that it is possible to create similar (or better) libraries in
> > D - whether it is easier (getting the same guarantees and performance) , I
> > don't know.
>
> The only real need in D is iterators, and this can be accomplished with free functions (since D has built in vectors and maps which you'd want to support with the same semantics as library types).  ie. it may end up looking something like this:
>
> dvector!(char).inst vec; // alias for char[] vec
> dvector!(char).iterator i = dvector!(char).begin( vec );
>
> It is probably possible to improve upon this, but I've held off on giving it much thought until I see what Matthew does with the DTL :)

Not much longer old bean. June's going to be a very nasty experience for me, but July will be much better. Expect much action in July.

btw, iterators will be one of the four cornerstones of DTL enumeration, but will be the poorer (and less needed) brother to freaching and ranges.