Const all the things?

> OP says this like this is an industry rule of sorts but I've pretty much always seen non-const references for this. Using pointers is terrible because now you have to add a check for null inside your function, as its API contract says "I can accept null values", while references make it clear that it does not make sense to call if you don't have a correct object to pass it.

The other side of the coin is that it hurts readability if you are passing non-const references. When a function takes a non-const reference, the caller looks like this:

    foo (bar); // Have to read the header to know if bar is modified.

When a function takes a pointer, the caller looks like this:

    foo (&bar); // Immediately clear that we cannot gloss over this line in code-review.

Since I read code much more than I write it, it's easier for me to determine that local non-const variables that are used as arguments to a function are not getting modified.

A better (but not best) solution might be to have the language recognise and enforce nullability on arguments. Still not perfect (pointer may be non-null but invalid), but better.

One other benefit pointer parameters have over reference parameters is that the API contract is more flexible. For example, I have a function that accepts a network connection,

    mynet_accept(int listener_fd, char **remote_ip, uint16_t *remote_port);

Having the caller specify NULL for `remote_ip` means that the callee just ignores the parameter. Same for `remote_port`.

If that was changed to use references, the caller will have to declare variables just to satisfy the parameter list, even if they never intend to use them.

Or, don't use out-parameters unless you really have to.

If a function returns a value, have it return that value, instead of using an out-parameter. Passing in-parameters by const reference rather than by value is a nice win because the semantics of the function remain clear. Input parameters still look like input parameters, you're just preventing unnecessary copies where it's easy to do so. Returning a value as an out-parameter rather than just returning it is a performance hack that prevents a copy, but at the expense of muddying the semantics of the function.

As the prophet says: we should forget about small efficiencies, say about 97% of the time. Write code that clearly expresses what it does. Return your return values. If you run a profiler over your code and you notice that some returns are causing a performance problem - sure, at that point, add an overload that takes an out-parameter and use it at the frequenty-executed hot spot.

I absolutely hate non-const reference parameters. Personally, I never use them except for operator overloading or stl functions.

The reason is, as lelanthran said, that when I see func(param), I don't expect param to be modified.

The time I lost because of non-const reference parameters adds up to days, maybe weeks. In fact, bugs caused by stealthy references are often way harder to find than null pointer crashes. Null pointer crashes are among the bugs that concern me the least, sure crashes are bad, but the core dump often tells you exactly what's wrong, and they rarely lead to non-DoS exploits. See: offensive programming.

Now that I think of it, maybe IDEs should highlight non-const references in function calls.

I think it is unfortunate because I like the extra guarantees that references offer over pointers but the lack of explicit (de)referencing is enough for me to avoid.

> Using pointers is terrible because now you have to add a check for null inside your function, as its API contract says "I can accept null values", while references make it clear that it does not make sense to call if you don't have a correct object to pass it.

You need no such NULL check. Specify as part of the function's contract that a pointer be non-NULL: if a caller breaks the contract, behavior is undefined. An unexpected NULL is just like any other violation of the function's contract: a programming error.

Spell out the contract in the function's documentation. A contract is more than the signature. There is absolutely no need for a runtime check (certain special cases aside) to enforce function contracts.

In some cases, assert()ing that a parameter that is expected to be non-NULL is in fact non-NULL can be useful --- but you don't need such checks for correctness of the program, and use of assertions in general ought to be a matter of taste and discretion.

Knee-jerk, automatic checking by random internal functions of a module of pointer parameters for NULL in every single place suggests that the author doesn't fully comprehend the concept of interface contracts generally.

> now you have to add a check for null inside your function

While I generally agree that non-const references make more sense for out-parameters (although I actually prefer return values), don't forget that it's possible for a reference to become "null" too. It's quite unlikely to happen, but if it happens it's much worse to debug than a null pointer.

Oversimplified example:

    const int& bla = *((int*)nullptr);

In our corner of said industry it's

   void foo(const T & in, const T * optional_in, T & out, T * optional_out);

> How would OP make a class, which loads content on construction which must absolutely not being changed after construction then, even within its implementation ? "Being careful" is really not sufficient in my experience, and introducing child classes just to enforce the invariant that "const" provides is actively harmful to readability.

Agreed. Also what did you mean by introducing child classes? If you move const fields from your class to a field which is an inner class, either it has an assignment operator (so you can overwrite the entire class by mistake) or not (so the outer class can't be assigned over). If you move all fields from your class to a field, it becomes substantially more tedious to access them. And I suppose you could move immutable fields to be private in a base class supplying a getter, but this feels like a hacky use of inheritance (you lose aggregate initialization, you expose an implementation detail in the header, etc).

Personally I want C++'s const fields to allow moving and swapping to replace them, but not regular methods. Is it possible for the compiler to distinguish moves/swaps and regular methods, or provide an escape hatch to allow `operator=() = default` or manually defining moves/swaps? And would the standards committee accept that type of change?

I really like the way C# did this:

    void foo<T>(T by_value, ref T by_ref, in T by_immutable_ref, out T out_only);

Append `?` to any type to make it optional. (Though that is more of a lint than truly part of the type system).

`out` parameters pass no value in and must pass a value out. Isn't that just a return value, semantically? Yes, but we didn't used to have value tuples and destructuring so we had to make do. It can still be nicer for some things:

    bool TryParse(string input, out int value)

    if (int.TryParse("123", out int value))
        // Use value

For the most part I agree with the article, but yes, for long functions I will often const locals that I want to make sure they stay constant (i.e. there is some cross variable invariant that I want to make sure always hold). I won't bother for functions of less of 10 lines (but it is not a rule and I wouldn't want it to be enforced).

I also see no issues in consting members of classes that don't have value semantics.

> I don’t need a keyword just to tell me that a variable isn’t modified during its lifetime.

I agree that this isn't very well argued, and variable re-use is a common source of bugs – especially variables that are used several times in a single function for different purposes.

On a similar point, Java has `final` instead of `const` and it does apply to local variables, including to guarantee that a variable is not only not modified, but set exactly once. Something like this:

    final String foo;
    if (condition) {
        foo = someValue();
    } else {
        foo = otherValue();
    }

Omitting any of the assignments leads to a compilation error. It works with complex if conditions with multiple branches, and even with `switch`. If a branch throws an exception, that's also acceptable as the variable is guaranteed not to be used below.

I find it pretty useful; doesn't C++ provide a similar construct?

> Diverging from TFA, local bindings are immutable (by default), however there have been rumblings about dropping this, and essentially always making them mutable because the signal is pretty low.

I hope that never happens; one of the best things in Rust is that it's easier (less typing) to make things non-mutable, which in the case of local bindings tends to encourage a more functional programming style (for instance, it encourages "let x = if foo { bar } else { baz };" instead of "let mut x; if foo { x = bar; } else { x = baz; }").

> there have been rumblings about dropping this

Really? I don’t pay attention to everything that goes on, but keep an ear to the general pulse, and I haven’t heard anything even vaguely serious about this since the mutpocalypse back in ¿2014?, which failed (sadly, in my opinion—though I was undecided back then). But I wouldn’t mind dropping immutable local bindings; as you say, it’s low signal and mostly just an annoyance. I’m interested if you have any citation, however loose; I’m curious.

—⁂—

I think the interesting difference between Rust and C/C++ in this space is the spelling, and just how significant its impact is. There are two parts to this:

① The reading order. C/C++ reading order is a hodge-podge of right to left and left to right. And what’s the difference between `T const * name` and `T * const name`? There’s a fair chance one who doesn’t know and hasn’t developed the appropriate intuition will guess incorrectly. (In pseudo-Rust terms: they’re `mut name: const T` and `const name: mut T`, and I think I got that the right way around.) See the worked example in https://en.wikipedia.org/wiki/Const_(computer_programming)#C... for a particularly painful example: `double (*const (fun(int))(double))[10]`. I believe that’s equivalent to `fun: fn(int) -> mut fn(double) -> const mut [double; 10]` in Rust (keeping raw pointers and C++ type names), which is much clearer, reading purely left to right.

② The default for constness. C/C++ default to mutable and require that you spell out any qualifiers (const in one directions, restrict in the opposite, dunno if there are others). Rust goes with a more sound hierarchical model instead, defaulting to immutable (the more restrictive) and requiring that you spell out any functional additions you want (mutability, which actually corresponds more to restrict), and I’m glossing over references versus raw pointers but because of having taken a different foundational design it’s all more sound and sensible to my eyes, with the simplest spelling providing the least privilege, and more keywords adding more privilege. (Raw pointers are spelled const/mut rather than just /mut as with &/&mut, but that’s to avoid confusion or error, given their role in FFI.) It’s an important philosophical difference; C++ templates versus Rust generics exhibit much the same difference. Well, is it any wonder that Rust has kept on surfacing LLVM bugs because noalias wasn’t exercised much in C/C++ code? When you have to add a restrict keyword, especially when the compiler doesn’t help you…

Well, the glib summary is that Rust is better in this area, with a better theoretical foundation and lessons learned from the likes of C/C++, but of course it’s more nuanced, and there are some types of architectures that don’t translate well to Rust. But it’s interesting to reflect on the differences. Because Rust basically does const all the things, and makes it easier and safer to do so. Kinda funny that I started the second half of this comment saying the spelling had a particularly significant impact, and ended up back at the memory/pointer/reference model differences. That’s definitely critical, but the spelling is a major part of it too.

> That "why" actually has an answer: "because the function might only copy the shared_ptr conditionally, and desire to remain efficient in the no-copy case".

Yeah. This blog post has a few well argued guidelines about passing smart pointers to functions, which covers this case: https://herbsutter.com/2013/06/05/gotw-91-solution-smart-poi...

> Use a const shared_ptr& as a parameter only if you’re not sure whether or not you’ll take a copy and share ownership; otherwise use widget* instead (or if not nullable, a widget&).

> Obviously that doesn't imply you should do this everywhere. I'm just pointing out it's not "wrong".

The article makes a point about contracts. In their code base, it's always wrong, since function parameters, by convention, are only allowed to be (a) non-const values, (b) const references, or (c) non-const pointers. Anything else, in their codebase indicates an error. Their point is that these three are all you need, so that getting in the habit of only using them helps maintenance, since during code review or something you know for sure that any other parameters is a mistake someone made, not an intentional choice (because of the coding standard).

> P.S. I hear optimizers can sometimes optimize const objects, though I don't have proof handy for that example, so someone else can fact-check that part.

That can happen, if a reference to your local variable is passed to a function.

For example, tried this in Godbolt [0]

  void some_func(const int& x);
  void some_other_func(int x);

  int bar() {
      int x = 123;
      some_func(x);
      volatile int y = x;
  }

The final line directly writes 123 to y if x is const (or if calling some_other_func()), but it reads again from memory as it is. This happens because some_func could do this:

  void some_func(const int& x) {
    const_cast<int&>(x) = 7;
  }

If x was `const int x`, this is UB, but if x is `int x`, the program MUST write 7 to y.

Note however that this optimization only happens (with clang) IF the value of x is a compile-time constant. If instead the value is only known at runtime, there is 0 difference - the value of x is still read from the stack, not kept in a register for example.

[0] https://godbolt.org/z/YKf4ndq1v

> Obviously that doesn't imply you should do this everywhere. I'm just pointing out it's not "wrong".)

I have to disagree here. const-int everything except stuff truly needs to be optimized significantly helps with readability, and when someone is updating their code they can other be warned of invariants if they inadvertently try to modify something that is const. Yes, it's a little verbose but worth it IMO. It also helps the compiler :)

Passing by 'const value' is not a real thing. In the implementation you can remove the const and the compiler will not complain.

You can put them in the definition and the compiler will prevent you from mutating that argument in the body of the function however.

I remove these in declarations if I see them usually. I see it as noisy and a little distracting, the caller can already see that there's going to be no side effects to that variable, whether or not the function changes its copy of it is an implementation detail.

i mean it's C++, there's like 4 ways to initialize variables that are all subtly different.

> I sometimes wonder if all this complexity is a necessary consequence of that power.

For many use cases you do not need all that knowledge. C++ is fast enough to not have to care. It's when you hit a wall that you need to get the extra tools to make things work.

I have seen developers discussing obscure optimizations for a piece of code that will only be called once several minutes, and only after unparsing a JSON String. That one less instruction call by the CPU makes no difference whatsoever.

I would say this is pretty obvious. Moving form an object will leave it in a different state than it was before. Obviously it can't be done for const objects.

A large amount of knowledge is required to be a great programmer. The choices of what to learn are far more than anyone can learn in a lifetime.

C++ gives a good abstraction for very low level operations, and has a great long term backward compatibility story. As such learning the details can be useful for anyone doing low level work over the long term. Rust is aiming at this space but doesn't have the long term track record (yet?). There are hundreds of other languages that you can also choose from with pros and cons. No matter what language you choose though, because low level details are important to you, you must learn fiddly low level bits to some extent as when move vs copy is used is by nature important.

Of course part of this is about age. C++ goes back to the early 1970s (the C roots). In that time a lot of things have change. We have learned not to do things that seemed good. We have found better ways. The way hardware works has changed. What is important to speed has changed. Compilers now do optimizations. Whatever language you choose today will look dated in 50 years.

> as it avoids having to check for nullptr

Which is nice, but the real problem always are invalid references/pointers. Which you can't check with a simple ` == nullptr`. So, if an error occurred the reference could be in any state instead of a `0`, which can easily be checked.

A reference is just a pointer in disguise, and so can still be null if created from a pointer.

The rationale behind passing by ptr is at the call site you have to use the & operator, which makes it immediately obvious to the reader that it's possible the argument is being mutated (because it's not passed by value).

In general it's even better to avoid out parameters entirely, although there are cases where you want to reuse a containers memory where it's a useful technique.

Maybe the visibility at the callsite, to make it clear what the parameter is used for because you have to take a pointer to it, and since input parameters can only be passed by value or const reference the only reason to hand out a pointer is an out parameter?

> avoids having to check for nullptr

You don't have to check for nullptr. It's the caller's job to adhere to the function contract. A function's caller can screw up in a thousand different ways: why check at runtime for one of those ways?

> by smart ptr

Unnecessary heap allocation (which is what you get with a scheme that forces passing of out parameters via smart pointer) is a bad thing.

> raw pointers are now code smell

The way I look at it is that something has to own the pointer. That ownership should be expressed via std::unique_ptr. If ownership must be shared (which is relatively rare) or you need weak pointers (even more rare), then use std::shared_ptr.

It's not a code smell to receive a pointer parameter because the function or method doesn't own the pointer. I would generally pass const references as parameters except for those cases where you may want to allow a nullptr parameter.

You'd get a language that is wildly incompatible with C and hence you may as well use a different language.

2 more instructions in GodBolt for the second version, in the end the urge to look cool and "elite" more often than not causes trouble. Unless there really is a need for complexity, it's almost always better to follow KISS principle

With the const-everywhere approach, the code reads like it's in an SSA format and is dataflow-oriented. As an extreme example, the "len - 1" expression can be substituted with yet another const variable:

    const size_t len = strlen(s);
    if (len > 0)
    {
        const size_t len_minus_one = len - 1;
        s[len_minus_one] = '\0';
    }

The additional const "variables" also add another layer of self-documentation by virtue of their names.

Not to argue your point but I think the "elite" old-sk00l C style implementation would be this:

    void truncate(char *s) { if (s && *s) s[strlen(s)-1] = 0; }

I don't have a hard and fast rule on when to use const for locals. In bigger functions, sometimes adding a const is just a nice quick way to ask the compiler if that variable gets modified later. So it can help readability. With tiny functions, it rarely matters much, you see everything at glance anyway. That's bikeshedding territory.

I tend to prefer to elide unnecessary temporary variables (then you don't need to worry whether it's const or how it should be named.. problem eliminated) and just use expressions like above. But this is also not a hard rule. In general, any hard rule smells like cults and religion.

The compiler isn't allowed to move instead of copy if the code implies a copy. What it can do however is completely elide the copy, and not call the copy constructor.

Const isn't really useful to the optimiser in any way, roughly all it does really is effect the overload resolution rules, and how the compiler maps statically initialized data in to your final binary.

> But wouldn't the ability to restrict arbitrary changes to a struct still be important?

Typically immutability in C++ is at the interface scope rather than structural, e.g. prefer this

    struct MyType {
        int x_;

        MyType( int x ) : x_( x ) {}
    };
   
    void do_the_thing( const MyType& mt ); // mt.x_ = 1; doesn't compile, mt is const

over this

    struct MyType {
        const int x_;

        MyType( int x ) : x_( x ) {}
    };
   
    void do_the_thing( MyType mt ); // mt.x_ = 1; doesn't compile, x_ is const

In c++ you normally interact with value types by copying them around. Same way you would do for an int for example. Immutability is enforced with a top level const.

I wouldn't choose C++ if I wanted to have fun. Practically any language (maybe not XML) is more fun to get things done in.

If using C++ is the right business decision, I'll use it, but I won't expect to enjoy it.

It's very rare where doing that is a good idea. A constructor is about the only time when you get much of a benefit.

Before the concept of effective finality had compiler support, it was often necessary.

Fewer than var or let?

Yes he does.

Det var kult!