I have encountered many compile-time uses of strings in my projects in the past few years. I would like to summarize my experience today.
Choice of Types
std::string is mostly unsuitable for compile-time string manipulations. There are several reasons:
- Before C++20 one cannot use
strings at all at compile time. In addition, the support for compile-timestrings comes quite late among the major compilers. MSVC was the front runner in this regard, GCC came second with GCC 12 (released a short while ago), and Clang has not yet had a formal release with compile-timestringsupport. - With C++20 one can use
strings at compile time, but there are still a lot of inconveniences, the most obvious being thatstrings generated at compile time cannot be used at run time. Besides, astringcannot be declaredconstexpr. - A
stringcannot be used as a template argument.
So we have to give up this apparent choice, but explore other possibilities. The candidates are:
- const
charpointer, which is what a string literal can naturally decay to string_view, a powerful tool added by C++17: it has similar member functions to those ofstring, but they are mostly marked asconstexpr!array, with which we can generate brand-new strings
We will try these types in the following discussion.
Functions Commonly Needed
Getting the String Length
One of the most basic functions on a string is getting its length. Here we cannot use the C function strlen, as it is not constexpr.
We will try several different ways to implement it.
First, we can implement strlen manually, and mark the function constexpr:
namespace strtools {
constexpr size_t length(const char* str)
{
size_t count = 0;
while (*str != '\0') {
++str;
++count;
}
return count;
}
} // namespace strtools
However, is there an existing mechanism to retrieve the length of a string in the standard library? The answer is a definite Yes. The standard library does support getting the length of a string of any of the standard character types, like char, wchar_t, etc. With the most common character type char, we can write:
constexpr size_t length(const char* str)
{
return char_traits<char>::length(str);
}
Starting with C++17, the methods of char_traits can be used at compile time. (However, you may encounter problems with older compiler versions, like GCC 8.)
Assuming you can use C++17, string_view is definitely worth a try:
constexpr size_t length(string_view sv)
{
return sv.size();
}
Regardless of the approach used, now we can use the following code to verify that we can indeed check the length of a string at compile time:
static_assert(strtools::length("Hi") == 2);
At present, the string_view implementation seems the most convenient.
Finding a Character
Finding a specific character is also quite often needed. We can’t use strchr, but again, we can choose from a few different implementations. The code is pretty simple, whether implemented with char_traits or with string_view.
Here is the version with char_traits:
constexpr const char* find(const char* str, char ch)
{
return char_traits<char>::find(str, length(str),
ch);
}
Here is the version with string_view:
constexpr string_view::size_type find(string_view sv,
char ch)
{
return sv.find(ch);
}
I am not going to show the manual lookup code this time. (Unless you have to use an old compiler, simpler is better.)
Comparing Strings
The next functions are string comparisons. Here string_view wins hands down: string_view supports the standard comparisons directly, and you do not need to write any code.
Getting Substrings
It seems that string_views are very convenient, and we should use string_views wherever possible. However, is string_view::substr enough for getting substrings? This is difficult to answer without an actual usage scenario. One real scenario I encountered in projects was that the __FILE__ macro may contain the full path at compile time, resulting in different binaries when compiling under different paths. We wanted to truncate the path completely so that the absolute paths would not show up in binaries.
My tests showed that string_view::substr could not handle this job. With the following code:
puts("/usr/local"sv.substr(5).data());
We will see assembly output like the following from the compiler (see https://godbolt.org/z/1dssd96vz):
.LC0:
.string "/usr/local"
…
mov edi, OFFSET FLAT:.LC0+5
call puts
We have to find another way. . . .
Let’s try array. It’s easy to think of code like the following:
constexpr auto substr(string_view sv, size_t offset,
size_t count)
{
array<char, count + 1> result{};
copy_n(&sv[offset], count, result.data());
return result;
}
The intention of the code should be very clear: generate a brand-new character array of the requested size and zero it out (constexpr variables must be initialized on declaration before C++20); copy what we need; and then return the result. Unfortunately, the code won’t compile. . . .
There are two problems in the code:
- Functions parameters are not
constexpr, and cannot be used as template arguments. copy_nis notconstexprbefore C++20, and cannot be used in compile-time programming.
The second problem is easy to fix: a manual loop will do. We shall focus on the first problem.
A constexpr function can be evaluated at compile time or at run time, so its function arguments are not treated as compile-time constants, and cannot be used in places where compile-time constants are required, such as template arguments.
Furthermore, this problem still exists with the C++20 consteval function, where the function is only invoked at compile time. The main issue is that if we allow function parameters to be used as compile-time constants, then we can write a function where its arguments of different values (same type) can produce return values of different types. For example (currently illegal):
consteval auto make_constant(int n)
{
return integral_constant<int, n>{};
}
This is unacceptable in the current type system: we still require that the return values of a function have a unique type. If we want a value to be used as a template argument inside a function, it must be passed to the function template as a template argument (rather than as a function argument to a non-template function). In this case, each distinct template argument implies a different template specialization, so the issue of a multiple-return-type function does not occur.
By the way, a standard proposal P1045 tried to solve this problem, but its progress seems stalled. As there are workarounds (to be discussed below), we are still able to achieve the desired effect.
Let’s now return to the substr function and convert the count parameter into a template parameter. Here is the result:
template <size_t Count>
constexpr auto substr(string_view sv, size_t offset = 0)
{
array<char, Count + 1> result{};
for (size_t i = 0; i < Count; ++i) {
result[i] = sv[offset + i];
}
return result;
}
The code can really work this time. With ‘puts(substr("/usr/local", 5).data())’, we no longer see "/usr/" in the compiler output.
Regretfully, we now see how compilers are challenged with abstractions: With the latest versions of GCC (12.1) and MSVC (19.32) on Godbolt, this version of substr does not generate the optimal output. There are also some compatibility issues with older compiler versions. So, purely from a practical point of view, I recommend the following implementation that does not use string_view:
template <size_t Count>
constexpr auto substr(const char* str,
size_t offset = 0)
{
array<char, Count + 1> result{};
for (size_t i = 0; i < Count; ++i) {
result[i] = str[offset + i];
}
return result;
}
If you are interested, you can compare the assembly outputs of these two different versions of the code:
Only Clang is able to generate the same efficient assembly code with both versions:
mov word ptr [rsp + 4], 108
mov dword ptr [rsp], 1633906540
mov rdi, rsp
call puts
If you don’t understand why there are the numbers 108 and 1633906540, let me remind you that the hexadecimal representations of these two numbers are 0x6C and 0x61636F6C, respectively. Check the ASCII table and you should be able to understand.
Since we stopped using string_view in the function parameters, the parameter offset becomes much less useful. Hence, I will get rid of this parameter, and rename the function to copy_str:
template <size_t Count>
constexpr auto copy_str(const char* str)
{
array<char, Count + 1> result{};
for (size_t i = 0; i < Count; ++i) {
result[i] = str[i];
}
return result;
}
Passing Arguments at Compile Time
When you try composing the compile-time functions together, you will find something lacking. For example, if you wanted to remove the first segment of a path automatically (like from "/usr/local" to "local"), you might try some code like the following:
constexpr auto remove_head(const char* path)
{
if (*path == '/') {
++path;
}
auto start = find(path, '/');
if (start == nullptr) {
return copy_str<length(path)>(path);
} else {
return copy_str<length(start + 1)>(start + 1);
}
}
The problem is still that it won’t compile. And did you notice that this code violates exactly the constraint I mentioned above that the return type of a function must be consistent and unique?
I have adopted a solution described by Michael Park: using lambda expressions to encapsulate ‘compile-time arguments’. I have defined three macros for convenience and readability:
#define CARG typename
#define CARG_WRAP(x) [] { return (x); }
#define CARG_UNWRAP(x) (x)()
‘CARG’ means ‘constexpr argument’, a compile-time constant argument. We can now make make_constant really work:
template <CARG Int>
constexpr auto make_constant(Int cn)
{
constexpr int n = CARG_UNWRAP(cn);
return integral_constant<int, n>{};
}
And it is easy to verify that it works:
auto result = make_constant(CARG_WRAP(2));
static_assert(std::is_same_v<integral_constant<int, 2>,
decltype(result)>);
A few explanations follow. In the template parameter, I use CARG (instead of typename) for code readability: it indicates the intention that the template parameter is essentially a type wrapper for compile-time constants. Int is the name of this special type. We will not provide this type when instantiating the function template, but instead let the compiler deduce it. When calling the ‘function’ (make_constant(CARG_WRAP(2))), we provide a lambda expression ([] { return (2); }), which encapsulates the constant we need. When we need to use this parameter, we use CARG_UNWRAP (evaluate: [] { return (2); }()) to get the constant back.
Now we can rewrite the remove_head function:
template <CARG Str>
constexpr auto remove_head(Str cpath)
{
constexpr auto path = CARG_UNWRAP(cpath);
constexpr int skip = (*path == '/') ? 1 : 0;
constexpr auto pos = path + skip;
constexpr auto start = find(pos, '/');
if constexpr (start == nullptr) {
return copy_str<length(pos)>(pos);
} else {
return copy_str<length(start + 1)>(start + 1);
}
}
This function is similar in structure to the previous version, but there are many detail changes. In order to pass the result to copy_str as a template argument, we have to use constexpr all the way along. So we have to give up mutability, and write code in a quite functional style.
Does it really work? Let’s put the following statement into the main function:
puts(strtools::remove_head(CARG_WRAP("/usr/local"))
.data());
And here is the optimized assembly output from GCC on x86-64 (see https://godbolt.org/z/Mv5YanPvq>):
main:
sub rsp, 24
mov eax, DWORD PTR .LC0[rip]
lea rdi, [rsp+8]
mov DWORD PTR [rsp+8], eax
mov eax, 108
mov WORD PTR [rsp+12], ax
call puts
xor eax, eax
add rsp, 24
ret
.LC0:
.byte 108
.byte 111
.byte 99
.byte 97
As you can see clearly, the compiler will put the ASCII codes for "local" on the stack, assign its starting address to the rdi register, and then call the puts function. There is absolutely no trace of "/usr/" in the output. In fact, there is no difference between the output of the puts statement above and that of ‘puts(substr("/usr/local", 5).data())’.
I would like to remind you that it is safe to pass and store the character array, but it is not safe to store the pointer obtained from its data() method. It is possible to use such a pointer immediately in calling other functions (like puts above), as the lifetime of array will extend till the current statement finishes execution. However, if you saved this pointer, it would become dangling after the current statement, and dereferencing it would then be undefined behaviour.
String Template Parameters
We have tried turning strings into types (via lambda expressions) for compile-time argument passing, but unlike integers and integral_constants, there is no one-to-one correspondence between the two. This is often inconvenient: for two integral_constants, we can directly use is_same to determine whether they are the same; for strings represented as lambda expressions, we cannot do the same—two lambda expressions always have different types.
Direct use of string literals as non-type template arguments is not allowed in C++, because strings may appear repeatedly in different translation units, and they do not have proper comparison semantics—comparing two strings is just a comparison of two pointers, which cannot achieve what users generally expect. To use string literals as template arguments, we need to find a way to pass the string as a sequence of characters to the template. We have two methods available:
- The non-standard GNU extension used by GCC and Clang (which can be used prior to C++20)
- The C++20 approach suitable for any conformant compilers (including GCC and Clang)
Let’s have a look one by one.
The GNU Extension
GCC and Clang have implemented the standard proposal N3599, which allows us to use strings as template arguments. The compiler will expand the string into characters, and the rest is standard C++.
Here is an example:
template <char... Cs>
struct compile_time_string {
static constexpr char value[]{Cs..., '\0'};
};
template <typename T, T... Cs>
constexpr compile_time_string<Cs...> operator""_cts()
{
return {};
}
The definition of the class template is standard C++, so that compile_time_string is a valid type and, at the same time, by taking the value member of this type, we can get "Hi". The GNU extension is the string literal operator template—we can now write ‘"Hi"_cts’ to get an object of type compile_time_string. The following code will compile with the above definitions:
constexpr auto a = "Hi"_cts; constexpr auto b = "Hi"_cts; static_assert(is_same_v<decltype(a), decltype(b)>);
The C++20 Approach
Though the above method is simple and effective, it failed to reach consensus in the C++ standards committee and did not become part of the standard. However, with C++20, we can use more types in non-type template parameters. In particular, user-defined literal types are amongst them. Here is an example:
template <size_t N>
struct compile_time_string {
constexpr compile_time_string(const char (&str)[N])
{
copy_n(str, N, value);
}
char value[N]{};
};
template <compile_time_string cts>
constexpr auto operator""_cts()
{
return cts;
}
Again, the first class template is not special, but allowing this compile_time_string to be used as the type of a non-type template parameter (quite a mouthful😝), as well as the string literal operator template, is a C++20 improvement. We can now write ‘"Hi"_cts’ to generate a compile_time_string object. Note, however, that this object is of type compile_time_string, so "Hi"_cts and "Ha"_cts are of the same type—which is very different from the results of the GNU extension. However, the important thing is that compile_time_string can now be used as type of a template parameter, so we can just add another layer:
template <compile_time_string cts>
struct cts_wrapper {
static constexpr compile_time_string str{cts};
};
Corresponding to the previous compile-time string type comparison, we now need to write:
auto a = cts_wrapper<"Hi"_cts>{};
auto b = cts_wrapper<"Hi"_cts>{};
static_assert(is_same_v<decltype(a), decltype(b)>);
Or we can further simplify it to (as compile_time_string has a non-explicit constructor):
auto a = cts_wrapper<"Hi">{};
auto b = cts_wrapper<"Hi">{};
static_assert(is_same_v<decltype(a), decltype(b)>);
Summary
In this blog I have discussed two things:
- Compile-time string manipulations
- Strings as non-type template parameters
They have proved to be useful in my real projects. When having time, I will explore some usages later. Stay tuned!
Yongwei’s Blog 