How rigorous are you about using const?

Chris Kawa

In many cases I expect compilers to figure out if some local variable is changed during its lifetime.

I think it was at some cpp con few years back that one of the implementers of LLVM said blatantly that they just straight ignore const in most of the optimizer passes. That's mostly because const_cast exists and any optimizations they might think of have some corner case that generates hard to diagnose or debug casting problems so it's just not worth it. Also you can't assume anything about a variable that crosses object file boundaries, unless you use something like WPO, but I don't think anyone is really optimizing for const beyond maybe some basic stuff.

What comes to mind is operator and operator const of std::vector and other vector classes, like QVector

I don't think it matters for std:: but with Qt containers const is important because of implicit sharing. non-const methods cause a detach that can be costly in many cases.

This begs the question how to write it:

IMO it's a pointless debate about east const vs west const. There are endless arguments that it should read right to left or like spoken word. Should programming languages read like books or shouldn't? Outside to inside or inside to outside? It should stay with type or with the indirection character. All of that just boils down to personal preference I think. I use west const just because that's how I learned it and most projects I worked in used it that way but I don't have any strong opinion either way. I don't care which is used, but the thing that actually bugs me is that there are two ways to use it. It's just unnecessary and I'd prefer much more to have only one valid syntax for it (whichever it is) because all that choice does is confuse the hell out of people, especially fresh C++ers.

sierdzio

That's one place where a simple new keyword could clarify a lot and make code more readable on first sight: const_object (or const_pointee or whatever).

const_object QWidget *blah; // Object is const, pointer is not
const QWidget *blah; // Pointer is const, object is not
const const_object QWidget *blah; // Both are const. For clarity, const_pointer could be added, too

I don't think anybody cares for it enough to change suggest it. C++ was always proud of it's hard to read syntax ;-)

Chris Kawa

@sierdzio The committee is usually very reluctant to add new keywords, especially if they're just sugar and I must admit I agree with them on this one. I really don't want to write constexpr const const_object Foo* const_pointer const if I don't have to :P

sierdzio

Hah, that's a strong argument indeed.

J.Hilk

@Chris-Kawa said in How rigorous are you about using const?:

constexpr const const_object Foo* const_pointer const if I don't have to

you mean, super_const 😎

SimonSchroeder

@Chris-Kawa said in How rigorous are you about using const?:

It's just unnecessary and I'd prefer much more to have only one valid syntax for it (whichever it is) because all that choice does is confuse the hell out of people, especially fresh C++ers.

I guess that most people learned west syntax. The thing is that const always modifies what is immediately left of it. Obviously, this rule does not work for west const. So, basically this is the only exception to the rule. Which means it would make more sense to adopt east syntax as it is more consistent throughout. However, I expect a very strong resistance in the C++ community to ditch west const entirely (everybody learned it like that).

@sierdzio

const QWidget *blah;

is already defined to be a const object. This will never be redefined to mean a const pointer to a mutable object. And I also don't mind writing const pointer to mutable object like this:

QWidget *const blah;

However, I guess that people mostly will write only a single const. What would be helpful then is a small wrapper for a const pointer to a const object, e.g.:

const_ptr<QWidget> blah;

This could belong to the Guidelines Support Library of the C++ Core Guidelines. I thought I once heard a suggestion like this, but couldn't find it again. I could be that it was related to pointers as members of a class: If accessing a member pointer (both non-const pointer and non-const object) from a const member function, constness only applies to the pointer but not the object. Maybe what I remember was related to this (but I can't still find it). Certainly, even if you apply const properly everywhere this is the place where it breaks.

kshegunov

That thread did spiral somewhat. Bringing it back to the original question (as I'm late to the party):
@JonB, I personally use const only for members, references and globals/statics. I don't see no sense in doing it for a function argument (as it's already a copy) and I most certainly don't see any gain in doing it for locals*.

* Exception is when I deal with Qt's iterators I force const iterators whenever I can to be absolutely sure I don't detach the container accidentaly.

jsulm

@kshegunov said in How rigorous are you about using const?:

I don't see no sense in doing it for a function argument (as it's already a copy)

If passed by value. But the benefit of const for "by value" parameters is that you can't change them by mistake (if they should not be changed inside the function). Another benefit is that const clearly states that the function should not change the parameter.
Same goes for locals.

Personally I always use const if something should not be changed.

kshegunov

@jsulm said in How rigorous are you about using const?:

If passed by value.

Yes, as I said:

... use const only for members, references and globals/statics.

But the benefit of const for "by value" parameters is that you can't change them by mistake (if they should not be changed inside the function).

I may throw by mistake too. Not all mistakes are preventable, and I really see no reason to sprinkle const liberally just for me. (the compiler doesn't care, nor should it, as @Chris-Kawa already mentioned)

Another benefit is that const clearly states that the function should not change the parameter.

Which as Chris already mentioned is none of the user of said function's business.

Same goes for locals.

So I prevent meself from changing something, so I don't accidentally change it, but then if I actually need to change it I unprevent myself. No thanks.
The big difference between a local (or a function argument) and a global (where it actually makes sense) is the scope of the state. A global is an application global state, while a function variable is self-contained in the function, so much so that it doesn't break reentrancy and thus doesn't introduce side effects on interruption. So for me using const in that tiny ecosystem is like putting a protective band around sheets of paper, so you don't get a paper cut. Doesn't sound like a smart use of my time is all.

Personally I always use const if something should not be changed.

We are going to disagree on the objective side of this argument, but you can do as you please, it's not wrong to do for certain.

kshegunov

@sierdzio said in How rigorous are you about using const?:

That's one place where a simple new keyword could clarify a lot and make code more readable on first sight: const_object (or const_pointee or whatever).

Sidetracking a bit - that wouldn't work, because you can have, albeit rare, QWidget **, then const is supposed to modify which pointer exactly? Current semantics is fine I think. And to be honest I believe noobsters have much more problems with dangling pointers than accidentally modifying stuff, for which const doesn't help at all. And I'm pretty sure of it as I was a noobster once too ... :)

JonB

I am glad to have started such a big discussion :)

For my own part, I shall:

Obviously, for any global/member variables which are genuinely meant to be const I will put that in. That was never the question.
When I choose to create a temporary pointer, I will (try to) make the effort to put in const (e.g. const QWidget *widg = something; widg->constMethod();) where I only need to use the variable to call something const. Just as I would it it were a formal parameter to a method.
But for non-pointer simple value types, whether as local variables or formal parameters, for right or for wrong I 'm not going to cover my code with const. It's just too much to type, and I'd rather save const for where it actually matters.

Thanks to all. I'll close this in a couple of days, give y'all some more time to disagree with each other ;-)