Date: Tue, 17 Nov 2020 05:17:54 -0800

I know you were speaking to the general, not your specific loop, but with

valaray, that becomes

u = v / std::sqrt( w);

On Tue, Nov 17, 2020 at 2:46 AM Pilar Latiesa via Std-Proposals <

std-proposals_at_[hidden]> wrote:

> Just a question to the C++ experts.

>

> There are some std algorithms that tend to be much more verbose and

> unclear than the plain loop counterpart. For example, compare:

>

> for (std::size_t i = 0; i < v.size(); ++i)

> u[i] = v[i] / std::sqrt(w[i]);

>

> with:

>

> std::transform(v.begin(), v.end(), w.begin(), u.begin(), [](auto a,

> auto b) { return a / std::sqrt(b); });

>

> The introduction of ranges library was a significant improvement:

>

> std::ranges::transform(v, w, u.begin(), std::divides{}, {}, [](auto b)

> { return std::sqrt(b); });

>

> Furthermore, thanks to the current and forthcoming range adaptors,

> we'll be able to use algorithms in pieces of code that weren't

> previously easily expressible with them. For example:

>

> for (std::size_t i = 0; i < v.size(); ++i)

> u[i] = v[i] * y[i] / std::sqrt(w[i]);

>

> might be written:

>

> std::ranges::transform(std::views::zip(v, w, y), u.begin(), [](auto

> &&Proxy) { auto [a, b, c] = Proxy; return a * b / std::sqrt(c); });

>

> The question is: would it be theoretically possible to add overloads

> to the algorithms such that they accept n-ary callables for iterators

> with tuple-like iter_reference_t, where n is

> tuple_size<iter_reference_t>?

>

> I mean:

>

> std::ranges::transform(std::views::zip(v, w, y), u.begin(), [](auto a,

> auto b, auto c) { return a * b / std::sqrt(c); });

>

> or also:

>

> map<string, int> m;

>

> auto sum = std::ranges::accumulate(m, 0, {}, [](auto &, auto i) { return

> i; });

>

> though in this case we'd also have:

>

> auto sum = std::ranges::accumulate(m | std::views::values, 0);

>

> Are there cases in which adding such overloads would cause ambiguities?

>

> Pili

> --

> Std-Proposals mailing list

> Std-Proposals_at_[hidden]

> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

>

valaray, that becomes

u = v / std::sqrt( w);

On Tue, Nov 17, 2020 at 2:46 AM Pilar Latiesa via Std-Proposals <

std-proposals_at_[hidden]> wrote:

> Just a question to the C++ experts.

>

> There are some std algorithms that tend to be much more verbose and

> unclear than the plain loop counterpart. For example, compare:

>

> for (std::size_t i = 0; i < v.size(); ++i)

> u[i] = v[i] / std::sqrt(w[i]);

>

> with:

>

> std::transform(v.begin(), v.end(), w.begin(), u.begin(), [](auto a,

> auto b) { return a / std::sqrt(b); });

>

> The introduction of ranges library was a significant improvement:

>

> std::ranges::transform(v, w, u.begin(), std::divides{}, {}, [](auto b)

> { return std::sqrt(b); });

>

> Furthermore, thanks to the current and forthcoming range adaptors,

> we'll be able to use algorithms in pieces of code that weren't

> previously easily expressible with them. For example:

>

> for (std::size_t i = 0; i < v.size(); ++i)

> u[i] = v[i] * y[i] / std::sqrt(w[i]);

>

> might be written:

>

> std::ranges::transform(std::views::zip(v, w, y), u.begin(), [](auto

> &&Proxy) { auto [a, b, c] = Proxy; return a * b / std::sqrt(c); });

>

> The question is: would it be theoretically possible to add overloads

> to the algorithms such that they accept n-ary callables for iterators

> with tuple-like iter_reference_t, where n is

> tuple_size<iter_reference_t>?

>

> I mean:

>

> std::ranges::transform(std::views::zip(v, w, y), u.begin(), [](auto a,

> auto b, auto c) { return a * b / std::sqrt(c); });

>

> or also:

>

> map<string, int> m;

>

> auto sum = std::ranges::accumulate(m, 0, {}, [](auto &, auto i) { return

> i; });

>

> though in this case we'd also have:

>

> auto sum = std::ranges::accumulate(m | std::views::values, 0);

>

> Are there cases in which adding such overloads would cause ambiguities?

>

> Pili

> --

> Std-Proposals mailing list

> Std-Proposals_at_[hidden]

> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

>

Received on 2020-11-17 07:18:08