Re: [lmi] default-member-initializers vs. is_trivial

[Vadim Zeitlin]

On Tue, 20 Apr 2021 01:20:35 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 4/19/21 9:30 PM, Vadim Zeitlin wrote:
GC> > On Mon, 19 Apr 2021 20:57:23 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> [...]
GC> > The task of the constructor is to actually initialize (or
GC> > not) the new object data and trivial constructor doesn't do it.
GC> 
GC> That's exactly my point.
GC>   Constructors actually initialize things.
GC>   "Trivial ctors" don't.

 This is a terminological question, but IMO the usual terminology makes
perfect sense: trivial ctors do the absolute minimum they could possibly
do.

 Again, I could understand if you'd expect them to zero-initialize the
object memory, rather than leaving it completely uninitialized, but this
wouldn't change anything as the main point is that it's not reasonable to
expect initializing data fields to arbitrary, non zero values to be called
"trivial".

GC> I wouldn't have been confused at all if they had made it clear
GC> that "triviality" is a low-level concept intended for systems
GC> programmers and library authors. Having first contemplated
GC> trivial-copyability, I had surmised that "triviality" was a
GC> generally desirable property of classes--a precondition that
GC> ensures that compiler-generated special member functions do
GC> the right thing--a prerequisite for the rule of zero to be
GC> generally applicable.

 I must be forcing an open door by now, but this is definitely not the
case. Of course, it's not the case for trivial copy ctors neither -- a
class may not be trivially copyable because it has members or base classes
with non-trivial copy ctors, but still not have any copy ctor of its own.

 Concerning the pursuit of the rule of zero, I have to say that I disagree
with it and believe that it's always best to write all the ctors
explicitly, even if just to default them, for all but the most trivial
classes. I thinks understand why you do what you do, but your approach
seems to implicitly rely on the infallibility of the programmer writing the
code, as it assumes that if a ctor is not defined, it is because it is not
needed and not just because it was forgotten. Personally I'd rather avoid
assuming this and explicitly show that it wasn't forgotten, but was
intentionally omitted by writing the default version -- in C++98 I always
used a stock comment to indicate that it was the case, but since C++11
writing "= default" serves the same purpose while being also enforced by
the compiler, which is much nicer. The gain from omitting these lines just
doesn't seem to be commensurate with the peace of mind gained from having
them.

 Regards,
VZ

pgpHjU5t3IQBa.pgp
Description: PGP signature