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

> 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

> 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

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

"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.


:-)