octave-maintainers
[Top][All Lists]
Advanced

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

Re: latest constructor changesets


From: Andrew Janke
Subject: Re: latest constructor changesets
Date: Tue, 10 Sep 2019 16:06:48 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0


On 9/10/19 2:26 PM, John W. Eaton wrote:
> On 9/10/19 11:40 AM, Rik wrote:
>
>> One of the latest commit messages was "use default or deleted
>> ctors/dtors/assignment ops in liboctave/util".  This is just about
>> code readability, correct?  Replacing hand-rolled constructors with
>> "= default" where there was in fact nothing different from what the
>> compiler would automatically generate. There shouldn't be any
>> performance changes over what we had before?
>
> Yes, I've been making changes like that because I think it makes the
> code easier to read and maintain.  I wouldn't expect any change in
> performance.  I think it's best to explicitly state that the compiler
> should generate these functions where possible.
>
> As an example of the kind of error that can happen when writing them
> by hand, I noticed one case in which the existing copy constructor and
> assignment operator were not copying all class data members.  I
> couldn't see any reason to omit any of them but it took some time to
> try to determine whether the omission was intentional.  I eventually
> decided that it was more likely that some data members were added but
> the copy and assignment functions were not updated.  Having the
> compiler generate these functions avoids that error and makes it
> easier to understand immediately what the functions will do.  If they
> are written by hand, you have to scan the list of data members that
> are copied in the functions and compare with the class declaration to
> be sure that everything is properly copied.
>
> I'm also switching to using "= delete" declarations instead of
> declaring copy constructors and assignment operators as private. 
> Using "= delete" will always give a compile time error when a copy is
> requested instead of a warning about "use of a private function in
> this context" or a linker error if a copy is requested inside another
> member function. Though we did try to mark these private declarations
> with a "No copying!" comment, the "= delete" declaration leaves no
> room for confusion about whether the function definitions were
> accidentally omitted.
>
> jwe
>
>
This sounds better to me. As a relatively inexperienced C++ programmer,
these forms are more readily understandable to me.

Cheers,
Andrew



reply via email to

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