Idiomatic Way to declare C++ Immutable Classes

Question

So I have some pretty extensive functional code where the main data type is immutable structs/classes. The way I have been declaring immutability is "practically immutable" by making member variables and any methods const.

struct RockSolid {
   const float x;
   const float y;
   float MakeHarderConcrete() const { return x + y; }
}

Is this actually the way "we should do it" in C++? Or is there a better way?

Solution 1

The way you proposed is perfectly fine, except if in your code you need to make assignment of RockSolid variables, like this:

RockSolid a(0,1);
RockSolid b(0,1);
a = b;

This would not work as the copy assignment operator would have been deleted by the compiler.

So an alternative is to rewrite your struct as a class with private data members, and only public const functions.

class RockSolid {
  private:
    float x;
    float y;

  public:
    RockSolid(float _x, float _y) : x(_x), y(_y) {
    }
    float MakeHarderConcrete() const { return x + y; }
    float getX() const { return x; }
    float getY() const { return y; }
 }

In this way, your RockSolid objects are (pseudo-)immutables, but you are still able to make assignments.

Solution 2

I assume your goal is true immutability -- each object, when constructed, cannot be modified. You cannot assign one object over another.

The biggest downside to your design is that it is not compatible with move semantics, which can make functions returning such objects more practical.

As an example:

struct RockSolidLayers {
  const std::vector<RockSolid> layers;
};

we can create one of these, but if we have a function to create it:

RockSolidLayers make_layers();

it must (logically) copy its contents out to the return value, or use return {} syntax to directly construct it. Outside, you either have to do:

RockSolidLayers&& layers = make_layers();

or again (logically) copy-construct. The inability to move-construct will get in the way of a number of simple ways to have optimal code.

Now, both of those copy-constructions are elided, but the more general case holds -- you cannot move your data from one named object to another, as C++ does not have a "destroy and move" operation that both takes a variable out of scope and uses it to construct something else.

And the cases where C++ will implicitly move your object (return local_variable; for example) prior to destruction are blocked by your const data members.

In a language designed around immutable data, it would know it can "move" your data despite its (logical) immutability.

One way to go about this problem is to use the heap, and store your data in std::shared_ptr<const Foo>. Now the constness is not in the member data, but rather in the variable. You can also only expose factory functions for each of your types that returns the above shared_ptr<const Foo>, blocking other construction.

Such objects can be composed, with Bar storing std::shared_ptr<const Foo> members.

A function returning a std::shared_ptr<const X> can efficiently move the data, and a local variable can have its state moved into another function once you are done with it without being able to mess with "real" data.

For a related technique, it is idomatic in less constrained C++ to take such shared_ptr<const X> and store them within a wrapper type that pretends they are not immutable. When you do a mutating operation, the shared_ptr<const X> is cloned and modified, then stored. An optimization "knows" that the shared_ptr<const X> is "really" a shared_ptr<X> (note: make sure factory functions return a shared_ptr<X> cast to a shared_ptr<const X> or this is not actually true), and when the use_count() is 1 instead casts away const and modifies it directly. This is an implementation of the technique known as "copy on write".

Now as C++ has developed, there are more opportunities for elision. Even C++23 is going to have more advanced elision. Elision is when the data isn't logically moved or copied, but just has two different names, one inside a function and one outside.

Relying on that remains awkward.

Comments

[BlamKiwi]

The semantics I particularly want, at least for this project, are the same as in "900 Pound Functional Languages" like Haskell where any new state has to be explicitly (type) constructed.

[Martin Moene]

You may consider using the immutable value–mutable companion idiom.

[paercebal]

@MartinMoene : That "idiom" still builds non-copy-assignable and non-move-assignable value objects (or relies on the heap). oikosdev's solution does not suffer for that drawback, and doesn't need a (companion) boilerplate. It just works... Why complicate everything?

[CinCout]

Why suggesting the use of class? Even struct with private member variables will do!

[Vorac]

or std::unique_ptr<const X>, which can be returned by value via std::move().

[jack_1729]

@chrphb : Here is an assertion my me - we did this because "For a type to be CopyAssignable, it must have a public copy assignment operator". Am I thinking right ?

[Utkarsh]

I read in this post dzone.com/articles/how-to-create-an-immutable-class-in-java that immutable classes cannot be inherited by any other class and that's done by final keyword in Java. On searching, I found that final keyword is also now present in C++; to confirm, shouldn't we use that in the C++ implementation of an immutable class too?

[Eljay]

struct and class are the same thing, with but one defaulting to public: and one defaulting to private:. Suggesting the use of class isn't a difference. Other languages, like C# or D, there is a semantic difference.