DE wrote:
for expression classes only shapes to be concerned: rectangular, symmetric, upper- and lower-triangular what i forgot?
I'm not sure you doesn't want to specialize on other thing. But maybe we can have an hybrid solution : named expression for shape + tempalte policy for the remaining. In the same vein, maybe either to have them be expression<Xpr, diagonal> than diagonal_expression<Xpr> so you can use partial tempalte specialization for matching them 'en masse'
example? Well see the Design rationale for boost::parameters but every unique entity can provide perfectly reasonable interface for just that entity e.g. a sparse matrix can provide non_zero_count() which will return the actual number of stored values furhtermore similar entities may (and must) be factored so there will be no code duplication
Hmm, then we really need soemthign hybrid (CRTP+Policy) CRTP leverage the raw things, Policy specialize them.
arguments?
See earlier but now it's maybe not that much valid -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35