Open psychocoderHPC opened 1 month ago
Can it be constexpr
?
In general, I do not share the "remove boost at all costs" goal, so to me the new implementation needs to be at least as good as the old one, or possibly better.
std::source_location::current()
is actual pretty well. I think it is more a question if we want remove the compilers, which does not support std::source_location::current()
.
@fwyzard If you want, you can test it here: https://godbolt.org/z/P6MsrKTKv
Update: a more advanced example with namespace: https://godbolt.org/z/159Gs313h
Can it be
constexpr
?
Yes. My minimal example produces only 15 lines assembler including printing: https://godbolt.org/z/YhxKx6n3W
(looks like there is a small bug with the string termination symbol \0
).
Can it be
constexpr
?
Can it be
constexpr
?
It was first constexpr but in some places, it produced some issues.
In general, I do not share the "remove boost at all costs" goal, so to me the new implementation needs to be at least as good as the old one, or possibly better.
I understand, the motivation was always that boost is not testing nvcc and HIP and this produced in the past many issues. Nevertheless this implementation is doing what it should. Removing boost will reduce the test complexity a lot.
Note that GCC and clang produce different output in some cases, for example for std::string
:
the name is: std::__cxx11::basic_string<char>
the name is: std::basic_string<char>
But maybe the old one was also doing this ?
Ah, looks like the two give a different output for inline namespaces.
inline namespace nested {
struct Type {};
}
int main(){
std::cout << "the name is: " << demangled<Type> << '\n';
}
Gives:
the name is: nested::Type
the name is: Type
https://github.com/alpaka-group/alpaka/blob/e20236d86be9a8093fa2efae44eaf2db79dc38db/include/alpaka/core/DemangleTypeNames.hpp#L18-L19
We aim to remove boost completely. With clang 15+ and gcc 11+ we can remove this code with the following code. These versions support
std::source_location
.