Re: [lmi] Define special member functions inline?

[Vadim Zeitlin]

On Sat, 4 Mar 2017 16:23:54 +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> [...big snip...]
GC> 
GC> > GC> Actually, lmi practice has been to define the dtor and all ctors
GC> > GC> out-of-line whenever any one of them is defined out-of-line. Is there
GC> > GC> any reason to change that convention now?
GC> > 
GC> >  I don't see any good reason to define the ctors and dtor in the same
GC> > place. 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) and also define trivial ctors inline as well
GC> 
GC> This seems to be the best rule. I'd like lmi to follow this guideline.
GC> 
GC> But there's one part I don't understand: "also define trivial ctors inline".
GC> Aren't all trivial ctors necessarily either omitted, defaulted or deleted?
GC> C++11 [12/5] says:
GC> | A default constructor is trivial if it is not user-provided and if ...

 Sorry, I was, as usual, too imprecise in my wording. I meant "trivial" in
the general sense, i.e. "simple", "short", "not complex" and not in the
sense used by the C++ standard. I.e. all I wanted to say was that I'd also
write a ctor like this inline (please ignore the details, I'm just making
things up to illustrate my point):

        class C
        {
        public:
                explicit C(unsigned num_threads)
                {
                        pool_.initialize(num_threads);
                }

        private:
                thread_pool pool_;
        };

GC> And, as a corollary, if a special member function written out-of-line
GC> has an empty body "{}", then it should be inlined with "=default".

 Yes, I definitely agree with this.

 Sorry again for the confusion,
VZ