lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 5732: Use unique_ptr in layout code (issue 573500043 by addres


From: nine . fierce . ballads
Subject: Re: Issue 5732: Use unique_ptr in layout code (issue 573500043 by address@hidden)
Date: Mon, 03 Feb 2020 10:27:23 -0800

Reviewers: dak, hahnjo,

Message:
On 2020/02/03 18:01:09, dak wrote:
> Stupid question: unique_ptr has the purpose of deallocating memory
when the last
> reference is gone.

When the single, owning reference is gone.  It's not reference counted.

> But we have an entire Scheme allocation system exactly for
> that purpose for which we are already paying the price in overhead. 
Any chance
> this can be usefully tracked in the SCM scheme of things?

Do you mean turn Accidental_placement_entry etc. into Smobs, call a
Guile function to sort a vector, etc.?  It seems possible, but is not
something that piques my interest.

To the point of overhead: you're not paying anything for unique_ptr if
your baseline for comparison is raw-pointer code that explicitly calls
delete everywhere it needs to be called to avoid leaks.  unique_pointer
might be slower than leaky code.


Description:
https://sourceforge.net/p/testlilyissues/issues/5732/

Use std::unique_ptr instead of manually managed raw pointers.

I suggest beginning the review in accidental-placement.cc  The
algorithm in stagger_apes () took me the most time to come to terms
with.  With unique_ptr, it's much easier to be confident that there
isn't a memory leak there.

unique_ptr deletes its object when it goes out of scope.  Transferring
ownership of the object to another instance of unique_ptr is done with
std::move().  A unique_ptr can not be copied, but one can get an alias
(a raw pointer) from it with p.get().

Using unique_ptr makes the flower junk_pointers() function
unnecessary.  I can't remove junk_pointers() yet because MIDI code
still uses it, and I don't want to wade into that high water now.

I'm aware that some lines are longer than 80 characters.  I plan to
try clang-format after Han-Wen's config file makes it through the
countdown.

Please review this at https://codereview.appspot.com/573500043/

Affected files (+86, -63 lines):
  M lily/accidental-placement.cc
  M lily/beam-quanting.cc
  M lily/include/beam-scoring-problem.hh
  M lily/include/slur-configuration.hh
  M lily/include/slur-scoring.hh
  M lily/slur-configuration.cc
  M lily/slur-scoring.cc
  M lily/system-start-delimiter-engraver.cc





reply via email to

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