[Top][All Lists]

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

Re: FWD: [bug #59270] [PATCH] node.h: avoid C++11 feature (non-const ini

From: G. Branden Robinson
Subject: Re: FWD: [bug #59270] [PATCH] node.h: avoid C++11 feature (non-const init in class)
Date: Thu, 15 Oct 2020 23:34:28 +1100
User-agent: NeoMutt/20180716

At 2020-10-14T15:45:16+0200, Ingo Schwarze wrote:
> Hi,
> this is the second portability issue that killed the build for me.
> Again, i'm looking for an OK to push the fix.
> Since i have little experience with C++, please check that the fix is
> correct and matches your intent.

TL;DR: LGTM, +1.

As far as I understand C++[1], yes it does.  I have an allergy to
allowing even the potential of a read from uninitialized storage, but I
recognize that this was not part of the ethic of early C++, where
everything was about "zero-cost" abstraction a.k.a. G01NG F4573RRRRRR.

> I don't think a Changelog entry is needed here, either.  This
> mini-issue never made it into a release and no user-visible change is
> intended.

Okay.  Per the rough consensus hammered out 3 years ago or so, my
personal practice is to add a ChangeLog entry if:

1. I'm changing executable code;
2. I'm fixing a ticket;
3. I'm making a "big" change to documentation.

That way the ChangeLog doesn't get clogged with my numerous editorial
revisions to documentation[2].

So my ChangeLogging threshold is lower than yours for executable code,
but I don't mind that.  I'm still the new kid around here and I
appreciate the increased probability of code reviews.


[1] And one's understanding must be rebuilt ex nihilo with every new
    release of the standard because FEATURES FEATURES FEATURES.
[2] Of course _everything_ gets a commit message, and even for changes
    where I produce a ChangeLog entry, I often have supplementary
    information in the commit message.

Attachment: signature.asc
Description: PGP signature

reply via email to

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