Similar thing: doc->frame()->document().
The solution should be defining both const and non-const members:
const Frame* frame() const { reutrn m_frame; }
Frame* frame() { return m_frame; }
2011/6/2 Yong Li <yong.li.web...@gmail.com>:
> I think we should add a rule like "a const member function should
> never return non-const pointer/reference".
>
> I have seen the problem in many places that you can get non-const
> reference on a const object.
>
> For example, InlineTextBox has
>
> InlineTextBox* prevTextBox() const;
> InlineTextBox* nextTextBox() const;
>
> Assume you have a function: void myFunction(const InlineTextBox* textBox)
>
> When the text box has a sibling, you can easily get a non-const
> pointer by calling textBox->nextTextBox()->prevTextBox(), which sounds
> ridiculous.
>
> 2011/5/31 Geoffrey Garen <gga...@apple.com>:
>>>>> Even in a class that is used in a tree, I still think simple member
>>>>> variable accessor methods (that do not return tree neighbors) should be
>>>>> const.
>>>>
>>>> OK. Why?
>>>
>>> Because it indicates to me and the compiler, that the method doesn't have
>>> side effects.
>>
>> A const member function can have side effects. It can modify any global
>> state outside the object. It can also modify sub-objects inside the object,
>> and return non-const references to sub-objects and related objects that
>> might be used to produce side-effects at any time.
>>
>> It's exactly statements like this that make me think that const member
>> functions are a bad idea -- people think they provide a guarantee, but they
>> don't.
>>
>> Geoff
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
