btVector3 and others not initialized to (0,0,0) by default?!

[ill]

Is there a reason why the default constructor for things like btVector3 doesn't initialize it to (0,0,0). I've written vector classes before and my implementations always had the constructor look something like this: Vector3(float x = 0.0f, float y = 0.0f, float z = 0.0f) so it would by default initialize the coords to (0,0,0)

I've been assuming it does and I finally got to test my game with Valgrind and found an amazing amount of uninitialized value errors because of this. Now every time I use a btVector3 I have to manually go in and set it to (0,0,0)? I have a lot of places where btVector3 objects are member variables of functions.

[Flix]

I believe that this is done for speed (and not only for btVector3, for btQuaternion and btTransform too).

[hymerman]

Hah, I just ran into the exact same problem! Except it manifested itself in setting collision shapes with vertices in crazy far away positions, resulting in rigid bodies that didn't move. Very hard to find.

"Performance" is not a good reason for this, in my opinion. There should be a default constructor (as 80% of users will probably find useful), and those 20% looking to improve performance should initialise on creation.

[Flix]

"Performance" is not a good reason for this, in my opinion. There should be a default constructor (as 80% of users will probably find useful), and those 20% looking to improve performance should initialise on creation.

It's always possible to extend these classes to get the behavior you're looking for in a backward compatible way (this is what I'm currently doing with the btTransform class). Some of the Bullet demos were probably made to show the performance of the library with a lot of bodies, and (maybe) that can be the reason of such a choice, but I agree with you (I like efficiency more than speed). Initialise on creation is good, but not comfortable in many cases (containers?).

[RBD]

"Performance" is not a good reason for this, in my opinion. There should be a default constructor (as 80% of users will probably find useful), and those 20% looking to improve performance should initialise on creation.

Inventing stats does not make it true . Performance is a great reason in this case, we are all looking for real-time performance from Bullet. But relatively, a disproportionate number of btVector3 are used in arrays, (i.e.: btAlignedObjectArray<btVector3>), it's not necessary to spend time initializing every btVector3 in these potentially large arrays to 0,0,0 before they will be loaded with data. It's very normal that a data type is not initialized, it's like that with all C data types, if you want it set to zero, then you initialize it to zero, just like you do a basic int (or any other basic C type). No need to impose overhead on everyone else.

[hymerman]

Sure, I understand why it's been done that way, I'm just saying I'd prefer a default constructor (and guessing that most other users would too). But then I like to do convoluted things like fill containers using std::generate or std::transform instead of default constructing and overwriting, to gain performance when I need to. I didn't mean literally 80% and 20%, I was just paraphrasing the 80/20 rule, but that wink tells me you know that