强制const对象的C ++类

为什么C ++似乎不支持创建对象只能是const的类?换句话说，尝试创建非常量对象的类会出现编译时错误.在许多情况下，这似乎是很自然的事情，但是C ++不允许这样做.这是什么原因造成的?

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?

想到的第一个问题是，对于所有对象都是 const 的类型，这是很自然的事情.有些类型自然是不可变的，在某些语言中甚至建议使尽可能多的类型成为不可变的，但这与强制所有对象都是 const .

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.

在您的类设计中，控制任何成员函数是否修改对象的状态以实现不可变对象很简单.然后，封装将发挥其神奇作用，如果您不公开任何突变函数，则类型为 immutable 且与 const 一样好.您也可以(如果需要额外的安全性)将所有成员数据限定为 const ，以使编译器告诉您是否违反了自己的代码约束.请注意，将所有对象隐式强制为 const 会将您的所有成员数据标记为 const ，而您的非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?)

在 enabled 类别中，示例为 rvalue-references ；如果没有该语言功能，就无法实现完美转发或移动语义.在第二类中，您可以考虑使用lambdas—.没有它们，lambdas是无法完成的工作—其价值在于简化用户代码(必须进行卷积的代码:创建函子，声明适当类型的所有成员，提供用于初始化—进行捕获—的成员…的构造函数)，但是代码变得更加简单与lambdas.请注意，萨特花了很多时间才能说服斯特鲁斯特鲁普(Stroustrup)Lambda具有价值.

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.