[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by add
From: |
hanwenn |
Subject: |
Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden) |
Date: |
Tue, 28 Jan 2020 22:36:06 -0800 |
On 2020/01/28 23:38:24, Dan Eble wrote:
> 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
I've never been a big fan of Stroustrup, so we are both coherent, at
least :-)
(see question 9
https://developers.slashdot.org/story/00/02/25/1034222/c-answers-from-bjarne-stroustrup)
> > 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.
I reorganized a bit more; I hope you like it better now.
BTW - I don't want to tell a C++ expert how to use the language in
general. If we were in an alternate reality where we could start from
scratch we could reconsider the decision to not use non-const references
in structs and function arguments. As it is however, any that we have
are most likely errors that we should correct. Check
grep --color -nH -e '&' lily/include/*h|grep -v const
Also, it is rare to check incoming parameters for nullness in
implementation.
https://codereview.appspot.com/577410045/
- Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden), hanwenn, 2020/01/27
- Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden), nine . fierce . ballads, 2020/01/27
- Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden), hanwenn, 2020/01/28
- Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden), dak, 2020/01/28
- Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden), nine . fierce . ballads, 2020/01/28
- Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden),
hanwenn <=
- Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden), dak, 2020/01/29
- Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden), dak, 2020/01/29
- Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden), hanwenn, 2020/01/30
- Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden), hanwenn, 2020/01/30
- Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden), dak, 2020/01/30
- Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden), hanwenn, 2020/01/30
- Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden), nine . fierce . ballads, 2020/01/30