For some unknown reason, VC++2019 won't let us take the address of std::list::unique() - although other std::list members seem okay. I've spent weeks tracking this down but there's no fix available AFAICT.
I've flagged it up to the MSVC development team - just don't hold your breath !!
This fixes an crashing issue with ArdourUI.SelectionList a bug
introduced in 6dc3bdf252 and 35dcd46d7d.
Since removal of the special cases in 35dcd46d7d, when using
a C-pointer in a std::list<>,
std::list<class*>::push_back(TypeListValue)
TypeListValues<>'s Head was expanded to "class*& const"
implied by void ::push_back(const T& value);
This resulted in lifetime issues with a classes that derive
from sigc::trackable (e.g. Ardour's Selection).
The reference leaves scope and isn't duplicated when it is pushed back
to the std::list<>.
The script scripts/select_every_2nd_region.lua crashed because entries
in the SelectionList were no longer valid.
Previously (before 6dc3bdf252) TypeListValues explicitly
copy-constructed the value to work around the lifetime issue.
This new solution bypasses the issue by directly using the c-pointer
without dereferencing it.
since 6dc3bdf, a const string reference would leave scope with Lua code
fn("text")
calling a C++
fn (const std::string&)
before the C++ function is called.
Since lua functions are closures, C++ methods that pass arguments by
reference cannot be used directly. The previous approach (boost::ref)
failed with clang. Assume the following:
void foo (float&) { }
static inline float& bar () {
boost::reference_wrapper<float> r (42);
return r.get ();
}
foo ( bar () );
With gcc, "r" goes out of scope after foo's arguments are processed
and all is well.
But with clang, "r" already leave scope when *inlined* bar() returns.
Solution: allocate some user-data on the lua-stack to hold the reference.
There is no reference to this user-data so lua will eventually
garbage collect it.
(theoretically, creating the table which holds the return-values
could trigger an emergency garbage collection when memory is low and
free the reference just while they're being pushed to the table, then
gain FuncArgs<Params> already dereferenced them all as variable on the
C stack -- probably again compiler specific)
in particular: lua-lifefime (!) C++ instances.
This allows for dynamic allocation of custom user-data, bound to
the lifetime of the allocating lua-context.
luabridge uses static fn addresses to identify classes.
Windows uses different addresses for *identical* static functions
in libardour.dll and ardour.exe
This solves the issue by moving the all functions from a
header-only implementation into libardour.
