I'm currently working on using cppyy (http://doc.pypy.org/en/latest/cppyy.html) to generate bindings for calling Bullet from within pypy. So far everything has gone fairly smoothly (I've even successfully written a Python version of the "hello world" program and have proceeded to cover a majority of the rest of the Bullet API as well), but there is one issue I've encountered on a few classes:
It appears that if some classes (specifically, mostly those that use HashMaps) are instantiated directly, the compiler really doesn't like it. An example can be demonstrated by simply attempting to compile the following:
Code: Select all
#include <btBulletDynamicsCommon.h>
int main (void) {
btDefaultSerializer s = btDefaultSerializer();
}
Code: Select all
$ g++ test.cpp -o test -I/usr/local/include/bullet
In file included from /usr/local/include/bullet/BulletCollision/CollisionDispatch/btCollisionObject.h:33:0,
from /usr/local/include/bullet/BulletCollision/CollisionDispatch/btCollisionWorld.h:76,
from /usr/local/include/bullet/btBulletCollisionCommon.h:22,
from /usr/local/include/bullet/btBulletDynamicsCommon.h:20,
from test.cpp:1:
/usr/local/include/bullet/LinearMath/btAlignedObjectArray.h: In instantiation of ‘btAlignedObjectArray<T>::btAlignedObjectArray(const btAlignedObjectArray<T>&) [with T = btHashInt; btAlignedObjectArray<T> = btAlignedObjectArray<btHashInt>]’:
/usr/local/include/bullet/LinearMath/btHashMap.h:220:7: required from here
/usr/local/include/bullet/LinearMath/btAlignedObjectArray.h:142:4: error: no matching function for call to ‘btHashInt::btHashInt()’
/usr/local/include/bullet/LinearMath/btAlignedObjectArray.h:142:4: note: candidates are:
In file included from /usr/local/include/bullet/BulletCollision/CollisionShapes/btTriangleInfoMap.h:20:0,
from /usr/local/include/bullet/BulletCollision/CollisionShapes/btBvhTriangleMeshShape.h:22,
from /usr/local/include/bullet/btBulletCollisionCommon.h:35,
from /usr/local/include/bullet/btBulletDynamicsCommon.h:20,
from test.cpp:1:
/usr/local/include/bullet/LinearMath/btHashMap.h:82:2: note: btHashInt::btHashInt(int)
/usr/local/include/bullet/LinearMath/btHashMap.h:82:2: note: candidate expects 1 argument, 0 provided
/usr/local/include/bullet/LinearMath/btHashMap.h:78:7: note: btHashInt::btHashInt(const btHashInt&)
/usr/local/include/bullet/LinearMath/btHashMap.h:78:7: note: candidate expects 1 argument, 0 provided
Now, I will admit it's been a while since I've done anything really in-depth in C++, but digging around it does appear to me that the compiler may have a valid point: btDefaultSerializer contains several btHashMaps (which use btHashInts/etc as keys). The btHashMap<Key, Value> declaration includes members of type btAlignedObjectArray<Key> (and <Value>), which expands to btAlignedObjectArray<btHashInt>, etc. However, the way the copy constructor (and copyFromArray) of btAlignedObjectArray<T> is written, it calls "resize(otherSize)", not specifying a second parameter. This results in an implicit reference to "T()", which means that any type which is to be used in a btAlignedObjectArray (and by extension, any type used as a key or value to btHashMap) needs to have a zero-argument constructor (which btHashInt and friends don't have) or the template instantiation will bomb out..
However, given that my C++ is a little rusty, and I'm not really familiar with the Bullet internals at all, I wanted to post a general query: Is this a genuine bug, or am I missing something, or is this deliberate for a non-obvious reason?
If it's a bug, it seems to me it would be fairly easy to fix (by just changing "btHashInt::btHashInt(int uid)" to btHashInt::btHashInt(int uid = 0)" (and similar for btHashString, btHashPtr, btHashKeyPtr, and btHashKey)). I'd be happy to submit a patch, if this is indeed a reasonable change to make..
Thanks,
--Alex