Re: [eigen] Map questions |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
I added static methods Matrix::Map() and Matrix::AlignedMap(), enforcing
constness of the array (contrary to the Map constructor) in r879722.
Cheers,
Benoit
On Wednesday 29 October 2008 23:41:14 Gael Guennebaud wrote:
> On Wed, Oct 29, 2008 at 11:28 PM, Benoît Jacob <jacob@xxxxxxxxxxxxxxx>
wrote:
> >> indeed, "Map<Vector3d>(a) = v;" seems to be equivalent to
> >> "Map<Vector3d> a = v;" that is very unfortunate...
> >
> > Ah thanks for the explanation, I was puzzled.
> >
> > Maybe we can at least block this form by disabling the default
> > constructor for class Map (private inheritance trick)? I mean, in the
> > "Map<Vector3d> a = v;" construction, the constructor used for A must be
> > the default constructor (then followed by operator=) since there is no
> > Map constructor taking v as argument. Right?
>
> indeed, but that does not solve anything, I mean the compilation error
> is still the same. (it complains a is already defined)
>
> >> I could keep going like this forever, but nothing is really good and
> >> intuitive. Perhaps this is a good motivation to resurrect the
> >> Matrix::Map static functions.... ???
> >
> > The idea behind letting the user construct named Map objects versus a
> > static method, was that it makes the user's code lighter when using a Map
> > object repeatedly. If you have a buffer that you want to map as a vector
> > and use that repeatedly, it is much ligher to do "Map<Vector3d>
> > m(buffer);" and use m henceforth. So I think we want to keep supporting
> > created named Map objects as part of our public API (and keep considering
> > this the recommended way in the documentation).
> >
> > I mean, we can always reintroduce the static methods, that would indeed
> > offer an nice alternative in the situation where a Map object is used
> > only once, but that doesn't solve the problem for other users who want a
> > permanent Map object.
>
> adding Map functions to Matrix does not change the current API, it
> just extend it. On the other hand I agree they are redundant in most
> cases, and having such two ways to express the same thing might be a
> bit confusing.
>
> perhaps we could rename the type Map to MapType, and define Map as a
> global static function, or something in that direction....
>
> > On Wednesday 29 October 2008 22:51:34 Gael Guennebaud wrote:
> >> Hi,
> >>
> >> On Wed, Oct 29, 2008 at 9:01 PM, Cristóvão Sousa <crisjss@xxxxxxxxx>
wrote:
> >> > Hi,
> >> >
> >> > I would like to do something like
> >> >
> >> > Vector3d v;
> >> > // v = something;
> >> > double a[3];
> >> > Map<Vector3d>(a) = v;
> >>
> >> indeed, "Map<Vector3d>(a) = v;" seems to be equivalent to
> >> "Map<Vector3d> a = v;" that is very unfortunate...
> >>
> >> Actually the following variants works:
> >>
> >> Map<Vector3d>(a,3) = v;
> >>
> >> (Map<Vector3d>(a)) = v;
> >>
> >> Map<Vector3d>(a).operator=(v);
> >>
> >> Map<Vector3d>(a).lazyAssign(v);
> >>
> >> Map<Vector3d> _a(a); _a = v;
> >>
> >> Map<Vector3d>(a).start<3>() = v;
> >>
> >> ...
> >>
> >> I could keep going like this forever, but nothing is really good and
> >> intuitive. Perhaps this is a good motivation to resurrect the
> >> Matrix::Map static functions.... ??? or find something else....
> >>
> >> > Another thing that could be a little bug:
> >> > it is currently possible to do
> >> >
> >> > const double a[3]={1,2,3};
> >> > Map<Vector3d>(a).setZero();
> >> >
> >> > , which discards the const qualifier of a.
> >>
> >> ok, I'll check later if we can do something for that, but there is
> >> nothing urgent here.
> >>
> >> cheers,
> >> gael.
> >
> > ---
---