GCC support for Compile-time string literals

416 Views Asked by At

C++20 introduces Class Types in Non-Type Template Parameters. As mentioned in the proposal, one of the motivations was the compile-time strings, and it enables to do this:

template < size_t size >
struct Literal : std::array<char,size>
{
  constexpr Literal(char const (&str)[size+1]) { for (size_t ii = 0; ii < size; ++ii) (*this)[ii] = str[ii]; }
};
template < size_t size > Literal(char const (&str)[size]) -> Literal<size-1>;
template < Literal literal > constexpr auto operator "" _lit() { return literal; }

template < Literal > struct Use { };
Use<"foo"_lit> use;

The proposal also says:

There have been multiple proposals[N3599][P0424R0] to relax the prohibition on string user-defined literals that take their raw form as individual char template arguments, and so far all of these proposals have failed to gain consensus.

The primary concern that gets raised in response to such proposals is that handling strings as packs of char template arguments is extremely costly in terms of the compiler’s CPU and memory usage, and allowing such UDLs would make very large packs of char values much more common than they are today. This may in turn result in pressure on compiler vendors to make their products perform well under such compile-time string processing workloads, which is difficult due to the strings being represented using a syntax and mechanism that was never intended to support such use cases.

Thus, though not mentioned directly, I assume this proposal was designed to avoid the extremely costly CPU and memory usage for the compilers while dealing with compile-time strings. Maybe this is to be possible because of the mangling approach and using Three-way comparison operator mentioned in the first section of the proposal. Is this assumption correct?

gcc-9.3 doesn't support the Three-way comparison operator but it supports Class Types in Non-Type Template Parameters. However, having compile-time strings in the above mentioned way with gcc-9.3 actually seems to result into extremely costly CPU and memory usage.

Is there any appropriate flag for gcc-9 or gcc-10 that will tune the compiler for such code?

0

There are 0 best solutions below