Hey, that's what betas are for, right?
A. I would be interested in learning the rationale was flagBits is a member variable, that is a runtime variable, in the QMatrix4x4 class. See line 191 in: http://qt.gitorious.org/qt/qt/blobs/master/src/gui/math3d/qmatrix4x4.h I would find it more natural to have it as a compile-time known quantity, such as a template parameter or some enum depending ultimately on template parameters, or even to split completely the different cases into completely different classes. To have flagBits be a runtime variable has the following disadvantages: 1) It forces you to do "flagBits = General;" everytime the non-constant mutators are called, such as data() at line 980 and operator()(int,int) at line 273, which means that everytime one wants to write a coefficients, one actually pays for 2 writes. This is still OK if you squarely aim QMatrix4x4 at basic usage only and don't aim to make it useful for advanced use cases. 2) It forces you to do quite some runtime branching in code that would otherwise be free of any runtime branching. Here I don't claim to predict the effect that has on performance, as that is IME often full of surprises, I just wanted to make sure you're aware of that. For example: in operator*= and operator* between matrices. 3) It increases the sizeof(QMatrix4x4), making it less interesting for people who'll have to manage a big array of those. And it require a few extra ops in most methods, making it a bit less fast everywhere. On the other hand, what does it bring to have that flagBits as a runtime variable as opposed to compile-time enum/template param? Is there really a use case where the type of matrix may actually not be known at compile time? Is it to make it all easier for the beginner? Or is it to have slightly smaller binary code in cases where the user makes use of various types of matrices? B. QMatrix4x4 doesn't seem to have 16-byte alignment, right? And neither has QQuaternion? Since this is an ABI question it must be cleared now: you are OK with the idea that you'll probably never get efficient vectorization for these types that are otherwise very suitable for vectorization? On the other hand, it is definitely true that _not_ aligning allows to avoid some tricky issues, since c++98 doesn't have good support for that, so by not aligning you are making the beginner's life easier. *** The general theme here is that you have a design that sacrifices performance but may actually make beginner's life easier, so if that's the target audience for math3d, that seems perfectly fine. Cheers, Benoit _______________________________________________ Qt4-preview-feedback mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt4-preview-feedback
