Boost logo

Boost :

Subject: Re: [boost] different matrix library?
From: DE (satan66613_at_[hidden])
Date: 2009-08-17 09:21:54


on 17.08.2009 at 10:30
 joel wrote :
> No, I was speaking of matrix of user defined nuemrical types ;)
> But the discussion on shape is good
oops, my bad

> Yet again, use policy. It'll clutter the code to have 34567 names for
> different object while having the shape as a template policy is
> prolly better. ANd the enforcement of shape semantic has to be implicit
> and static, no need for need_simmetric.

> matrix<float, settings(diagonal)> m;

> For checking arguments of elements with same shape, just use tag
> dispatching or SFINAE instead of concrete typing.

my question is: is a common user able to write just what he wants?
e.g. i want to take as a parameter in my function a diagonal matrix,
shoud i write

    void foo(const matrix<float, settings(symmetric)> &m);

to me it is more convenient to write

    void foo(const symmetric_matrix<float> &m); //it's even shorter

my point is since we need to implement such features why not in a
distinct type? that will provide proper interface to each concrete
featured entity
e.g. a symmetric matrix can have such an interface:

    template<...> //parameters omitted for simplicity
    class symmetric_matrix : public symmetric_matrix_expression<...>
    {
      //...
      explicit symmetric_matrix(size_t size); //since it is square
      //... //there's no need for
      void resize(size_t size); //distinct rows/columns
      //etc... //numbers
    }

so a user will not even be able to write such nonsensical code like

    symmetric1.resize(10, 10); //note unnecessary duplication

because symmetric_matix does not even provide such interface
and will not leave user wandering if he missed the key and typed '(10, 19)'
with unreadable compiler error somewhere in instantiated templates
as far as i know policies can not do this unless it is full
specialized
and the latter i think is equivalent to a distinct type

-- 
Pavel

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk