[LLVMdev] Guidance on using pointers vs. references for function arguments

Chandler Carruth chandlerc at google.com
Mon May 26 20:21:28 PDT 2014


On Mon, May 26, 2014 at 7:41 PM, Andrew Trick <atrick at apple.com> wrote:

> On May 26, 2014, at 5:02 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
>
> On Mon, May 26, 2014 at 4:43 PM, Andrew Trick <atrick at apple.com> wrote:
>
>> This has been discussed before but I can’t find a reference to it. I
>> could have sworn this was in the coding convention at some point. Here’s
>> what I remember: during early LLVM development there was an effort to
>> establish the convention that you described above—use pointer types only
>> when nullptr is valid. This led to a lot of redundant declarations and
>> annoying taking of addresses and dereferences. It turns out that the
>> convention doesn’t really help for most informal/internal APIs. It’s
>> actually no harder to debug a SIGSEGV than a nullptr check. I also adhered
>> to this convention in a previous project and it never paid off.
>>
>> Once you begin working on a piece of code you get a feel for which types
>> should be passed as pointers and which should be passed as reference. Then
>> you try to pass types consistently regardless of whether a null input is
>> valid. For example, some types, like the current context, should never be
>> copied or passed by value and are obviously not null. That’s lower overhead
>> in practice forcing callers to convert to a reference whenever we want to
>> skip a null check.
>>
>
> This last sentence should read: it’s lower mental overhead for the
> programmer to use the same type consistently rather than worrying about
> another convention to follow at every call.
>
> I would personally be happy to follow the pointer may be nullptr
> convention if it were used consistently. I was just trying to reiterate
> arguments against it that I’d seen w.r.t LLVM codebase, and I don’t see
> much value in forcing the convention everywhere.
>

Certainly.

My suggestion: unless we have evidence this is confusing people trying to
contribute to LLVM, then it isn't broken as is.

If folks are confused by this and it is becoming a neusance, then I would
suggest we draw a line in the sand much like we did with function names.
New code gets the new rule, existing code (and code with existing
conventions surrounding it) isn't impacted. My suggested rule would be "use
a pointer if it might be null or re-pointed at some other entity, otherwise
use a reference". But I don't think adding that kind of rule is necessary
unless folks are frequently tripped up by this in reviews, etc.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140526/f9da5537/attachment.html>


More information about the llvm-dev mailing list