Boost logo

Boost :

From: jsiek_at_[hidden]
Date: 2000-01-07 19:48:37


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?

Cheers,

Jeremy

----------------------------------------------------------------------
 Jeremy Siek
 Ph.D. Candidate email: jsiek_at_[hidden]
 Univ. of Notre Dame work phone: (650) 933-8724
 and cell phone: (415) 377-5814
 C++ Library & Compiler Group fax: (650) 932-0127
 SGI www: http://www.lsc.nd.edu/~jsiek/
----------------------------------------------------------------------


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