| "It's more common to read callsites than to read the declaration. This way you don't need to lookup the declaration."
You *always* need to look up the declaration if you want to be sure of what is actually happening. Seeing:
m.foo(a, &b);
in no way verifies that the second parameter is an output parameter. There are only two valid assumptions that can be made about the second parameter from reading that callsite:
1. The second parameter is a pointer (possibly a pointer to const and therefore not an output).
2. The function is *expecting* null as a possible value for the second parameter.
"Furthermore, using references doesn't prevent null pointer problems"
Correct, it doesn't
prevent them, but it does document that a prerequisite for calling the function is that the passed-in value be a valid object with a valid memory location. If that is not the intent, then passing by pointer is the correct choice. Either way, this is just another example of why one must look at a function's public interface before assuming they know how to use it. --- On Fri, 7/24/09, Keir Mierle <mierle@xxxxxxxxx> wrote:
From: Keir Mierle <mierle@xxxxxxxxx>
Subject: Re: [eigen] API change proposal
To: eigen@xxxxxxxxxxxxxxxxxxx
Date: Friday, July 24, 2009, 12:37 PM
On Fri, Jul 24, 2009 at 10:28 AM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:
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.
+1.
I dislike references for output parameters. It's more common to read callsites than to read the declaration. This way you don't need to lookup the declaration.
Furthermore, using references doesn't prevent null pointer problems; instead someone who is working with pointers will do
m.foo(a, *b);
and crash just the same.
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.
>
>
>
its ridiculous to use pointers if you can - without any differences /
limitations - also use non-const references.
Gaël Guennebaud
Iparla - INRIA Bordeaux
(+33)5 40 00 37 95
|