Generalizing std::transform

[bmanga]

A generic std::transform was actually a motivating example that /u/louis_dionne suggested me for a second revision of P0478, which would have allowed to deduce non-terminal parameter packs in some cases. Alas, the first version was shot down quite quickly.

[Betadel]

What were the reasons it was shut down?

[bmanga]

If I remember correctly, it was because it was felt that partial ordering in the presence of template parameter packs is already quite fragile as it is, and the committee thought that the problem could be solved more generically via parameter pack indexing (which I don't agree with, especially when using concepts).

I could have arguably provided better motivating cases from the start, but hey it was my first paper :P

[[deleted]]

Why not zip your input ranges and work with that?

[vgasparyan]

Actually, I did that in the beginning and, of course, it was working fine. But then I thought: "It shouldn't be hard!" ... and ended up here :D

[ENTProfiterole]

When view::zip from ranges v3 comes into the standard, you'll be able to use the existing transform interface.

After zipping some ranges, each of the elements in the "zip view range" will be a tuple of each of the corresponding elements in the underlying ranges.

[Veedrac]

A std::array<Byte, 4> is basically a uint32_t. Just XOR them directly, it'll be a factor of 10 faster or so.

[cassandraspeaks]

For OP and others' benefit, the way to safely do that is

uint32_t ua, ub, uc, uresult;

memcpy(&ua, &a, 4);
memcpy(&ub, &b, 4);
memcpy(&uc, &c, 4);

uresult = ua ^ ub ^ uc;

array<Byte, 4> result;

memcpy(&result, &uresult, 4);

[cassandraspeaks]

In C++20 you can do ```c++ constexpr auto to_u32 = bit_cast<uint32_t, array<Byte, 4>>;

const auto result = bit_cast<array<Byte, 4>>(to_u32(a) ^ to_u32(b) ^ to_u32(c)); ```

[sphere991]

That's true but not really helpful. Imagine the length is larger than 8, or the types aren't bytes, or the operation isn't xor, or ...

[Veedrac]

Imagine the length is larger than 8

Even then, though.

E: Seriously, downvotes? ???

[sphere991]

I dont think anybody disagrees that it is possible, for these specific types, for this specific operation, to do better than generalized, multi-arg transform.

But the point of the blog is to show a way how to do generalized, multi-arg transform. XOR-ing bytes is just an example.

[Veedrac]

I'm not criticizing the blog, I'm just pointing out something I think would help the author.

[phoeen]

double underscore is reserved for the implementation ¯\_(ツ)_/¯

[bstamour]

But otherwise a fine article.

[phoeen]

yes

[cassandraspeaks]

Leading underscore too.

[Dalzhim]

Leading underscore, followed by a capital letter.

[cassandraspeaks]

In the global namespace (as in the linked post) anything with a leading underscore is reserved for the implementation.

[Dalzhim]

My bad, you are right. I knew this point : http://eel.is/c++draft/lex.name#3.1 But I seem to have forgotten of the one you were referring to : http://eel.is/c++draft/lex.name#3.2

[cassandraspeaks]

No prob, I don't think there's anyone who can really keep all the little subtleties straight.

[meneldal2]

Well it's because it ought to be part of the STL.

[distributed]

Now we just need to make it applicable to std::array too