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
