Re: [ublas] Generic traits for scalars

From: Michael Stevens (mail_at_[hidden])
Date: 2005-07-11 05:31:08

On Monday 11 July 2005 10:05, Dima Sorkin wrote:
> Quoting Michael Stevens <mail_at_[hidden]>:
> > On Sunday 10 July 2005 11:11, Dima Sorkin wrote:
> > > I meant that it would be nice to have such traits class
> > > (or classes) ,**as a part of user interface**,to enable the
> > > use of any types of "scalars" with ublas.
> >
> > Agreed. Is this 'just' a documentation issue?
> >
> > Michael
>
> Hi.
>  Yes and no.
>  It is first of all a documentation issue, but not just this.
>
>  Today (I still use 1.31 :)),ublas functions do not accept traits_class
> as template type-parameter from the user/caller, but rather assume that
> traits class with the right name will be present at the right scope at
> the point of binding (instantiation) of the template.
> This practice seems odd to me,for the following reasons:
> 1 - Such a dependency is not so stable and may lead to compilation
>     problems (Following the discussion of this issue in B.Stroustrup
>     book "C++ prog. language")
> 2 - to define such traits class for my "scalar", I need to intervene
>     into ublas namespace.

Agreed. The namespace intrusion required to user define a type_traits is very 
nasty.

I'm not sure that adding a template type_parameter to each ublas function 
would be such a good idea. In syntax overhead of adding such to the hundreds 
of functions which could potentially make use of such a parameter would seem 
to outway the benefits.

What is the current Boost best practice in providing such extensible traits 
classes? One possibility is to provide the traits as a template argument to 
the containers. These ultimately determine how various operations are 
performed.

Since the norms are really what we require it would seem that Andrew's 
argument for simply using free function templates is a strong one. (Andrew - 
Hopefully I have understood you correctly in this regard)

> 3 - When I tried to understand the structure of ublas traits classes,
>     I found there traits3 on traits2::type on traits1::type chains of
>     type calculations (closure_traits etc, which I didn't suceeded to
>     understand). Here no documentation will help.
>     So this chain of traits calculations must be begun with some simple
>     traits_class accepted as template argument from user/caller.
>     And this simple traits_class that starts the whole chain should
>     be documented first of all.
>
> So, if I am right, it is also question of changing ublas interface,
> soon or later.
Agreed.

        Michael