Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Awesome compile-time evaluation proposal

76 views
Skip to first unread message

Christian Gollwitzer

unread,
Oct 6, 2017, 2:37:29 AM10/6/17
to
Hi,

I've just watched the recent talk from Herb Sutter:

https://www.youtube.com/watch?v=4AfRAVcThyA

Wow, this is awesome. I've been wondering for years why C++ has such an
odd way to do metaprogramming, either you can use the outdated
preprocessor, which has no knowledge of types and can't even express a
simple loop without hardcore trickery, or you are stuck with an abuse of
the type system which is even more impenetrable.

Finally, there is a sane proposal on the table, and they even have a
prototype implementation in clang.

Christian

David Brown

unread,
Oct 6, 2017, 2:48:17 AM10/6/17
to
I haven't looked at the video link, but I'm guessing you are talking
about metaclasses. (Why do people post links like this with no
explanation or information? I guess it is from the generation brought
up on pads and youtube as their main source of information. I greatly
prefer to /read/ stuff - varying the speed to match my interest as I go.)

Yes, metaclasses look like a fantastic idea that will open up a whole
lot of new ways to work in C++. I look forward to them.

But in the meantime, there is a lot that has happened in C++
metaprogramming between C++98 templates and now. Templates have
improved in a variety of ways, and "constexpr" functions - especially
with their updates in C++14 - give you a great deal. Yes, you can make
loops - with no trickery at all, just write the loop in a constepxr
function. And for the brave, gcc has concepts support tracking the
planned C++20 feature.

Christian Gollwitzer

unread,
Oct 6, 2017, 3:31:43 AM10/6/17
to
Am 06.10.17 um 08:48 schrieb David Brown:
> On 06/10/17 08:37, Christian Gollwitzer wrote:
>> Hi,
>>
>> I've just watched the recent talk from Herb Sutter:
>>
>> https://www.youtube.com/watch?v=4AfRAVcThyA
>>
>> Wow, this is awesome. I've been wondering for years why C++ has such an
>> odd way to do metaprogramming, either you can use the outdated
>> preprocessor, which has no knowledge of types and can't even express a
>> simple loop without hardcore trickery, or you are stuck with an abuse of
>> the type system which is even more impenetrable.
>>
>> Finally, there is a sane proposal on the table, and they even have a
>> prototype implementation in clang.
>>
>> Christian
>
> I haven't looked at the video link, but I'm guessing you are talking
> about metaclasses. (Why do people post links like this with no
> explanation or information? I guess it is from the generation brought
> up on pads and youtube as their main source of information. I greatly
> prefer to /read/ stuff - varying the speed to match my interest as I go.)

I'm sorry if this wasn't obvious enough. The talk is indeed about
metaclasses, but this metaclass thing rests upon an extended "constexpr"
which allows to emit code. So it is about compile-time code generation.
I posted the video link merely because I haven't seen it elsewhere.
There is a link on this youtube page to a github repo with the slides:
https://github.com/CppCon/CppCon2017/blob/master/Keynotes/Meta%20-%20Thoughts%20on%20Generative%20C%2B%2B/Meta%20-%20Thoughts%20on%20Generative%20C%2B%2B%20-%20Herb%20Sutter%20-%20CppCon%202017.pdf

I couldn't find a paper-like write-up for the talk.

>
> Yes, metaclasses look like a fantastic idea that will open up a whole
> lot of new ways to work in C++. I look forward to them.
>
> But in the meantime, there is a lot that has happened in C++
> metaprogramming between C++98 templates and now. Templates have
> improved in a variety of ways, and "constexpr" functions - especially
> with their updates in C++14 - give you a great deal. Yes, you can make
> loops - with no trickery at all, just write the loop in a constepxr
> function. And for the brave, gcc has concepts support tracking the
> planned C++20 feature.

I haven't been following it too closely, but for instance such a beast:

https://codereview.stackexchange.com/questions/133668/constexpr-sin-function-c-14

drives me away. Do I really need to build my own sine function to be
able to use it in a constexpr? In order to get a trigonometric lookup
table currently I'm using a different language to generate C++ code,
which is of course not satisfying.

There is another talk about extending constexpr in this conference:
https://www.youtube.com/watch?v=PJwd4JLYJJY


Christian

David Brown

unread,
Oct 6, 2017, 5:00:19 AM10/6/17
to
No, you don't need your own sine function - it seems to be fine to use
std::sin in constexpr functions. (I use the phrase "seems to be fine",
because it works in practice when I tested it, but I am not sure if the
standards guarantee it is correct.) Here is an example - it generates a
sine table with int16_t entries, such as one might want in a small
embedded system:

#include <stdint.h>
#include <cmath>

constexpr double const_sine(double x) {
return std::sin(x);
}

const auto pi = 3.14159265358979323846264338327;
const auto pi2 = 2 * pi;

template<class T, int N> struct array {
T elems[N];

constexpr T& operator[](size_t i) {
return elems[i];
}
constexpr const T& operator[](size_t i) const {
return elems[i];
}
};

const auto size = 128;
using Table = array<int16_t, size>;

