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 !!
Add custom API to prevent Lua Objects from being garbage collected.
This is intended to for Ardour LuaBridge bindings (~1MB Objects:
tables, functions and userdata).
The bindings are persistent and the gc can skip them in mark & sweep
phases. This is a significant performance improvement for garbage
collection.
Note. The next version of Lua (5.4) will come with a generational-gc
rather than an incremental, so extending the API at this point in time
is acceptable.
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.
Add custom API to prevent Lua Objects from being garbage collected.
This is intended to for Ardour LuaBridge bindings (~1MB Objects:
tables, functions and userdata).
The bindings are persistent and the gc can skip them in mark & sweep
phases. This is a significant performance improvement for garbage
collection.
Note. The next version of Lua (5.4) will come with a generational-gc
rather than an incremental, so extending the API at this point in time
is acceptable.
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.
