Open davidtranhq opened 1 year ago
LGTM, anyone else have objections to merging this? Alternatively it could live in cxxshim?
Don't hijack std:: in frigg
Don't hijack std:: in frigg
i.e this could be changed to use the frg
namespace or you could send a PR to cxxshim and put it there instead.
Don't hijack std:: in frigg
yeah, not sure what's preferred here. I wanted it to match the corresponding get
functions that were also overloaded in the std
namespace + thought it fit better in frigg
since the standard library defines these functions in <array>
. Up to the maintainers where they want it to go.
<array>
is included in freestanding in GCC 13. Either use GCC 13 snapshots (and more testing is always nice :) or a hack (though, you'd need to add it to this hack in particular).
Either way, frigg should not clash with the standard, and more conservatively, the standard namespace.
I recommend the GCC 13 route if you can afford using a compiler with potential regressions (and, again, finding and reporting such regressions is invaluable).
oh, also, FTR: adding stuff to std::
is explicitly UB, unless it's to specialize existing templates like is the case for std::get
and std::tuple_{size,element}
, which is why frigg works in hosted environments without this overload added.
C++17 and C++20 defines template functions for deducing the size of C-style arrays. I've found this useful and the implementation is simple (pretty much identical to the implementation on cppreference).