compared to C++03 with gcc 5.x or 6.x.
May be related: About a year ago I wrote a constexpr-string library for
myself. The idea was to provide string manipulation functions like search,
replace, etc at compile time. This would then allow me to build and express
SQL queries in type-safe code and tie them to program logic (i.e. the
queries could be expressed as chains of constexpr functions). I was testing
on apple clang.
Initially all went well. Intermediate strings where never produced in the
assembler output and when the compiler needed the address of the resulting
string, it would place the parts of the resulting string in data sections.
Perfect.
Then I tested with gcc. This was a disaster. Whenever a constexpr string
was used, the compiler would build it on the stack, explicitly initialising
it.
I actually found that gcc produced better code when string literals were static
const and not constexpr.
What I took away from this was either,
1. I was pushing beyond the intended boundaries of constexpr and clang was
just happy to oblige, or
2. gcc's code generation involving constexpr objects is a little suspect.
On 2 January 2018 at 09:24, Hans Dembinski via Boost
Hi John,
On 31. Dec 2017, at 20:50, John Maddock via Boost
wrote: Folks I have a very strange issue that I need help with understanding, it comes from https://github.com/boostorg/multiprecision/issues/32 but in summary:
There is a 20-30% slowdown when compiled in C++11 or later compared to C++03 with gcc 5.x or 6.x.
I am not able to answer you, I just also want to say it is weird. I thought that making things constexpr should not change run-time code emitted by the compiler at all.
Best regards, Hans
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost