[Range] Transform in place

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Range] Transform in place

Boost - Dev mailing list
Earlier today I wrote the following two lines of code:

        auto const my_range = v | boost::adaptors::sliced(1,15) |
boost::adaptors::strided(2);
        boost::range::transform( my_range, my_range.begin(), std::bit_not<uint8_t>() );

However it would have been nice as a one-liner:

        boost::range::transform( v | boost::adaptors::sliced(1,15) |
boost::adaptors::strided(2), std::bit_not<uint8_t>() );

Why isn't there a form of "range::transform" that can transform in
place (and therefore takes exactly two arguments)?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] Transform in place

Boost - Dev mailing list
On 30/03/2020 05:21, Frederick Gotham wrote:

> Earlier today I wrote the following two lines of code:
>
> auto const my_range = v | boost::adaptors::sliced(1,15) |
> boost::adaptors::strided(2);
> boost::range::transform( my_range, my_range.begin(), std::bit_not<uint8_t>() );
>
> However it would have been nice as a one-liner:
>
> boost::range::transform( v | boost::adaptors::sliced(1,15) |
> boost::adaptors::strided(2), std::bit_not<uint8_t>() );
>
> Why isn't there a form of "range::transform" that can transform in
> place (and therefore takes exactly two arguments)?

I would imagine that mutating an adapted range in-place may not always
be safe -- eg. a sorted/filtered range, especially if you're modifying
the field used as key.

But you could always write your own wrapper that lets you do that if you
wanted.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] Transform in place

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, 29 Mar 2020 at 17:21, Frederick Gotham via Boost <
[hidden email]> wrote:

> Earlier today I wrote the following two lines of code:
>
>         auto const my_range = v | boost::adaptors::sliced(1,15) |
> boost::adaptors::strided(2);
>         boost::range::transform( my_range, my_range.begin(),
> std::bit_not<uint8_t>() );
>
> However it would have been nice as a one-liner:
>
>         boost::range::transform( v | boost::adaptors::sliced(1,15) |
> boost::adaptors::strided(2), std::bit_not<uint8_t>() );
>
> Why isn't there a form of "range::transform" that can transform in
> place (and therefore takes exactly two arguments)?
>
>
The reason is that when I first implemented the main algorithms I was
writing almost exact equivalents of the iterator-based algorithms in
<algorithm>. This is a missed opportunity to take advantage of the template
parameter deduction advantage of range parameters to support chaining.

I shall look at adding this. It may have to be spelled inplace_transform. I
need to consider the impact, backward compatibility, and any potential
confusion over the semantics. There is definitely something to be done to
address this.

Thanks for your report.

Regards,
Neil Groves



> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost