www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - 1.8.6 sr_* algorithms

reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
Hi,

One question:
Is there any reason for excluding sr_find from the sr_* familiy of 
algorithms?

On another subject... I take it you missed my e-mail or were to busy with 
1.8.6, but I never got a reply when asking about missing files for testing 
the CArray adaptors (afx_allocator, and some others I don't remember), still 
interested in thesting those?


Pablo
Aug 16 2005
next sibling parent "Matthew" <matthew hat.stlsoft.dot.org> writes:
 Is there any reason for excluding sr_find from the sr_* familiy of
 algorithms?


Probably just an omission


 On another subject... I take it you missed my e-mail or were to busy with
 1.8.6, but I never got a reply when asking about missing files for testing
 the CArray adaptors (afx_allocator, and some others I don't remember),


still

 interested in thesting those?


Sorry, I did get it, but then it slipped. I'm having a little trouble with
bandwidth on all the things for XSTL at the moment.

I'm pretty sure I sent you everything - did you make sure to place the new
zip in a directory which was specified _before_ %STLSOFT_INCLUDE% in the
include paths? In any case, I'll send you another. Let me get the final
changes for it and the associated chapter done, and then I'll wing it your
way again.

Cheers

Matthew
Aug 18 2005
prev sibling parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
 Is there any reason for excluding sr_find from the sr_* familiy of
 algorithms?


I remember now, yes. r_find() looks like:

    template< typename R
            , typename T
            >
    R r_find(R r, T const &val);


It returns a range representing the found element and the remainder of the
range, or an empty range otherwise.

To do this for a sequence, it'd have to be like the following:

    template< typename S
            , typename T
            >
    sequence_range<S> sr_find(S s, T const &val);

I guess this works and makes sense, but it didn't seem obvious to me at the
time.

One might use it as follows:


    if(sr_find(my_vector, 10))
    {
        . . .
    }

which is nice, but that's already available via sr_exists() and
sr_exists_if(). Actually using the return would be something like:

    sequence_range<std::vector<int> >  res = sr_find(my_vector, 10);

    if(res)
    {
        my_vector.erase(res.begin(), res.end());
    }

in which case one might as well skip ranges and just use normal STL:

    std::vector<int>::iterator i = std::find(my_vector.begin(),
my_vector.end(), 10);

    my_vector.erase(i);

What do you think? Have I missed some more-useful use? Is this desirable
without losing discoverability?

If people want it, I'll happily add it.

Cheers

Matthew
Aug 26 2005
parent reply "Pablo Aguilar" <pablo.dot.aguilar gmail.dot.com> writes:
Actually, you're right... the main reason for having it would be pretty much 
the same as using sr_exists. Which I wasn't aware of 'till you mentioned it 
here.

So I guess there's no need for it then.

Thanks for the info.


Pablo

"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:deorn0$304k$1 digitaldaemon.com...

 Is there any reason for excluding sr_find from the sr_* familiy of
 algorithms?


 I remember now, yes. r_find() looks like:

    template< typename R
            , typename T
            >
    R r_find(R r, T const &val);


 It returns a range representing the found element and the remainder of the
 range, or an empty range otherwise.

 To do this for a sequence, it'd have to be like the following:

    template< typename S
            , typename T
            >
    sequence_range<S> sr_find(S s, T const &val);

 I guess this works and makes sense, but it didn't seem obvious to me at 
 the
 time.

 One might use it as follows:


    if(sr_find(my_vector, 10))
    {
        . . .
    }

 which is nice, but that's already available via sr_exists() and
 sr_exists_if(). Actually using the return would be something like:

    sequence_range<std::vector<int> >  res = sr_find(my_vector, 10);

    if(res)
    {
        my_vector.erase(res.begin(), res.end());
    }

 in which case one might as well skip ranges and just use normal STL:

    std::vector<int>::iterator i = std::find(my_vector.begin(),
 my_vector.end(), 10);

    my_vector.erase(i);

 What do you think? Have I missed some more-useful use? Is this desirable
 without losing discoverability?

 If people want it, I'll happily add it.

 Cheers

 Matthew
Aug 29 2005
parent "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Pablo Aguilar" <pablo.dot.aguilar gmail.dot.com> wrote in message
news:devhpb$4or$1 digitaldaemon.com...

 Actually, you're right... the main reason for having it would be pretty


much

 the same as using sr_exists. Which I wasn't aware of 'till you mentioned


it

 here.

 So I guess there's no need for it then.

 Thanks for the info.



:-)
Aug 29 2005