[range_ex]"Practical" Status of boost::range, boost::range_ex, and associated algorithms
Hi there, I am excited to start using ranges in user code with standard algorithms (mostly copy, transform, binary_searches). Is it safe for me to start using code with range/range_ex? Since the http://www.boostpro.com/vault/index.php?directory=Algorithms version hasn't been updated for a while, I was worried that there could be interface changes. I am perfectly willing to use a subset of algorithms that are expected to remain stable -Jesse
On Fri, Jan 29, 2010 at 4:55 PM, Jesse Perla <jesseperla@gmail.com> wrote:
Hi there, I am excited to start using ranges in user code with standard algorithms (mostly copy, transform, binary_searches).
Is it safe for me to start using code with range/range_ex?
Absolutely, it's very safe to start using it! There are users of range_ex in substantial applications. I am frantically updating documentation and making minor changes as related to the review. If you stick to the pipe (|) syntax the interface remains stable. I need to rename the make_xxx_range functions before getting this into the sandbox. The only reason RangeEx is not in the current release is due to the need to update documentation and make some minor changes before submission. It is not due to known defects. RangeEx is most definitely supported despite my infuriating lack of progress due to job changes and other life nonsense. I will respond to issues in a good time frame, and will have everything ready for a proper boost release but after 1.42. I fully encourage using RangeEx. If you need assistance, changes, or new features please ask. Regards, Neil Groves
On Jan 29, 12:47 pm, Neil Groves <n...@grovescomputing.com> wrote:
On Fri, Jan 29, 2010 at 4:55 PM, Jesse Perla <jessepe...@gmail.com> wrote: Absolutely, it's very safe to start using it! There are users of range_ex in substantial applications.
Great. Should I use the copy in: http://www.boostpro.com/vault/index.php?directory=Algorithms or SVN version? Thanks for such an important library. -Jesse
Great. Should I use the copy in: http://www.boostpro.com/vault/index.php?directory=Algorithms or SVN version?
If you wish to use Boost.RangeEx then please use the version in the Vault. This has many additional features than the SVN sandbox version and a huge number of features over the current Boost.Range. Boost.RangeEx is backward compatible with Boost.Range so you might decide to use the trunk version if this is more convenient, but Boost.RangeEx adds Range Adaptors and Range Algorithms which are very compelling.
I shall post publicly once I have put a newer version into the main trunk. Regards, Neil Groves
Neil Groves wrote:
Great. Should I use the copy in: http://www.boostpro.com/vault/index.php?directory=Algorithms or SVN version?
If you wish to use Boost.RangeEx then please use the version in the Vault. This has many additional features than the SVN sandbox version and a huge number of features over the current Boost.Range. Boost.RangeEx is backward compatible with Boost.Range so you might decide to use the trunk version if this is more convenient, but Boost.RangeEx adds Range Adaptors and Range Algorithms which are very compelling.
I shall post publicly once I have put a newer version into the main trunk.
Regards, Neil Groves
Have you written anything about how to write my own adaptors? I have several iterator adaptors that I'd like to try converting to range adaptors. I noticed the 'strided' example which seems like a good starting example. One I'm interested in is adaptors that convert between interpretations of sequences as real and complex.
Have you written anything about how to write my own adaptors? I have several iterator adaptors that I'd like to try converting to range adaptors. I noticed the 'strided' example which seems like a good starting example.
I have not yet written this documentation although I had already put this on my schedule. I'm frantically putting the documentation together. I'll try and get something to you privately by the end of next weekend. It might be a big rough around the edges but hopefully it will help.
One I'm interested in is adaptors that convert between interpretations of sequences as real and complex.
That's a great idea and a perfect use case for the Range Adaptors. Regards, Neil Groves
On Jan 29, 12:47 pm, Neil Groves <n...@grovescomputing.com> wrote:
to the review. If you stick to the pipe (|) syntax the interface remains stable. I need to rename the make_xxx_range functions before getting this into the sandbox. The only reason RangeEx is not in the current release is due to the need to update documentation and make some minor changes before submission. It is not due to known defects.
Thanks Neil, everything seems to work swimmingly. One question related to the make_XXX_ I had was the preferred method (today and in the future post inclusion into the standard library if they are different) for creating ranges from a subset of a container. i.e. what is intended equivalent to: std::copy(myvec.begin() + 1, myvec.end(), targetvec.begin()); Should I be using something like: boost::copy( myvec | sliced(1, myvec.size()), targetvec.begin()); Or: boost::copy( make_range(myvec, 1, myvec.size())), targetvec.begin()); or...: boost::copy( make_iterator_range( mvec.begin() + 1, myvec.end(), targetvec.begin() ); Thanks, Jesse
Should I be using something like: boost::copy( myvec | sliced(1, myvec.size()), targetvec.begin());
The above example using '|' is my favourite. The other mechanisms will remain supported. The '|' operator is far more readable when one chains adaptors in my opinion, but this is controversial.
Or: boost::copy( make_range(myvec, 1, myvec.size())), targetvec.begin());
In the above IIRC this should be make_sliced_range
or...: boost::copy( make_iterator_range( mvec.begin() + 1, myvec.end(), targetvec.begin() );
The above example isn't compelling, but is indeed legal and works. I hope this helps, Neil Groves
participants (3)
-
Jesse Perla -
Neal Becker -
Neil Groves