constexpr Table makeTable() {
Table t{};
for (auto i = 0; i < size; i++) {
const auto angle = (i * pi2 / size);
const auto s = const_sine(angle);
t[i] = 32767 * s;
}
return t;
}

extern const Table sine_table = makeTable();

Ben Bacarisse

unread,
Oct 6, 2017, 6:18:51 AM10/6/17
to
David Brown <david...@hesbynett.no> writes:

> On 06/10/17 09:31, Christian Gollwitzer wrote:
>> Am 06.10.17 um 08:48 schrieb David Brown:
>>> On 06/10/17 08:37, Christian Gollwitzer wrote:
<snip>
>>>> https://www.youtube.com/watch?v=4AfRAVcThyA
<snip>
>>> ... I greatly prefer to /read/ stuff - varying the speed to match
>>> my interest as I go.)

Me too. Video seems to me to a dreadful way to convey technical
information. It makes sense to have conferences about things, but the
old way was always to have published proceedings.

<snip>
>> I couldn't find a paper-like write-up for the talk.

There's this:

https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf

but it's not about the talk. It's a detailed technical description of
the proposal (presumably and early version).

<snip>
>> I haven't been following it too closely, but for instance such a beast:
>>
>> https://codereview.stackexchange.com/questions/133668/constexpr-sin-function-c-14
>>
>> drives me away. Do I really need to build my own sine function to be
>> able to use it in a constexpr? In order to get a trigonometric lookup
>> table currently I'm using a different language to generate C++ code,
>> which is of course not satisfying.
>
> No, you don't need your own sine function - it seems to be fine to use
> std::sin in constexpr functions. (I use the phrase "seems to be fine",
> because it works in practice when I tested it, but I am not sure if the
> standards guarantee it is correct.)

clang says no and gcc says yes. These are all with -std=c++14 and
-pedantic (plus warning flags) to try to get standard conformance
without extensions.

clang says (of your example)

