Question

First let me ask a general question:

• It seems to me that C++ is a language whose point is to provide tons of capabilities, to give the programmer the greatest possible flexibility in doing things in whatever way he finds suitable. In other words, it’s a flexible language that allows the programmer to express himself in more ways than probably any other language that I’ve seen. Is this right?

Then a specific one:

• Why doesn’t C++ seem to support creating classes whose objects can be only const? In other words, classes where you get a compile-time error if you try to create a non-const object of it. This seems like a natural thing to do in many cases, yet C++ doesn’t allow it.
  What is the reason behind this? (Sure, I can make all the members const, but that is somewhat of a copout.)

Answer 1

Why doesn’t C++ seem to support creating classes whose objects can be only const? In other words, classes where you get a compile-time error if you try to create a non-const object of it. This seems like a natural thing to do in many cases, yet C++ doesn’t allow it. What is the reason behind this?

The first question that comes to mind is when having a type for which all objects are const is a natural thing. There are types that are naturally immutable, in some languages it’s even recommended to make as many types as possible immutable, but that is not the same thing as enforcing that all objects are const.

In your class design it is trivial to control whether any of your member functions modifies the state of the object achieving an immutable object. Encapsulation will then do its magic, and if you don’t expose any mutating function, then the type is immutable and as good as const. You can also (if you want the extra safety) qualify all your member data as const to let the compiler tell you if you violate your own constraint in your own code. Note that forcing all the objects to be const implicitly would mark all your member data to be const, and your non-const functions useless.

Given that the high level effect can be achieved in different ways with little cost, why would you make a complex language even more complicated for no added value?

While the question above may seem rhetoric it is not. One of the criteria to consider extensions to the language is the return on investment: What will we be able to do with this feature that was not possible without it? (i.e. is this an enabling feature?) If the answer is nothing, then the next question is How much simpler will programmer’s life be with this feature compared to the current state? (for non-enabling features, what is the value of adding them?)

In the enabling category the example would be rvalue-references; without that language feature, you cannot implement perfect-forwarding, nor move-semantics. In the second category you can consider lambdas — there is nothing that can be done with lambdas that was not doable without them — whose value lies on simplifying user code (code that would have to be convoluted: create a functor, declare all members of the proper types, provide a constructor that initializes — does the capture — the members…) but the code becomes much simpler with lambdas. Note that it took quite a bit of arguing from Sutter to convince Stroustrup that lambdas had value.

In your case, what you are asking for is not an enabling feature, and the cost of supporting the use cases without the feature is low enough that it does not grant providing that as a core language feature.