`array_functions(TYPE, NAME)' generates a `new_foo(size)' function that
allocates a new array of the given type. When compiling in C, the array
is initialized with `calloc()', which shows that the intent was to have
the array be zero-initialized. When in C++, however, the array was not
getting initialized, so it could contain random garbage after creation,
when the type was a POD type.
This change makes `new_foo(size)' create a value-initialized array when
in C++, as per the C++ standard's 5.3.4.15 that says that adding a pair
of parentheses at the end of a new-expression does that.
Hi
Would it be possible to add the following 2 typedefs to std_ios.i?
typedef basic_ios<char> ios;
typedef basic_ios<wchar_t> wios;
at present, it contains only
%template(ios) basic_ios<char>;
%template(wios) basic_ios<wchar_t>;
This means however that things like std::ios::openmode are currently not
recognised by SWIG. With the above typedefs, they are. Similar typedefs
should probably be added in std_iostream.i for ostream etc.
Also, while checking std_ios.i, it seems that the definition of basic_ios
has a copy-paste error in the private section (the constructor is still as
ios_base). To avoid confusion, I suggest to change that. Below is a diff
with the suggested changes.
Kris
-- The commit propagates the package option to the newly create
module node so it is recognized by SWIG
-- Added a relativeimport test for this combination
(in lack of py3 I was not able to test it with py3 but it
"should just work")
This doesn't play well with PEP8 checks which imposes very strict continuation
line indentation rules which need to be _visually_ aligned, i.e. the subsequent
lines must be indented by the position of the opening bracket in the function
declaration line, but the code generating the parameter lists doesn't have
this information and so it's impossible to do it while avoiding either E128 or
E123 ("continuation line {under,over}-indented for visual indent" respectively)
error from pep8.
Moreover, the wrapping code didn't work correctly anyhow as it only took into
account the length of the parameter list itself and not the total line length,
which should include the function name as well.
So just disable wrapping entirely, long lines shouldn't be a problem anyhow in
auto-generated code.
* gpetrou-CSharpLicense:
Tweak generated C# .cs files header
Changed CSharp license header to include auto-generated tag so that StyleCop ignores the files.
* yuvalk-master:
Add changes entry for NIOBUFFER Java typemaps
Doc/comment improvements in Java various.i
Add support for java.nio.Buffer including test-suite test case and documentation
This fix takes into account the classname while generating overload
handlers.
Example:
If you have two classes:
class A {
public:
void doSomething(int);
void doSomething(double);
};
class B {
public:
void doSomething(int);
void doSomething(double);
};
Before this patch, the overload handlers for A::doSomething and
B::doSomething create conflicting names and function redefinition errors
are caused.
After the patch, the overload handlers are named classname_doSomething
and no longer conflict.
This is might not the best way to implement this, but it
solves a critical problem on large projects, and specifically can affect
operator overloads that are being wrapped.
Move to construct on first use idiom for singleton definition,
which prevents problems with singletons between ruby swig modules
in an environment with multiple modules on MacOS 10.9 with xcode 5.1.
Before this fix, data was being shared between modules which caused
a crash on shutdown of the ruby interpreter if more than one
module was loaded at a time.
