[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Define special member functions inline?
From: |
Vadim Zeitlin |
Subject: |
Re: [lmi] Define special member functions inline? |
Date: |
Sun, 5 Mar 2017 17:29:33 +0100 |
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