Re: Issue 4156 in lilypond: Patch: Define Smob<> constructors.

[Ian Hulin]

On 15/10/14 09:47, address@hidden wrote:
> Updates:
>     Status: Fixed
>     Labels: -Type-Enhancement -Patch-push Type-Maintainability
> Fixed_2_19_16
> 
> Comment #13 on issue 4156 by dak-mXXj517/address@hidden: Patch:
> Define Smob<> constructors.
> https://code.google.com/p/lilypond/issues/detail?id=4156
> 
> Pushed to staging as
> commit 7f309e69558db5225b92ae003c0818c68988013d
> Author: David Kastrup <dak-mXXj517/address@hidden>
> Date:   Wed Oct 8 16:46:52 2014 +0200
> 
>     Issue 4156: Define Smob<> constructors
> 
>     The purpose of this patch is to stop the previous implicit copying of
>     Smob<> data members in derived copy constructors.
> 
>     To that purpose, Smob<> has received a private copy constructor (which
>     gcc unfortunately only considers worth a warning rather than an error
>     when implicitly used in a default copy constructor) and an inline
>     default constructor.
> 
>     Several classes contained virtual copy constructors without being
>     actually copyable have had their copy constructor removed.
> 
>     Several copy constructors just containing a failing assertion were
>     instead removed and left (privately) declared but not defined.  This
>     standard C++ practice leads to link time rather than run time errors in
>     case an instance of such a class is copied.
> 
>     <b>Other smob-defining base classes (Simple_smob and Smob{1,2,3}) do not
>     actually have non-static data members that could be initialized.<b/>
> 
>     Prohibiting the copying of Simple_smob as a base class seems rather
>     pointless as all of the data members of a derived class are under the
>     control of the derived class.  However, Smob{1,2,3} "misuse" this
>     pointer to contain an SCM value.  Creating a copy would change the
>     associated address, a very undesirable operation.  So Smob{1,2,3} have
>     its constructors private and/or disabled.
> 
>