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: dak
Subject: Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by address@hidden)
Date: Wed, 29 Jan 2020 03:44:57 -0800

On 2020/01/29 06:36:07, hanwenn wrote:

> 
> 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

Errors mean non-intentional things.  My own take here is that we would
not want to use references on things that may be used as SCM values, so
things like

Grob &bla = *unsmob<Grob> (sbla);

would be quite undesirable.  However, for code that has no Schemish
implications, I find it perfectly fine to use C++ references in the
manner they are intended to be used.  There has been a recent push to
settle on C++11 as a programming standard to adhere to in order to be
more friendly to newcomers, and it seems sort of pointless to promote
C89 standards to go alongside.  That makes people less, not more
confident in what they may rely on using.

> grep --color -nH  -e '&' lily/include/*h|grep -v const
> 
> Also, it is rare to check incoming parameters for nullness in
implementation.

I am not exactly sure I'd call that a feature: we had crashes because of
it.  Some trampolining code now has the requisite assertions inside
since one cannot perform those checks too late: GCC optimises checks
like "if (!this)" away these days.

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



reply via email to

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