Re: [eigen] API change proposal

[Markus Benjamin Fröb <grey_earl@xxxxxx>]

I agree when you see such a function call it is likely b is an output 
parameter - if and only if the API writer was sane, and it's not something 
like

bool foo(type& out, const bigdata* data)

although this is unlikely, I admit. But in any case, to read through code and 
understand it (to work with it), you have to lookup exactly what each function 
does anyway.

For me personally, the best thing would be something like
Matrix<>* LU::solve(const Matrix<>& b) {
  return the solution if it exists, else null
}

since then it is really obvious what is argument and what is output. Even 
though it's very much C-Style, but it is mathematical style.

Greetings, Markus

Am Freitag, 24. Juli 2009 schrieb Gael Guennebaud:
> hm... when we had this debate for the first time I felt alone in favor of
> references so we chose the use of pointers and now everybody is against
> this choice... Actually the main (unique) motivation was to emphasize the
> output parameters when you read an existing code (and you are not familiar
> with Eigen). For instance, when you read:
>
> m.foo(a, &b);
>
> you don't know what is a, b, or foo, but it is quite obvious that b is very
> likely to be an output.
>
> Anyway, I think it is a bit late for such a change. What could be done is
> to add overloads but that would clutter the API, so I'm puzzled.
>
> cheers,
> Gael.
>
> On Fri, Jul 24, 2009 at 3:00 PM, Andre Krause <post@xxxxxxxxxxxxxxxx> wrote:
> > Tim Hutt wrote:
> > > 2009/7/24 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> > >> You can pass null, right? The function will simply return. What else
> > >> could happen?
> > >
> > > Obviously you never used gnome back in the day! Segfaults left right
> > > and centre. Just because it is a good idea to check for NULL doesn't
> > > mean every function does it in practice.
> >
> > very true. it can happen and hence it WILL happen that pointers go
> > unchecked.
> >
> > its ridiculous to use pointers if you can - without any differences /
> > limitations - also use non-const references.