dolfin team mailing list archive

[kent-and@xxxxxxxxx]

> 2008/4/3, Anders Logg <logg@xxxxxxxxx>:
>> On Thu, Apr 03, 2008 at 07:47:13PM +0200, Martin Sandve Alnæs wrote:
>>  > We only talked about create() the other day, copy() can still be
>>  > useful! Or does the factory duplicate this functionality?
>>
>>
>> No, but Kent has added an assignment operator:
>>
>>   GenericVector* y = x.factory().createVector();
>>   *y = x;
>
> Ok, but the assignment operator doesn't exist in Python, so some
> variant of the copy function may still be needed. Could be just a
> wrapper for the two lines above.


PyDolfin has assign:
dolfin_function_pre.i:%rename(assign) dolfin::Function::operator=;



>
> But the current default implementation of operator= (just return
> *this;) isn't good, it should be abstract or at least raise an error
> somehow.
>

It did not compile when it was defined as an abstract function. But I
agree completely. You probably have a fix, I didn't manage.

> And I the uBlas implementation seems potentially dangerous too,
>
> const uBlasVector& uBlasVector::operator= (const GenericVector& x_)
> {
>   const uBlasVector* x = dynamic_cast<const uBlasVector*>(&x_);
>   if (!x) error("The vector should be of type PETScVector");
>
>   *this = (*x)*1.0;
>   return *this;
> }
>
> In particular, this line
>   *this = (*x)*1.0;
> depends on (*x)*1.0 being resolved by the ublas_vector subclass,
> triggering operator= in ublas_vector. Implementing operator* in
> GenericVector will break this and possibly make an infinite recursion.
> Unless I misunderstand something? (I don't know ublas).
>

Please help here as well. The reason it looks like this is that I don't
know ublas.

Kent