Using constexpr structs as template parameters

[marsh sage]

Only MSVC manage to compile this (while still printing an Intellisense error!)
Didnt manage to compile that with neither clang or gcc using godbolt

https://godbolt.org/z/5PK7vaoeo

any idea how to make that work for the other compilers? The two fields in the Argument struct are required (a void lambda with no parameters would work too instead of T), same for the compile time hash computation, required.

[bleak basin]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question run !howto ask.

[ebon notch]

Clang and GCC have smaller recursion depth limits than MSVC

So, they hit that limit compiling your recursive constexpr functions

[marsh sage]

This has nothing to do with recursion depth, the function already fail to compile on those compilers with a single template param, which happens to have zero recursion happening

[ebon notch]

Then add a template argument

or use parentheses to explicitly call the variadic overload

afaik

[marsh sage]

well actually sorry, it does recurse with fnv1a_32, but like the string is so small, how can it hit recursion depth already

[ebon notch]

write it in a iteration, maybe this will fix your issue

[marsh sage]

I'm pretty sure the issue is elsewhere though (different compilers being picky about how to write templates), I guess I can simplify the fnv1a func just for the repro case and make it return a fixed value

[ebon notch]

do that

[upper sonnet]

what is the purpose of the code?

you can't really use string literals in NTTPs afaik

this compiles on gcc: https://godbolt.org/z/Yxcq65TT1

this compiles on gcc and clang: https://godbolt.org/z/5Kdesxfq3

[marsh sage]

Oh my god, it works perfectly, thanks a lot, I thought string literals were gonna be fine since my assumption was that they are just static storage in the resulting assembly

[marsh sage]

The purpose of the code is that in our code base we have a long list of such strings (they are ultimately used as a way of representing an array of bytes that we later need to find in a binary file), and instead of having to find them each time our program is ran, we later cache the result as offsets from the start of the file, but I couldnt figure a nice way to invalidate the cache if any of those strings changed/added/removed (I guess a proper alternative solution would be to use external tools+version control heh?) so I thought about having a hash that would change at compile time if any of the strings were modified by a dev

[bleak basin]

@marsh sage Has your question been resolved? If so, run !solved :)