Re: [eigen] still the solve() API debate

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

2009/9/21 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> On Mon, Sep 14, 2009 at 11:29 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> void swap(typename ei_ref_to_temporary<MatrixBase<OtherDerived> >::type
>> other);
>
> It's done... though for some reason buggy (thus again a patch) and currently
> I am too blind to see the issue. But first things first. I added two new
> CMake flags, as discussed with Benoit
>
> a) EIGEN_TEST_RVALUE_REF_SUPPORT (enable rvalue references only in the unit
> tests, not supported on MSVC)
> b) EIGEN_TEST_C++0x (enable C++0x features in general, again unit tests only
> due to missing config file)
>
> Regarding a), I am not sure whether we should look up how to check the
> actual compiler versions. GCC supports this feature since 4.3 (correct me if
> I am wrong)

you're right :) See here:
http://gcc.gnu.org/projects/cxx0x.html

> and MSVC will starting from version VC10.

Yes, it's probably a good idea to enable using c++0x features
automatically when the compiler supports them and the user enabled
c++0x mode. We already do exactly the same for a lot for non-standard
features such as SIMD intrinsics, so why not also here.

This would go into Core/util/Macros.h.

>
> [........]
>
> p.s. What do you think about using CMake in order to create a
> system/compiler specific configuration file - if somebody want's to use it?

I was considering that not having a configured header was a feature,
not a lack. Indeed, we were so far able to do all our platform checks
with the preprocessor, so the result was the same, and we got the
flexibility of not having a configured header, which is very useful in
some circumstances, like when testing different compilers.

It seems to me that the real use case for configured headers is to
detect if particular libraries are installed and to test for functions
that they provide when that isn't possible with the preprocessor. As
long as we can do what we need with the preprocessor, let's do it...

Introducing an optional configured header would also require us to
ask, everytime a user reports an error, "did you use a configured
header", "try rerunning cmake", etc...

Let me make a counter proposal: we could offer a tool that generates a
configured header for tuning Eigen for the specific host machine,
instead of the platform. That can't be done with #ifdefs. For example,
that tool would detect the cache size and define
EIGEN_TUNE_FOR_CPU_CACHE_SIZE accordingly. The header wouldn't be
automatically included, the user would have to #include it explicitly
before #including eigen.

Benoit