dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #18296
Re: [gnw20@xxxxxxxxx: [Blueprint array-typemaps] New approach to array typemaps]
I think it is as complete as it might get. It all boils down to if we want to
move the rest of std::vector<Foo>, and Foo* interface to Array<Foo>. I am not
sure we want that. Maybe for some methods in the LA interface, see below and
its own Blueprint.
On Thursday May 13 2010 10:27:33 Anders Logg wrote:
> * Cleanup (remove?) the std::vector typemaps.
> -> We cannot remove all std::vector typemaps.
> |-> We still use std::vector<Foo*> typemaps.They might be changed
> | with Array, but it will not be easier.
> |-> std::vector<Foo>& argout typemaps are useful to pass data out
> | from intersection detectors and like.
I think we are fine with the few std::vector<Foo> typemaps we still have. It
will be difficult to move both of these cases to Array<Foo>
> Things left to consider:
> * Consider which other foo* or std::vector<foo> methods should be using
> Array<foo>
> -> GenericFoo.{get,set} in the la interface?
> -> Expression(std::vector<uint> value_shape)?
> -> GenericMatrix.{get,set}row?
The first two cases might benefit from a change. Any such change should be
readily wrapped by the present Array typemap. We might need to do something in
the python layer for the Expression typemap.
I am not sure with the last issue. I remember that there were some benefits
using std::vector for this.
Johan
Follow ups
References