[webkit-dev] Do we have a style preference about const member functions?
pkasting at google.com
Fri Jun 3 17:46:35 PDT 2011
On Fri, Jun 3, 2011 at 5:27 PM, Darin Adler <darin at apple.com> wrote:
> From a const Node* you can get:
> - a non-const pointer to a parent, sibling, or child
> - a non-const pointer to the document
> - a non-const pointer to the renderer
> - a non-const pointer to the style
> - a non-const pointer to various shadow-related ancestors and hosts
> That’s one problem. Extending the const-ness of the node to mean constness
> of everything you can get through all these pointers would be a big task,
> and it’s not clear it would be worthwhile.
>From the perspective of Node itself, I'm not sure why this would be a "big
task". There shouldn't be any const accessors that return non-const
pointers. Simply removing the "const" qualifier on all the above accessors
would make things correct, at the expense of possibly making it difficult to
use a const Node*. Adding const versions of the accessors where necessary,
which themselves vend const pointers, is not significantly harder.
The only way this is a "big task" is if there are callers that make
significant use of const pointers to do non-const actions. Then we need to
clean these up. But if they're doing non-const actions, then the cleanup is
simply to make them use non-const pointers.
Further, from the document you can get to the frame and things like the
> selection controller.
Similarly, you shouldn't be able to get non-const pointers to the frame or
selection controller from a const document pointer.
Experience with the C++ standard library taught me that a constant pointer
> to something within a collection is a difficult concept to model with const.
> The key example here is the std::vector::erase function. It seems illogical
> that you can’t call erase on a const_iterator, because the iterator is
> identifying the location within the vector, not whether you have permission
> to modify the vector. You’re not modifying something through the iterator.
Whether or not it's reasonable to have non-const functions on containers,
which modify only the container and not the elements within it, take const
pointers to elements, seems like a separable question from the rest of the
issues with using const correctly. I happen to find the standard library's
behavior here more reasonable than what you suggest, but regardless, all of
the other cases above could certainly be handled in a "clearly correct"
In other words, I don't find this problem a compelling reason to discard the
entire idea of constness when it comes to objects which participate in
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev