Const ref and rvalues again...

[Timon Gehr]

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, ...)