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