[boost] Re: nasty design problem

From: scleary_at_[hidden]
Date: 2000-01-11 09:56:31

> So here's a nasty design problem I've been struggling with.  I'm
> curious if anyone can offer a better solution, or give opinions about
> the solutions I've already got.
>
> In MTL often times vector and matrix objects are temporary objects,
> since they are "view" into an existing object. For instance,
>
> A[2]
>
> returns a temporary "row" object that view a part of the matrix.
> Now a typical scenario would be to use this object in a call to
> an MTL algorithm, such as
>
> add(A[3],A[4]); // add A[3] into A[4]
>
> Now this is a bit of a problem if the add function is defined
> with pass-by-reference:
>
> add(const Vec& x, Vec& y);
>
> Since there's a rule that you can't initialize a reference with a
> temporary.
>
> Now, since MTL objects are all handles with shallow copy semantics
> I can instead define the function like this:
>
> add(const Vec& x, Vec y);
>
> However, I'd like to add static-sized matrices to MTL, and
> static-sized matrices can't be handle-based.
>
> Ok, so here are the solutions I've thought of:
>
> 1. The user has to explicitly create handles to the static-sized
>  matricies.
>  Pros: Simple solution
>  Cons: ugly, makes user work more, not generic
>
> 2. Change the second parameter to const Vec&, then cast
>  away the const.
>  Pros: Makes everything work, keeps user syntax clean
>  Cons: Casting away const a questionable practice
>
> 3. Keep the second parameter as Vec& and forces the user
>  to make local variables out of the temporaries.
>  Pros: Works will with non-temporary and non-handle based objects
>  Cons: clutters up user syntax considerably
>
>
> Thoughts? suggestions?
>

You could use a sort of call_traits. . . :)
Specialize for your "row" type, and the rest should be automatic -- choosing
Vec & by default but passing your row type by value.

This wouldn't work for unary functions, though, unless the template
arguments were explicitly specified:
  template <class T>
  void negate(MTL_call_traits<T>::type x);

Maybe a bit messy, but it's an automatic solution.  :)
        -Steve