lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by add


From: nine . fierce . ballads
Subject: Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden)
Date: Tue, 28 Jan 2020 15:38:23 -0800

On 2020/01/28 22:06:33, hanwenn wrote:
>
> In general, pointers are preferred in function signatures, so you can
see that
> the value is mutated in the call site. See also
> https://google.github.io/styleguide/cppguide.html#Reference_Arguments

OK, they're preferred by one or more people at Google.  They're not
preferred by me, the people I've worked with, or the creator of C++:
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-ptr-ref

> What would we do in a check? Passing a null input is a programming
error; if we
> don't check, we'll generate a segfault and that seems appropriate for
a
> programming error.

Not seeing a satisfying way to handle a null pointer is a hint that
using a reference would be better.  You've preferred one of two kinds of
run-time errors, but the choice you've dismissed is a compile-time error
when someone tries to pass a pointer to a function that requires a
reference.  A compile-time error is an improvement over a run-time
error, isn't it?

I don't want to spend a great deal time trying to change your mind, and
I'm certainly not going to tell a project founder what to do here, but I
would rest easier if there were at least a comment on the prototype that
the pointer is not allowed to be null.

https://codereview.appspot.com/577410045/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]