Glas List: Re: [glas] MTL3 design ? [was MTL project site is up]

From: David Abrahams (dave_at_[hidden])
Date: 2005-02-01 15:55:01

Toon Knapen <toon.knapen_at_[hidden]> writes:

> David Abrahams wrote:
>
>>> And finally (and a bit related to the above), the operator=
>>> for vectors does not require both vectors to have the
>>> same size.
>
>> I haven't written an operator= yet.  If you're basing your remarks on
>> what's in Jeremy's paper, you should know that I don't plan to do
>> everything the same way as he did; not by a long stretch.
>
> Yes my remarks were based on Jeremy's paper.
> When I posted my small initial prototype, you asked why I did not reuse 
> concepts as defined in Jeremy's paper. So I went through the paper and 
> assumed that this paper was the basis of the MTL3 design.

Well, parts of it are ;-)

> Next you mentioned that cooperation between glas and MTL3 would be 
> possible (and I think this would be very interesting). Therefore I 
> tought to start the discussion starting from this paper.

Makes sense.

> But since this paper is apparantly not consistent with the MTL3 design, 
> could you elaborate on the design of MTL3?

We should discuss specifics on a case-by-case basis.  I'm not very far
along with design, but I have _some_ definite ideas.  The ones related
to copy semantics are:

  * except for views and adapters, which explicitly do not own data,
    copy constructors should copy (no "handles").  Rationale: this
    models the well-understood behavior of mathematical primitives.
    Less chance of confusing bugs.

  * assignment operators should always copy.  Views and adapters copy
    over their target elements when assigned.  Rationale: ditto.

  * Efficiency issues can be handled using library implementations of
    move semantics.  "Perfect" move semantics are possible in most
    modern compilers today, and with recent developments in the core
    working group that capability will become mandated
    (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#291)
    and even automatic
    (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#391).
    None of this was available when Jeremy wrote his paper.

  * Issues of views and reference binding (see
    http://www.osl.iu.edu/research/mtl/reference/html/MTL_Object_Model.html)
    can be dealt with by returning const views from adapter
    functions.  For example:

       template <class MatrixType>
       const transpose_view<MatrixType> transpose(MatrixType& m);

    consider:

       typedef transpose_view<matrix<> > t;
       typedef transpose_view<matrix<> const> tc;

    The library supplies t with const member functions and free
    functions accepting t const& that can mutate t's referent matrix.

    The library only supplies tc with const member functions and free
    functions accepting tc const& that cannot mutate tc's referent
    matrix.

This rant has been posted at
http://boost-consulting.com/projects/mtl/html/plan.html#deep-vs-shallow-copy-semantics

As for your concerns here:

> operator= for vectors does not require both vectors to have the same
> size. Thus the lhs will be resized to the size of the rhs. But again
> this poses a problem with stack-based objects because they can't be
> resized. And why actually do you prefer to resize the lhs instead of
> requiring that both vectors have the same size?

I haven't given that question much thought yet, and I don't know
Jeremy's rationale, but I can guess: stack objects with different
sizes also have different types, so we can enforce incompatibility at
compile-time.  We can't do the same with other objects, and there's no
obvious reason to impose an incompatibility restriction.  I can
imagine that it becomes quite inconvenient and even expensive in some
cases.  For example, constructing unity and identity matrices might be
more painful than neccessary.

Jeremy, can you comment on this?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com