On Sat, Mar 21, 2009 at 9:55 AM, Benoit Jacob
<jacob.benoit.1@xxxxxxxxx> wrote:
Hi,
at the moment there are 2 issues in Eigen 2.0 that can make us
considering breaking the ABI for 2.1
First of all, since Eigen is pure template, it doesn't have an ABI by
itself. So what I am speaking of, is the ABI of binary libraries
exposing Eigen objects.
In any case, we must not break the ABI after the 2.1 release (e.g.
libavogadro wants a stable ABI, and will make their 1.0 release soon).
The question is whether it's still OK to break the ABI between 2.0 and
2.1.
Here are the reasons why I'm considering breaking the ABI.
1) (the main reason). The "Options" template parameter to the Matrix
class is a bit-field, with one bit controlling RowMajor/ColMajor
storage, and another bit controlling automatic alignment. The default
is column-major and automatic alignment. We made a mistake in Eigen
2.0: the value 0 corresponds to NO automatic alignment. This means
that if you want a RowMajor matrix and you pass just "RowMajor" as the
Options parameter, then you don't get automatic alignement ... you
have to pass RowMajor|AutoAlign if you want automatic alignment. What
this means is that people using row-major fixed-size vectorizable
matrices can be puzzled as to why they don't get vectorization. The
obvious solution is to set AutoAlign=0 and
DontAlign=the_corresponding_bit. However this means that in a binary
library, functions taking Matrix arguments will have a different
mangled name, so this change breaks the ABI.
2) See this bug report:
http://forum.kde.org/strange-bug-for-large-fixed-sized-matrices-t-38426.html
Basically, a user had a fixed-size 100x100 matrix, so the size was
10000, which gave him errors as 10000 is the value of our constant
Dynamic. So we have 2 options:
a) we can enforce a hard limit on fixed-sizes, e.g. size <= 4096;
b) or we can change the value of Dynamic.
If we do b), that breaks the ABI, as Dynamic is often used as a
template parameter for the Matrix class template.
We've already discussed possible values for Dynamic; the obvious
choice of -1 is dangerous as e.g. a condition like this,
SizeAtCompileTime <= 16
would be satisfied by all dynamic-size matrices; whence our choice of
a large positive value; but then since we're often squaring this
value, in order to avoid integer overflow we don't want to go above
sqrt(MAX_INT) which is roughly 46000; also, we want a value that's
easily recognizable in backtraces and compiler output; finally, the
above bug report shows that this value shouldn't be a square (10000 =
100^2) and more generally should be a prime number; so I propose
33331.
Well, there is always the option of finally setting Dynamic=-1 but
then we have to be extremely careful, not only at the time we make
this change, but ever after! Perhaps some helper macros would help
then.
I don't have a strong opinion between a) and b) but again the big
drawback of b) is breaking the ABI.
Cheers,
Benoit