Re: [lmi] Request for code review

[Vadim Zeitlin]

On Tue, 24 Jan 2017 01:10:51 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-01-23 22:30, Greg Chicares wrote:
GC> > On 2017-01-23 21:12, Vadim Zeitlin wrote:
GC> >> On Mon, 23 Jan 2017 20:11:00 +0000 Greg Chicares <address@hidden> wrote:
GC> >> 
GC> >> GC> Two (tested) changes here. The "auto" change seems obvious.
GC> >> 
GC> >>  Yes, except that I'd use "auto const" but I am, of course, have somewhat
GC> >> of an obsession with const local variables...
GC> >> 
GC> >> GC> The other is Meyers's "Avoid Duplication in const and Non-const 
Member
GC> >> GC> Function" technique. It's already used elsewhere in this file, and I
GC> >> GC> kind of like it.
GC> >> 
GC> >>  I can't say I like it but I definitely dislike it less than duplicating
GC> >> code and personally I think it's as good an idea as it ever was. But why
GC> >> use static_cast<> instead of (strictly less powerful and hence less
GC> >> dangerous, without mentioning that it's also much clearer) const_cast<>?
GC> > 
GC> > Meyers says: "The cast that adds const is just forcing a safe conversion
GC> > (from a non-const object to a const one), so we use a static_cast for
GC> > that." I thought he might have had some profound reason, but I guess he
GC> > might be avoiding const_cast because some people think of it as a code
GC> > smell, or perhaps he liked to reserve const_cast for removing constness.
GC> > Whatever his reason, I find your arguments persuasive. And of course if
GC> > we wait until 2017 we can use std::as_const(). C++2017, that is.
GC> 
GC> Wait...const_cast<> is not strictly less powerful than static_cast<>,
GC> because const_cast<> can cast away volatility but static_cast<> cannot.

 Sorry, I clearly don't use "volatile" keyword enough because you're right,
of course. I still think const_cast<> is more clear away for casting away
constness, even though static_cast<> can't be used to cast away staticness.

VZ