On Mon, Jan 11, 2010 at 7:42 PM, Benoit Jacob
<jacob.benoit.1@xxxxxxxxx> wrote:
2010/1/11 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> The point c) ... well, it's related to a) and b). Unifying the access to
> class properties (traits) has the chance of improving readability and
> navigability.
The biggest purpose of ei_traits<...> is forward-declarations.
Actually, at some point, I named it ForwardDecl<...>. The idea is that
with our CRTPs, when we want to access Derived::SomeTypedef from
MatrixBase<Derived>, we can't, because Derived isn't fully declared at
that point, so we put SomeTypedef instead in ei_traits<Derived>. Does
that help? Should ei_traits be renamed?
It wasn't primarily about the understanding. I think the naming ei_traits is perfect. I was wondering about things as this here (found e.g. in ProductBase)
typedef typename Lhs::Nested LhsNested;
typedef typename ei_cleantype<LhsNested>::type _LhsNested;
...
Sometimes, _expression_ helpers are used explicitly and sometimes they are just indirectly. For the sake of clarity I would have preferred something like
typedef typename ei_nested<Lhs>::type LhsNested;
typedef typename ei_cleantype<LhsNested>::type _LhsNested;
...
Here, I know right away where to look for the type behind LhsNested. For the other case, I first have to browse to the file corresponding to the 'Lhs' type, then I have to search for the 'Nested' typedef, which might be again redirecting to another class. Since I am lacking the possibility to create the pre-compiled code with MSVC, it would just allow me faster navigation.
- Hauke