Re: [lmi] const or reference members

[Vadim Zeitlin]

On Tue, 12 Jul 2022 22:26:27 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 7/12/22 21:40, Vadim Zeitlin wrote:
GC> > On Tue, 12 Jul 2022 16:18:34 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> > 
GC> > GC> On 7/11/22 22:12, Vadim Zeitlin wrote:
GC> > GC> > On Mon, 11 Jul 2022 16:22:14 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> > GC> > 
GC> > GC> > GC> On 7/11/22 12:12, Vadim Zeitlin wrote:
GC> [...]
GC> > GC> > GC> Here, I want to consider a distinct question: if, for any given 
class,
GC> > GC> > GC> defaulted copy operations are correct, then can default 
assignment
GC> > GC> > GC> operations be incorrect?
GC> > GC> > 
GC> > GC> >  It's, of course, possible to maliciously design just such a class, 
but I
GC> > GC> > don't think it's something that can happen organically.
GC> > GC> 
GC> > GC> I stumbled on one case: const reference members. I suppose either
GC> > GC> const-ness or reference-ness is enough to poison assignment.
GC> > 
GC> >  Either is enough for the assignment not to be possible, but for me this
GC> > doesn't mean it's incorrect -- it's disallowed, which is something quite
GC> > different (and not nearly as bad).
GC> 
GC> Let me paraphrase, to see whether I understand:
GC> 
GC> Given a class with const or reference members, in our editor we can add
GC> defaulted assignment operators, but our compiler will reject them.

 I might be nitpicking, but the compiler won't "reject" them in the sense
that it will result in any kind of error. The compiler will handle the
default assignment operator for a non-assignable class in the same way as
the deleted assignable operator because, for a non-assignable class, the
default behaviour is to disallow assignment.

GC> It won't accept them and generate invalid code.

 It certainly won't generate invalid code because any attempt to use the
assignment operator will result in a compilation error.

GC> Is that equivalent to what you said?

 I'm not sure, but hopefully the above clarifies what I meant.


GC> I've written classes with const or reference members. I'm wondering
GC> whether I should repent and change them all.

 I definitely don't think there is any need to do it. Sometimes it may be
worth using a pointer rather than a reference just to allow the class to be
assignable, but if you don't especially need it to be assignable, you
certainly shouldn't hesitate to use const or reference members when they're
appropriate.

GC> OTOH, I recently found a case where changing a non-const non-reference
GC> member to "const&" would permit a forward declaration where an entire
GC> header is now included:
GC> 
GC>   -#include "round_to.hpp"
GC>   +template<typename> class round_to;
GC> 
GC>   ...and change 'round_to' to 'round_to const&' in these places:
GC>   $ git grep 'round_to<\w*> *\w*;' *.hpp
GC> 
GC> I resisted the temptation to make that change for fear it would
GC> interfere with special-member operations.

 This looks like a potentially useful change, but looking at e.g.
outlay.hpp in more details I see that you need to pass round_to<>
objects to its ctor, which probably means that any code using it would
include round_to.hpp anyhow. Unless it already uses references itself, of
course... I.e. more analysis is needed to confirm that this will actually
reduce physical dependencies (and I still didn't finish my experiments with
IWYU that would have allowed to do things like this semi-automatically...).

VZ

pgpgcvZ6Dn5OU.pgp
Description: PGP signature