Boost logo

Boost :

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2004-01-05 18:13:39

"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

> [snip]

> If we were to try to compare the two different notion const-correctness,
> that is,
> (as written in the faq):

> "Some programmers feel this should be a signal to the compiler that the raw
> bits
> of the object's `struct' aren't going to change, others feel it means the
> *abstract* (client-visible) state of the object isn't going to change."

> on one hand the notion of shallow raw bits objects and the abstract
> observable state/behavior of the
> class, then it should be clear that the latter is a much more powerful
> concept. If followed, it really
> makes it easier to show certain things holds in the program. Consider also
> that the "observeable behavior"
> is the idea used in formal operational semantics.

Actually, the key distinction here is not between ``shallow raw bits''
and ``abstract observable state/behavior,'' but rather whether the
state of the pointee is part of the state of the pointer/object that
contains the pointer. But there is not a single answer, it depends on
the use case.

Consider, for example, an object that refers to a file. This object
contains an int which is a file descriptor. If you call this object
``file'', it might be logical for a ``write'' function to require a
constant instance of this ``file'' object. If you call this object
``file_descriptor,'' however, one could easily argue that the state of
the file descriptor is not affected by the write, and thus a constant
instance can be used.

It is clear that there are use cases for smart pointers with deep
constness, and this need can be filled by a policy-based pointer class.
It would not be useful, however, to eliminate the existing shared_ptr
with real pointer-like semantics, because there are important use cases
for smart pointers with those semantics also. Furthermore, it would be
highly impractical since the new semantics would break a large amount of
existing code for no good reason.

Jeremy Maitin-Shepard

Boost list run by bdawes at, gregod at, cpdaniel at, john at