The "any tuple-like" thing was nice but
it was confusing when passing for example
a std::string, which is a typedef to a
tuple-like thing. Making a custom
ConstructorParameters struct is more clear
both to users and to the compiler.
But there is a bug in meson currently that makes it so that
neon is never detected on aarch64 so the generic crc32
implementation is always chosen. Not a big deal right now.
It will fix itself once meson fixes their bug.
Following what's been suggested on IRC libera.chat #mesonbuild,
this is so that the -march=generic+crc option only applies to
the code it should apply to and not to the entire code base.
Crc is used as an optimisation for operator==, which is legit.
Either way, the struct's size would still be 16 even without
the crc (the variable would just became an always 0 "reserved").
Crc's use is limited to here anyways, so for now it's not
harming anyone.
Upon testing (and reading), getting the address of a static
is safe even across .so boundaries. Moreover it doesn't incur
into the risk of collisions, unlike hashes, and also works
with different classes with the same name (for example from
two different unnamed namespaces). At this point the crc32
stuff is pretty much redundant, I'll try to remove it next.
This commit breaks the ARM64 version, I will fix it next.
Lots going on here. DynafuncMaker got updated to store strings
to back the ModuleAndName objects that get hardcoded in the
assembly glue function.
ModuleAndName is not a typedef to a tuple anymore, because I
discovered that tuples suck. They get always pushed on the stack
when passed as parameter, instead the new implementation gets
passed into 2 registers being it a standard layout type.
dhandy::bt::string got updated so it can be used as a literal
value for non-type template parameters, which allowed for a
really easy to use `wren::MN<>` helper. Code now fully requires
c++20.
No need to have two versions of this.
Static assert when users specify ambiguous overloads.
Currently overloads are discriminated only by
parameter count, not types, so we need to enforce this.
I think this is the opposite of the code I'm working on
now, ie it's not called by wren to create a c++ object
but from c++ to create a wren object. I'll add an
example for this.
