Date: Sun, 14 Jun 2020 13:56:42 +0200
Hi Arthur
Thank you for your comments.
(See an updated version on https://github.com/zingsheim/ProposalTernary
Fold/blob/progress/ProposalTernaryFold.md)
The f<is>() example in fact was the realistic starting example which
initiated the proposal.
It makes it easy to write an alternative to std::visit where the
compiler is able to inline the function calls.
https://gcc.godbolt.org/z/waSAfn
Note: Such a kind of visit would not be standard conform since it is
not O(1) in the non-optimized version.
However, I did not want to add this example to the proposal since
complier optimizers improve over time and maybe the next generation of
compilers will be able to inline the function calls of std::visit,
too.
(See for initial question on reddit https://www.reddit.com/r/cpp/commen
ts/7pya5s/stdvisit_overhead/)
> (2) You say "initial value" several times when you mean "final value".
T
he reason why I called it initial is the recursion which is build up to
generated the code for ( C ? E : ... : I )
(I)
(C(N) ? E(N) : (I))
(C(N-1) ? E(N-1) : (C(N) ? E(N) : (I)))
(C(N-2) ? E(N-2) : (C(N-1) ? E(N-1) : (C(N) ? E(N) : (I))))
...
But maybe this is a to much mathematically centric view, and "initial expression" would be a better term anyhow.
However, looking at this from the programmers point of view as a recursion which stops at a final expression, the wording "final expression" might be better.
(C(1) ? E(1) : (...))
(C(1) ? E(1) : (C(2) ? E(2) : (...)))
(C(1) ? E(1) : (C(2) ? E(2) : (C(3) ? E(3) : (...))))
...
(C(1) ? E(1) : (C(2) ? E(2) : (C(3) ? E(3) : (... (C(N) ? E(N) : F))))
Furthermore, in the first proposal P1012R0 https://github.com/zingsheim/ProposalTernaryFold/blob/P1012R0/ProposalTernaryFold.md there was a comparison to binary fold expressions and in a fold like (values + ... + 0) you would call the 0 the initial value and not the final value.
However, since the conditional operator is the only ternary operator in C++ the wording "final expression" might be more suitable or even "default expression", since it is comparable to the "default:" of a "switch" statement. What do you think?
To you comments to the + on the string_view you are right (what should
the + return, definitely not a string_view).
But do you know why std::string + std::string_view does not work and
one has to use std::string.append instead?
Anyhow I tried to check the code with Compiler Explorer again. I was a
little bit sloppy with changes which I thought were only minor changes.
But there is always room for mistakes.
Unfortunately, I am only a user of C++ and am not capable to program
the proposal in Clang myself. It would be nice if I could do especially
it would reduce the work to the Clang developers as soon as the
proposal is accepted.
For the hyperlinks I tried to add them. They work on Typora (a markdown
editor) but unfortunately they do not work on Github (https://github.co
m/zingsheim/ProposalTernaryFold/blob/progress/ProposalTernaryFold.md).
Do you know what might be wrong with their formating?
Thanks again for your support
Frank
>
Thank you for your comments.
(See an updated version on https://github.com/zingsheim/ProposalTernary
Fold/blob/progress/ProposalTernaryFold.md)
The f<is>() example in fact was the realistic starting example which
initiated the proposal.
It makes it easy to write an alternative to std::visit where the
compiler is able to inline the function calls.
https://gcc.godbolt.org/z/waSAfn
Note: Such a kind of visit would not be standard conform since it is
not O(1) in the non-optimized version.
However, I did not want to add this example to the proposal since
complier optimizers improve over time and maybe the next generation of
compilers will be able to inline the function calls of std::visit,
too.
(See for initial question on reddit https://www.reddit.com/r/cpp/commen
ts/7pya5s/stdvisit_overhead/)
> (2) You say "initial value" several times when you mean "final value".
T
he reason why I called it initial is the recursion which is build up to
generated the code for ( C ? E : ... : I )
(I)
(C(N) ? E(N) : (I))
(C(N-1) ? E(N-1) : (C(N) ? E(N) : (I)))
(C(N-2) ? E(N-2) : (C(N-1) ? E(N-1) : (C(N) ? E(N) : (I))))
...
But maybe this is a to much mathematically centric view, and "initial expression" would be a better term anyhow.
However, looking at this from the programmers point of view as a recursion which stops at a final expression, the wording "final expression" might be better.
(C(1) ? E(1) : (...))
(C(1) ? E(1) : (C(2) ? E(2) : (...)))
(C(1) ? E(1) : (C(2) ? E(2) : (C(3) ? E(3) : (...))))
...
(C(1) ? E(1) : (C(2) ? E(2) : (C(3) ? E(3) : (... (C(N) ? E(N) : F))))
Furthermore, in the first proposal P1012R0 https://github.com/zingsheim/ProposalTernaryFold/blob/P1012R0/ProposalTernaryFold.md there was a comparison to binary fold expressions and in a fold like (values + ... + 0) you would call the 0 the initial value and not the final value.
However, since the conditional operator is the only ternary operator in C++ the wording "final expression" might be more suitable or even "default expression", since it is comparable to the "default:" of a "switch" statement. What do you think?
To you comments to the + on the string_view you are right (what should
the + return, definitely not a string_view).
But do you know why std::string + std::string_view does not work and
one has to use std::string.append instead?
Anyhow I tried to check the code with Compiler Explorer again. I was a
little bit sloppy with changes which I thought were only minor changes.
But there is always room for mistakes.
Unfortunately, I am only a user of C++ and am not capable to program
the proposal in Clang myself. It would be nice if I could do especially
it would reduce the work to the Clang developers as soon as the
proposal is accepted.
For the hyperlinks I tried to add them. They work on Typora (a markdown
editor) but unfortunately they do not work on Github (https://github.co
m/zingsheim/ProposalTernaryFold/blob/progress/ProposalTernaryFold.md).
Do you know what might be wrong with their formating?
Thanks again for your support
Frank
>
Received on 2020-06-14 06:59:55