constexpr double const_sine(double x) {
^
t.cc:6:12: note: non-constexpr function 'sin' cannot be used in a constant
expression
return std::sin(x);
^

> Here is an example - it generates a
> sine table with int16_t entries, such as one might want in a small
> embedded system:
>
> #include <stdint.h>
> #include <cmath>
>
> constexpr double const_sine(double x) {
> return std::sin(x);
> }
>
> const auto pi = 3.14159265358979323846264338327;
> const auto pi2 = 2 * pi;

gcc wants these to be constexpr -- my gcc version (5.4.0) won't compile
the example without it -- but clang is not bothered. I wonder what's up
here. Neither gcc not clang compiled the example without change but for
different reasons. Am I missing some option?

(gcc also objects to size_t not being defined. I never know what
headers are obliged to define size_t and which ones are not, but I added
cstddef to be sure.)

<snip>
--
Ben.

David Brown

unread,
Oct 6, 2017, 6:38:59 AM10/6/17
to
Yes, I have just tried that, and got the same results. I also note that
std::sin is not specified as "constexpr" in the standards (it's always
hard to add that kind of thing as an afterthought, especially if "errno"
may be involved).

>
> clang says (of your example)
>
> constexpr double const_sine(double x) {
> ^
> t.cc:6:12: note: non-constexpr function 'sin' cannot be used in a constant
> expression
> return std::sin(x);
> ^
>
>> Here is an example - it generates a
>> sine table with int16_t entries, such as one might want in a small
>> embedded system:
>>
>> #include <stdint.h>
>> #include <cmath>
>>
>> constexpr double const_sine(double x) {
>> return std::sin(x);
>> }
>>
>> const auto pi = 3.14159265358979323846264338327;
>> const auto pi2 = 2 * pi;
>
> gcc wants these to be constexpr -- my gcc version (5.4.0) won't compile
> the example without it -- but clang is not bothered. I wonder what's up
> here. Neither gcc not clang compiled the example without change but for
> different reasons. Am I missing some option?

-std=gnu++14 or -std=c++14 should be all you need (it's the default for
later gcc versions).

>
> (gcc also objects to size_t not being defined. I never know what
> headers are obliged to define size_t and which ones are not, but I added
> cstddef to be sure.)
>

Testing on godbolt.org gave complaints on missing size_t for some
versions, and not others - varying according to version and target.
Adding <cstddef> sounds like a good idea.

I did not manage to get gcc to complain about pi and pi2 not being
constexpr, no matter which options I tried.


But the conclusion is that std::sin is not guaranteed by the standards
to be usable in constexpr like this, which is a shame - it is exactly
the kind of function people would want to use for building tables. Even
the simple:

constexpr auto pi = 4 * std::atan(1);

works in gcc, but not clang.

Time to moan to the C++ standards people, I think!



Ben Bacarisse

unread,
Oct 6, 2017, 7:29:24 PM10/6/17
to
David Brown <david...@hesbynett.no> writes:
<snip>
> I did not manage to get gcc to complain about pi and pi2 not being
> constexpr, no matter which options I tried.

Curious. It turns out to be -fsanitize=undefined that causes this:

$ g++ -std=c++14 -fsanitize=undefined -c t.cc
t.cc: In function ‘constexpr Table makeTable()’:
t.cc:34:1: error: the value of ‘pi2’ is not usable in a constant expression
}
^
t.cc:10:12: note: ‘pi2’ was not declared ‘constexpr’
const auto pi2 = 2 * pi;

(And it's an error, not just a warning.) If you make pi2 constexpr, you
get the same message about pi.

I was not aware that -fsanitize=undefined altered the language that g++
compiles, but it seems to. Maybe g++ detecting and complaining about
undefined behaviour in code that is "run" at compile time?

<snip>
--
Ben.

Alf P. Steinbach

unread,
Oct 6, 2017, 9:53:16 PM10/6/17
to
On 10/6/2017 9:31 AM, Christian Gollwitzer wrote:
> Am 06.10.17 um 08:48 schrieb David Brown:
>> On 06/10/17 08:37, Christian Gollwitzer wrote:
>>> Hi,
>>>
>>> I've just watched the recent talk from Herb Sutter:
>>>
>>>      https://www.youtube.com/watch?v=4AfRAVcThyA
>>>
[snip]
> I posted the video link merely because I haven't seen it elsewhere.
> There is a link on this youtube page to a github repo with the slides:
> https://github.com/CppCon/CppCon2017/blob/master/Keynotes/Meta%20-%20Thoughts%20on%20Generative%20C%2B%2B/Meta%20-%20Thoughts%20on%20Generative%20C%2B%2B%20-%20Herb%20Sutter%20-%20CppCon%202017.pdf
>
>
> I couldn't find a paper-like write-up for the talk.

<url: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf>

My poor Thunderbird's inbox quickly filled up with comment notices after
Herb posted the following, so I was able to find it quickly now :) :

<url:
https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-generative-c/>

Strangely, I haven't read it. I'm of the firm opinion that we need many
things fixed before introducing even more language in the language, so
to speak. E.g. I'd like const+non-const member function support, ideally
integrated with support for covariant features (like used for e.g. a
clone function, which now is redefined textually identically in every
derived class). And modules of course. And real UTF-8 support, which
involves a notion of detectable execution character set. Maybe at long
last recognizing the reality of shared (dynamically loaded) libraries.
There's lots that needs fixing, and committee's attention & time is very
limited...

Superbly better car information system, with built-in network radio &
integration with emergency services, yep that's good.

But wheels and carriage and engine most important IMHO.


Cheers & hth.,

- Alf

David Brown

unread,
Oct 9, 2017, 8:45:20 AM10/9/17
to
That /is/ strange. I don't make much use of the -fsanitize options
(they are not well supported in small embedded systems). It is
reasonable for a compiler to allow looser but "sensible" syntax with
some compiler options and have tighter control with other options, but
usually you'd expect that sort of change when choosing -std=c++XXX
instead of -std=gnu++XXX, or -Wpedantic. I am very happy that gcc gives
better support for constexpr than the standards require (it's cmath
functions are declared as constexpr, at least in the setups I tried).
But I'd rather it did so by saying in the manual that this is a gcc
extension feature and they will guarantee to keep it in -std=gnu++XXX
modes, instead of it being something that just happens to work.

David Brown

unread,
Oct 9, 2017, 9:03:16 AM10/9/17
to
I'd recommend you do read this proposal. Metaclasses can't come soon
enough. It is not part of the car entertainment system - it is a new
way to design bits for the car. It will let you build new types of
wheels, or swap them for caterpillar tracks or a hoverboard. If we had
had metaclasses from the beginning, then "class", "struct", "union" and
"enum" would not be part of the language and compiler, they would be
part of the standard library. The potential here is /that/ big.

But I don't know if it would fix your const + non-const problem, or your
UTF-8 support!


Richard

unread,
Oct 9, 2017, 11:57:18 AM10/9/17
to
[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
<or9c22$j3f$1...@dont-email.me> thusly:

><url: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf>
>
>My poor Thunderbird's inbox quickly filled up with comment notices after
>Herb posted the following, so I was able to find it quickly now :) :
>
><url:
>https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-generative-c/>
>
>Strangely, I haven't read it. I'm of the firm opinion that we need many
>things fixed before introducing even more language in the language, so
>to speak. [...]

Herb's point is that people are doing this already, but in a clumsy
way and rather than add new extensions to the language one by one,
he'd rather add one thing that results in user libraries that can be
tested, developed and shipped without further modification to the
standard. 'interface' is the big one that wins.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

woodb...@gmail.com

unread,
Oct 14, 2017, 11:41:58 PM10/14/17
to
On Monday, October 9, 2017 at 10:57:18 AM UTC-5, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
> <or9c22$j3f$1...@dont-email.me> thusly:
> >
> >Strangely, I haven't read it. I'm of the firm opinion that we need many
> >things fixed before introducing even more language in the language, so
> >to speak. [...]
>
> Herb's point is that people are doing this already, but in a clumsy
> way and rather than add new extensions to the language one by one,
> he'd rather add one thing that results in user libraries that can be
> tested, developed and shipped without further modification to the
> standard. 'interface' is the big one that wins.


Other than C++ 2011, there's not a lot to cheer
about. Too many cooks spoil the soup.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net


0 new messages