[PATCH] Missing zero-argument constructors

[GoogleCodeExporter]

Several methods of btAlignedObjectArray (including one of the constructors), 
assume that the contained type has a callable zero-argument constructor.  
However, a few of the types used with btAlignedObjectArray in various places do 
not meet this requirement (specifically sStkNP, btHashInt, btHashString, 
btHashPtr, and btWheelInfo).

(This is particularly problematic because I am attempting to create a language 
binding for Bullet in PyPy using cppyy, and these instantiation issues cause 
the whole compilation to bomb out if not corrected.)

Attached is a patch (against SVN head) to fix this problem in the headers.  In 
the case of sStkNP, I added a zero-argument constructor consistent with the 
ones that were already there for the other sStkN* classes.  In the case of the 
btHash* classes, I just added default values to use if no arguments were 
supplied.  For btWheelInfo I added an empty constructor for 
btAlignedObjectArray to call (since it's only called in cases where the data 
for the entry is going to be overwritten anyway, leaving the data members 
uninitialized in this case did not seem to be a big issue)..

Original issue reported on code.google.com by foogod@gmail.com on 15 Jan 2014 at 12:47

Attachments:

• bullet_constructor_fixups.patch

[GoogleCodeExporter]

I'll look into it.

Why hasn't this issue been reported earlier? Does the issue only appear when 
you perform such language bindings, but not in regular C++ development?

Original comment by erwin.coumans on 19 Feb 2014 at 6:56

[GoogleCodeExporter]

Thanks..  I assume it hasn't been noticed earlier because the issues only show 
up during template instantiation, which only happens if somebody attempts to 
actually use one of the relevant methods with one of the problem types.  
Unfortunately, since the bindings being produced with cppyy have no idea what 
routines will or won't want to be used by any given Python program, they 
attempt to instantiate everything by default, and thus trigger the issue.

I've actually run into similar issues with the "findBinarySearch", 
"findLinearSearch", and "remove" methods on btAlignedObjectArray as well, 
because they assume that the contained type will have "<", ">", or "==" 
operators, which many don't.  I've managed to work around this by explicitly 
excluding specific cases of those methods one-by-one from the bindings (which 
is ugly, but at least works).

Unfortunately this issue with the constructors is much harder to work around 
because I can't currently figure out a way to exclude just certain constructors 
from the binding (and copy constructors are "contagious" in C++, so even when I 
can exclude them, they get pulled back in and instantiated anyway by the 
(implicit) copy constructors of other classes which contain 
btAlignedObjectArrays as members, and it's all just a big mess)..

Original comment by foogod@gmail.com on 19 Feb 2014 at 10:55

[GoogleCodeExporter]

moved to github tracker here:
https://github.com/bulletphysics/bullet3/issues/56

Original comment by erwin.coumans on 30 Mar 2014 at 4:58

• Changed state: Done