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,
> 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,A); // add A into A
> 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
> 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
> 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. :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk