Re: [eigen] Quaternion and expression template

[Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>]

You are right. It really sucks. Even switching to initialization lists and declaring like everything with throw() does not change the issue. 

But coming back to my previous proposal. Why should we implement a destructor when there is nothing to do. I agree, that in some cases it might be required but then we could do that in those cases. The thing is that there is one case left which we ignored. Destrcutors can be trivial (required for objects you want to put in unions, http://stackoverflow.com/questions/1025313/c-will-an-empty-destructor-do-the-same-thing-as-the-generated-destructor) and it is not possible to declare a destructor as such when it is explicitly implemented.

So since tagging with throw() does not help we should get rid of the Matrix destructor as well es the remaining (some specializations already have none) ei_matrix_storage destructors (when possible).

- Hauke

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

Hauke Heibel a écrit :

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().

Yes, I didn't talk about this point in my previous mail, but declaring the destructor of Test as :

inline ~Test() throw() {}

didn't modify the assembly. The code is not inlined. So, the link between rvo, exception handling and the explicit destructor is not clear, and I don't know how where to look.

--
Mathieu