On 11/07/2012 06:52 PM, martin wrote:
On Wednesday, 7 November 2012 at 16:57:47 UTC, Timon Gehr wrote:
That is the main thing, but C++ also has a 'mutable' keyword.
Right, I forgot this inconspicuous little keyword. It really is a huge
hole in C++'s const system.
If your struct doesn't support any const operations, it most likely
has good reasons not to.
Either that, or someone hasn't bothered to annotate.
Hehe, yeah, the latter being more likely.
You got it exactly reverse. const harms encapsulation because it
exposes some details about implementations. It is often not applicable
in sufficiently dynamic code.
I don't see it that way.
You do not give a justification.
I find it very useful to know that an argument
won't be modified.
That is unrelated and does not necessarily follow, but that it does in
some cases is the main reason why const is useful even though it weakens
encapsulation.
Example: suppose we have a large array (static array
or wrapped in a struct) and need it as input for some independent
operations. By knowing it won't be touched (passing by const ref) it is
immediately clear that the operations can be run in parallel. Otherwise,
one would need to go through the operations' implementation to determine
if parallelization is possible.
You have to do that anyway if it the operation is not at least 'const
pure' and you need to guarantee that no other thread is in fact
modifying the data. But even then I do not see how that helps
encapsulation. Naive parallelization is just one of the examples that
shows that encapsulation can be harmful in some specific cases.
You do not see issues with changing the interface based on
implementation details?
I find it okay to require all possible changes to an argument passed by
reference to be required to be directly visible by the caller, just to
prevent accidentally missing side effects. Suppose a function takes a
const reference parameter and is called at a site using an rvalue. After
some time, that function is updated so that its parameter is or may be
changed, changing the const ref parameter to a ref parameter. That may
lead to big issues for the call sites. A compiler error would make sure
the affected call sites are inspected and updated instead of potentially
introducing regressions.
Often there is nothing to be seen for the caller. (lazy initialization,
caching, internal state update part of a larger computation, ...)
