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

Chandler Carruth chandlerc at google.com
Mon May 26 21:15:27 PDT 2014


On Mon, May 26, 2014 at 8:45 PM, Chris Lattner <clattner at apple.com> wrote:

> Chandler, Andy's recollection is correct.
>
> I was personally infatuated by this idea and pushed it through a ton of
> the LLVM IR APIs (this was many years ago, (in the pre-1.0 days, and then
> again early in Clang's development because I'm a slow learner).  It led to
> all sorts of weird cases where some arguments to IR objects would be taken
> by reference and some by pointer.  It made it impossible to remember
> whether a given function took a pointer or a reference, and made for
> absolute madness trying to program against the APIs.  It got to the point
> where literally you had to do a build and just add the missing &/*'s to get
> the build to go through.
>

I didn't doubt any of Andy's recollection here, and it seemed like we were
largely in agreement...

Anyways, while inconsistency such as you describe between pointer and
reference arguments can be quite frustrating (as I see it was for you), at
least LLVM is still pretty stunningly inconsistent to this day. I also
don't find it to be a significant burden. Especially with Clang (which
corrects for this pretty much perfectly every time) and other tools, when I
have to fix these issues it is very fast.

Ultimately, (as I said in my prior email) I don't think there is a problem
to solve here because I don't think that any of these things are actively
"bad". Maybe its just the devs I know who don't really have trouble here,
but its not one of the complaints I hear from others or have myself in
day-to-day development.

If mixing pointers and references for the same type in LLVM's APIs is a
serious problem in your mind, what is your concrete suggestion? What should
the end state look like?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140526/c49a019b/attachment.html>


More information about the llvm-dev mailing list