- See Examples/octave/callback/runme.m: a.run() calls Octave callback,
but due to changes in behaviour to subsref() a.Callback.run() can no
longer be used to call C callback unless a.Callback actually exists;
subsrefs() just gets the "Callback" call whereas prior to Octave 4.4
it would get both the "Callback" and "run" calls. So now a.Callback is
set to the original base class (with own=0) so that it can be accessed
Add support so that the %csmethodmodifiers, %dmethodmodifiers,
%javamethodmodifiers can modify the method modifiers for the destructor wrappers
in the proxy class: dispose, Dispose, delete. With this feature, it is now possible
to make a C# proxy class sealed, eg when wrapping a class X, the virtual method modifiers
can be removed using:
%typemap(csclassmodifiers) X "public sealed class"
%csmethodmodifiers X::~X "public /*virtual*/";
Changes the location of the director code wrt to the generated _wrap.h
file to fix throw macro skullduggery in the director_throws testcase
(see previous commit).
Split director_exception testcase into two so that testing throw(),
with no arguments, that is nothrows, can be tested separately to throw()
taking arguments. [The throw keyword needs to be removed for C++
compilation in C++11 and later when it was deprecated.]
Some code in this test case is actually only supported in c++17...
cpp11_lambda_functions_wrap.cxx:275:87: error: the type ‘const<lambda(int, int)>’ of ‘constexpr’ variable ‘lambda18’ is not literal
CONSTEXPR auto lambda18 = [] (int x, int y) mutable TESTCASE_THROW(int) { return x+y; };
^
cpp11_lambda_functions_wrap.cxx:275:28: note: ‘<lambda(int, int)>’ is not literal because:
CONSTEXPR auto lambda18 = [] (int x, int y) mutable TESTCASE_THROW(int) { return x+y; };
^
cc1plus: note: ‘<lambda(int, int)>’ is a closure type, which is only literal in C++17 and later
cpp11_lambda_functions_wrap.cxx:278:89: error: the type ‘const Space1::<lambda(int, int)>’ of ‘constexpr’ variable ‘Space1::lambda19’ is not literal
CONSTEXPR auto lambda19 = [] (int x, int y) mutable TESTCASE_THROW(int) { return x+y; };
1. move the 'no executable found' message up to be with the executable tests
2. test for an (non-)empty GUILE variable for all other conditions after that
An empty GUILE variable means guile is disabled and consistently using the
same test makes the code more readable.
Querying guile-config for the executable name was only introduced in guile 2.0.12.
If it works it's the most reliable method in environments with more than one guile
executable. If it doesn't work fall back to path detection, assuming the executable
name is just 'guile'. If that's incorrect it's up to the caller to explicitly
specify the path to the right guile executable.
