It is useful to say that "getting a pointer to T from an object of type S does not change S's state".
-F On Oct 28, 2012, at 2:09 PM, Peter Kasting <[email protected]> wrote: > On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak <[email protected]> wrote: > I am not sure a blanket rule is correct. If the Foo* is logically related to > the object with the foo() method and effectively would give access to mutable > internal state, then what you say is definitely correct. But if the const > object is a mere container that happens to hold pointers, there's no > particular reason it should turn them into const pointers. For example, it is > fine for const methods of HashSet or Vector to return non-const pointers if > that happens to be the template parameter type. In such cases, constness of > the container should only prevent you from mutating the container itself, not > from mutating anything held in the container, or else const containers of > non-const pointers (or non-const types in general) would be useless. > > IMO const containers that vend non-const pointers _are_ nearly useless. > > I consider logical constness to include not only "this statement has no > observable side effect" but also "this statement does not allow me to issue a > subsequent statement with observable side effects". A const Vector that > allows to to obtain a non-const element pointer, which you subsequently > mutate, means that you can mutate the vector. (Consider for example an > element destructor that removes the element from the vector.) > > If you allow const methods to return non-const pointers, it's almost always > possible to construct some chain of events that leads to mutation of the > const object or of state it can observe. It is far easier to simply make > simple rules like "const methods shall not vend non-const pointers" than try > to allow it but guarantee that all the code everyone writes is safe. > > PK > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
