lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 5705: int->long in Stem::get_beaming and set_beaming (issue 56


From: hanwenn
Subject: Re: Issue 5705: int->long in Stem::get_beaming and set_beaming (issue 561350044 by address@hidden)
Date: Mon, 03 Feb 2020 00:04:24 -0800

sorry to complain late about this change. I understand that this gets
rid of a conversion warning, which is something that we want, but I am
missing the big picture here. Is there a plan for the big picture?


https://codereview.appspot.com/561350044/diff/571460330/lily/stem.cc
File lily/stem.cc (right):

https://codereview.appspot.com/561350044/diff/571460330/lily/stem.cc#newcode67
lily/stem.cc:67: Stem::set_beaming (Grob *me, long beam_count, Direction
d)
sorry to be late to the party; I hadn't seen this change.

This is the right approach if you take the output type of scm_ilength as
a given.

However, beam_count is the number of beams that will be on an individual
stem, which fits easily in a byte (128th notes are exceedingly rare, and
they use 5 beams). Using a long here is 7 bytes too many.


What is the overall plan here? If we change the beam count to be long,
shouldn't we just bite the bullet and banish int altogether? We could
globally replace it with int64_t which has the additional advantage of
being explicit about its size.

https://codereview.appspot.com/561350044/



reply via email to

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