Re: [lmi] [lmi-commits] master 43dcd1b 5/6: Make all table_column_info data members private and non-const

[Vadim Zeitlin]

On Fri, 24 Aug 2018 16:28:10 +0000 Greg Chicares <address@hidden> wrote:

GC> For you, the natural state of a bunch-of-data may be a struct with const
GC> members

 Yes, it is indeed natural because it's not a iota more complex than it
needs to be: such struct is just a tuple but with named fields. I just
don't see any compelling argument to have anything more.


GC> > GC> Given that, what is the benefit of making them (or most of them) 
const?
GC> > 
GC> >  Sorry if it's a trick question, but my naive answer is that, of course,
GC> > making them "const" ensures they're not mutated in the class code itself
GC> > and not only from outside it. And if they really don't have to be changed,
GC> > this can only be a good thing.
GC> 
GC> I suspect you want members to be const because you want them to be
GC> contained in a struct, while I see it as pointless to make them
GC> const because I want them to be private members in a class. I was
GC> just wondering whether there was a substantive, concrete, practical
GC> difference.

 Well, the fact that a class can modify its non-const members in its
methods while it can't do it with const ones is IMO pretty concrete. In
fact, when I see a non-const member of a class, I do assume that it's going
to be modified -- because otherwise, why is it not const in the first
place?

GC> Glad you asked. I looked for std::vector::emplace() but didn't find
GC> any such member, so I figured maybe we'll get it in a later standard.
GC> Looking again more carefully, I now see that it does exist.

 Yes, since C++11.

GC> However, it seems to have the same semantics as insert(), whereas I was
GC> hoping for an equivalent of "operator[]=" with move semantics.

 This would be just "vec[n] = std::move(table_column_info{...})", wouldn't
it?

VZ