|
|
Ublas : |
Subject: Re: [ublas] Assignement operation proposal.
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2010-04-12 08:43:06
Nasos Iliopoulos <nasos_i <at> hotmail.com> writes:
>Because though the order of evaluation is not guaranteed for comma operator
>this overload on matrix and vector types may be problematic and in general
>comma overloading on types that do other jobs also is generally not
>recommended. Also a bit more verbose interface maye be needed to signify that
>this returns a vector or matrix.
I am having a tough time seeing where the , operload could get us in trouble
unless some ublas type implemented it for some other nefarious purpose.
Wouldn't ADL pick things up properly otherwise??
>I would love to have this feature if the above problem can be faced somehow.
>Any other ideas of how this suggestion could be implemented would be very
>helpful
>return stack() <<= v1, v2;
This sounds reasonable to me for return types, though I think we need to think
through the word "stack()" here since it might be more general than that. For
example, it would also convert vectors to matrices.... Is the general case
of this making a composite perhaps? "composite()"
But I went:
auto m = v1, v2;
auto m <<= v1, v2; //Perhaps this is fine as well
What would m be and could it then be used like a normal expression or confuse
users? I think this sort of usage is inevitable with C++0X.
Also, does that mean to call a function with stacked vectors in my original
function would look like this?:
ublas::matrix<double> m = func1( (stack() <== v1, v2) );
I suppose that isn't so bad and could even make the code happening clearer.
>I thought of overloading operator =, but it didn't look as a good choice,
>since it would interfere with expression templates.
I hear you. And doing a quick look at eigen2 and MTL4, they don't seem to use
operator= either (though your implementation is much more flexibile).
Even boost assign uses +=, so you must be right about it being a bad idea.
Eigen2 does use << instead of <<=. Even if <<= is better, it may make
sense to consider just using << for generic interface compatibility with
eigen. Though who knows if they are going to stay with it for eigen3, the
closer libraries interfaces to look to me, the easier for me to write generic
code.