Date: Sat, 29 Aug 2020 18:35:13 -0600

Perhaps a type trait is a suitable alternative for this (as opposed to

introducing yet another keyword that decorates a function signature). For

example: https://godbolt.org/z/ecaro9

On Sat, Aug 29, 2020 at 6:03 PM Tobias W. via Std-Discussion <

std-discussion_at_[hidden]> wrote:

> Hi everyone!

> I am coming with a mathematical and embedded systems background and

> there is something that bothered me since I started programming.

> Firstly, I would like to explain the problem with an example that occurs

> often in slightly different but similar ways.

> Secondly, I will propose a possible solution.

> Of course, I would love to hear your thoughts.

> So let's imagine we have three classes.

> class Real{

> double value;

> ...

>

> };

>

> class Imag{

> double value;

> ...

>

> }

>

> class Complex{

> double Im;

> double Re;

> ...

>

> };

>

> Then if I was to write functions, for example, an add function or

> operator+ and would like to add them in all possible permutations of

> arguments.

> This means, that I would have to write all those following functions,

> just to add them:

>

> Complex operator+ (Real a, Imag b);

> Complex operator+ (Imag b, Real a); // Mirrored function

> Complex operator+ (Real a, Complex b);

> Complex operator+ ( Complex b, Real a); //Mirrored function

> Complex operator+ (Imag a, Complex b);

> Complex operator+ ( Complex b, Imag a); //Mirrored function

>

> From a mathematical point of view, all mirrored functions are obsolete,

> because the intent has already been stated in the function above.

> Furthermore, each mirrored function will use additional program memory

> and this can become an issue on embedded devices.

> Therefore I would like to introduce the idea of the expression

> "commutative" that can be added to functions.

> The commutative expression will tell the compiler that he can switch the

> parameters that will be passed to a function.

> Following this, the keyword will only be allowed for functions that

> possess two and only two parameters.

> Then the example from above may look something like this:

>

> commutative Complex operator+ (Real a, Imag b);

> commutative Complex operator+ (Real a, Complex b);

> commutative Complex operator+ (Imag a, Complex b);

>

> If the compiler comes across a statement like below, he is allowed to

> restructure the code.

>

> Complex = Complex * Imag + Real;

>

> will change to:

>

> Complex = Real + Imag * Complex;

>

> and now the three commutative functions can be used to process this

> command.

>

> This is far less to write, the intent is clear, fewer functions are used

> and I only pay for the programme memory I need.

> This, of course, is not allowed to change the evaluation order of

> operator* and operator+. The operator* will always be evaluated first

> and the operator+ will always work with its result.

> The operator+ is not allowed to steal one of the operator* 's parameters.

> commutative will, of course, be available for all functions that take 2

> parameters, not just operators.

>

> These are my thoughts, as already stated above, I would love to hear yours.

>

> Sincerely,

> Tobias Wallner

>

> --

> Std-Discussion mailing list

> Std-Discussion_at_[hidden]

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

>

introducing yet another keyword that decorates a function signature). For

example: https://godbolt.org/z/ecaro9

On Sat, Aug 29, 2020 at 6:03 PM Tobias W. via Std-Discussion <

std-discussion_at_[hidden]> wrote:

> Hi everyone!

> I am coming with a mathematical and embedded systems background and

> there is something that bothered me since I started programming.

> Firstly, I would like to explain the problem with an example that occurs

> often in slightly different but similar ways.

> Secondly, I will propose a possible solution.

> Of course, I would love to hear your thoughts.

> So let's imagine we have three classes.

> class Real{

> double value;

> ...

>

> };

>

> class Imag{

> double value;

> ...

>

> }

>

> class Complex{

> double Im;

> double Re;

> ...

>

> };

>

> Then if I was to write functions, for example, an add function or

> operator+ and would like to add them in all possible permutations of

> arguments.

> This means, that I would have to write all those following functions,

> just to add them:

>

> Complex operator+ (Real a, Imag b);

> Complex operator+ (Imag b, Real a); // Mirrored function

> Complex operator+ (Real a, Complex b);

> Complex operator+ ( Complex b, Real a); //Mirrored function

> Complex operator+ (Imag a, Complex b);

> Complex operator+ ( Complex b, Imag a); //Mirrored function

>

> From a mathematical point of view, all mirrored functions are obsolete,

> because the intent has already been stated in the function above.

> Furthermore, each mirrored function will use additional program memory

> and this can become an issue on embedded devices.

> Therefore I would like to introduce the idea of the expression

> "commutative" that can be added to functions.

> The commutative expression will tell the compiler that he can switch the

> parameters that will be passed to a function.

> Following this, the keyword will only be allowed for functions that

> possess two and only two parameters.

> Then the example from above may look something like this:

>

> commutative Complex operator+ (Real a, Imag b);

> commutative Complex operator+ (Real a, Complex b);

> commutative Complex operator+ (Imag a, Complex b);

>

> If the compiler comes across a statement like below, he is allowed to

> restructure the code.

>

> Complex = Complex * Imag + Real;

>

> will change to:

>

> Complex = Real + Imag * Complex;

>

> and now the three commutative functions can be used to process this

> command.

>

> This is far less to write, the intent is clear, fewer functions are used

> and I only pay for the programme memory I need.

> This, of course, is not allowed to change the evaluation order of

> operator* and operator+. The operator* will always be evaluated first

> and the operator+ will always work with its result.

> The operator+ is not allowed to steal one of the operator* 's parameters.

> commutative will, of course, be available for all functions that take 2

> parameters, not just operators.

>

> These are my thoughts, as already stated above, I would love to hear yours.

>

> Sincerely,

> Tobias Wallner

>

> --

> Std-Discussion mailing list

> Std-Discussion_at_[hidden]

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

>

Received on 2020-08-29 19:38:54