Phil Bouchard
Founder & CTO
C.: (819) 328-4743
With C++ ranges today you can do :
auto const ints = {0,1,2,3,4,5,6};auto d = ints | views::transform([](int x) { return x*2; });
This is great but it'll need to support 2D / 3D / 4D / ... matrices cleanly also.
auto const mat = {{0,1},{2,3},{4,5},{6,7}};
For parallel computation it'll need to either:
- Apply maths in parallel across the entire piping sequence, element by element, row by row, vector by vector or matrix by matrix or etc.:
auto res = mat | /* operation 1 */ views::transform([](int x) { return x*2; }) | /* operation 2 */ views::transform([](int x) { return x-2; }) | /* operation 3 */ views::transform([](int x) { return x^2; });
The final "res" here will be filled up in parallel, like if op 1
+ op 2 + op 3 is one giant function running in parallel
- Or apply maths in parallel at each piping operation:
auto res = mat | /* operation 1 */ views::transform([](int x) { return x*2; }) | /* operation 2 */ views::transform([](int x) { return x-2; }) | /* operation 3 */ views::transform([](int x) { return x^2; });
The final "res" here will be filled up with 3 sequential parallel functions, or one parallel function at the time.
Definitely.You're right, I did read very quickly on this but it's the standard OR operator being used differently:
Well, I think that is a "good thing" if the language allows you to reuse the syntax (operator overload) through library implementations without changing the compiler.
So there would seem be be a need here since this is not yet implemented if I am right.
Not yet, but being flexible to convert from ranges to *ANY* kind of container may be challenging...
We are also trying to avoid macros... they are not module-friendly, not bounded to the type system, among many other issues:
BRCleiton
So anyway it's important the C++ remains extensible enough to
support these parallel operations sooner or later.