Re: [lmi] Define special member functions inline?

[Vadim Zeitlin]

On Mon, 6 Mar 2017 10:41:40 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-03-04 02:42, Vadim Zeitlin wrote:
GC> > On Sat, 4 Mar 2017 02:01:07 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > My personal rule is to define all defaulted special functions inline
GC> > (because of the above efficiency considerations and also because it avoids
GC> > unnecessary repetition)
GC> 
GC> Okay, then our guideline so far is
GC>   Write explicitly-defaulted special member functions inline, in the
GC>   class definition.
GC> with the rationale that
GC>   This makes the code clearer, and lets the compiler optimize better.
GC> [plain text because I don't know '.md']

[the nice thing about Markdown is that if you know plain text, you do know it]

GC> If we cannot write them in the class definition, should we still write
GC> them in the header?

 IMO no. It can't be written in the header when using unique_ptr<> with a
forward-declared class and has to be put in the source file in this case,
so it makes sense to always put it there for consistency. Especially
because there is no performance benefit from defining it inline for pure
virtual dtors as they will be always called virtually (i.e. indirectly)
anyhow and so won't be inlined (unless the compiler implements
devirtualization but if it's so smart, it certainly supports whole program
optimization as well and it can peek inside the source file too anyhow).

GC> IOW, would you revert the following (not yet pushed) commit?

 Yes, I would, for the reasons above. I'd rather do it like the commit
b05b68201a064b22cec6ec159e7372337a5fa1f8 does.

GC> But whichever we decide, I just want there to be a guideline so that we
GC> can always write code like this in the same well-chosen way without
GC> re-thinking the style each time.

 I wholeheartedly support this.

 Thanks,
VZ