[Boost-users] [range_ex]"Practical" Status of boost::range, boost::range_ex, and associated algorithms

[Jesse Perla]

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
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Neil Groves]

On Fri, Jan 29, 2010 at 4:55 PM, Jesse Perla <jesse...@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

 

[Jesse Perla]

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.

[Neil Groves]

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

[Neal Becker]

Neil Groves wrote:

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.

[Jesse Perla]

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,

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

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

[Neil Groves]

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