Re: [eigen] Quaternion and expression template

[Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>]

Ok, I know what you mean. Then just to get things right we might try the following when explicitly defining the destructor.

According to 15.4.13 Exception specifications, the implicitly generated destructor will be tagged as throw() (i.e. it does not throw) when all used destructors are tagged with throw(). This seems to be the case for Matrix (only in some cases). Let's take a look. MatrixBase and ei_special_scalar_op_base have implicitly generated destructors and no data and thus their destructors will be tagged with throw(). So none of the base classes may prevent the Matrix destructor from being tagged with throw(). The only class we are depending on is ei_matrix_storage. Here, fixed size matrices and the null matrix have implicitly generated destructors and thus they will be tagged with throw() and consequently Matrix's implicitly generated destructor would be tagged with throw().

So, to come to a point. We should add throw() to the destructor of Matrix and to all destructors of ei_matrix_storage. I am wondering why this is working like this at all. Actually, many books state that destructors may never throw. This makes very much sense since throwing while deleting an object may cause memory leaks which cannot be prevented. Here is just one citation telling that destructors should never throw (http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.3).

And I have to think about all the private destructors I added recently because the issue Benoit described happened all over the lib. I hope they are not crucial - at least I should tag them with throw().

- Hauke

On Tue, Dec 1, 2009 at 10:29 AM, Mathieu Gautier <mathieu.gautier@xxxxxx> wrote:

I'm a bit afraid of infering such rules from experiments, because for
example, i remember adding a default ctor to SVD in the 2.0 branch
because for some user, MSVC failed to generate a default constructor
automatically. Just saying that it's scary because compilers can have
very erratic behavior.

How about instead saying that all that is a good reason to actually do
xpr templates for Quaternion? After Hauke and Gael merge their
branches, the small performance argument should be gone. Also, Gael's
idea for reusable Xpr classes should apply there too, allowing to do
that without writing any new xpr class.

I agree, any solution is better than relying on observation of VS compiler behavior.

--
Mathieu