Re: [eigen] proposal to use static const integer class members instead o

Thanks a lot, now I understand. And, rereading Marc's messages, he was giving the same example, of which I missed the point. Sorry and thanks to both of you for the explanation.

It's very counter-intuitive that this works for enums but not for inline-defined static consts. The only reason why it works for enums is that when passing an enum to a function taking a const int&, a temporary is constructed and passed by const reference, while when passing a static const int by const reference, the compiler doesn't construct a temporary... how sad.

Anyway, my proposal seems pretty much dead at this point. Eigen's constants have been public and passable by const reference for years, so surely people are depending on it now, and we shouldn't break them. As to the idea of inheriting from an integral_constant struct, as far as I can see, Eigen doesn't have anywhere to put the definition of such structs, since it is headers-only, contrary to libc++ / libstdc++.

Benoit

2014-12-13 12:51 GMT-08:00 Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>:

On 13.12.2014 20:57, Marc Glisse wrote:

Hopefully someone else on the list can tell us in what way we are
misunderstanding each other.

Indeed, you can't pass a const static int member without an external definition to a function expecting (const int&). That means, with the proposed changes it wouldn't be possible anymore to pass VectorXd::ColsAtCompileTime to a function expecting (const int&):
http://ideone.com/K26A41 (reduced example)

It is, however, still possible to use those as template parameters for other classes. See plusOne struct in this example:
http://ideone.com/twvYCa
Admittedly, I'm not entirely sure if that must be possible in C++98/03/11, or if the compiler vendor can decide on that.

So the main questions are whether the first thing shall be working, and if the benefits of `const static int` vs `enum` outweigh that.
Saving all the int castings would indeed significantly clean up our internal code, but I doubt that we'd get any significant simplification from user's perspective.

Christoph

--
----------------------------------------------
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: +49 (421) 218-64252
----------------------------------------------