Re: [eigen] MSVC inlining - just FYI

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

Interesting!

How about adding this MSVC warning to DisableMSVCWarnings.h at least
by default; if you want you can add a preprocessor option to keep it
and a CMake option to enable that in the unit tests.

After all, there are many reasons that may prevent a compiler from
inlining a function, and they don't usually emit warnings about that.

Benoit

2009/12/17 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> Hi all,
>
> So, after some reading I was able to find out the following things I'ld
> quickly like to share.
>
> There was a recent discussion regarding the inlining problem on
> comp.lang.c++.moderated
>
> http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/e286bba27402a9e1/ff59c4e78f93e9ab?lnk=raot
>
> The problem which is affecting us is that MSVC does not inline functions
> returning an unwindable object (an object having a non-trivial destructor or
> an object having members with non-trivial destructors). Here is an example
> where the __forceinline is ignored unless exception handling is disabled.
>
> template <typename T>
> struct UnwindableTemplate
> {
>   T* m_data;
>
>   UnwindableTemplate() : m_data(0)
>   {
>   }
>
>   ~UnwindableTemplate()
>   {
>     delete [] m_data;
>   }
> };
>
> template <typename T>
> __forceinline UnwindableTemplate<T> create_unwindable()
> {
>   return UnwindableTemplate<T>();
> }
>
> void main ()
> {
>   UnwindableTemplate<float> unwind = create_unwindable<float>();
> }
>
> Here, I choose the unwindable object to mimik our ei_matrix_storage classes
> for the particular case when we are dealing with dynamic sized objects. As a
> consequence, this leads to the fact that functions returning expressions
> containing matrix members by value will not be inlined. Currently it seems
> as if this can not be remedied. Returning a reference to a local temporary
> seems tempting since we are anyways trying to enforce inlining but I would
> refrain from such a solution and say we just live with it.
>
> It seems as if with newer compiler versions the SSE issue mentioned in the
> forum is fixed and not our actual problem.
>
> Regards,
> Hauke
>
>