On May 30, 2011, at 4:19 PM, Geoffrey Garen wrote:
Updated:
Const member functions:
Do use const member functions in classes that are independent data holders,
to help distinguish between references that can modify the data and
references that can't.
Do not use const member
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?
Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On May 31, 2011, at 10:47 AM, Geoffrey Garen wrote:
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
On Mon, May 30, 2011 at 11:32 PM, Maciej Stachowiak m...@apple.com wrote:
A linked list node or tree node could useful have const methods, which give
only const pointers/references to other nodes. If there is a reason const
references to DOM nodes or renew objects are not useful, it is not due
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
On May 31, 2011, at 10:54 AM, Peter Kasting wrote:
On Mon, May 30, 2011 at 11:32 PM, Maciej Stachowiak m...@apple.com wrote:
A linked list node or tree node could useful have const methods, which give
only const pointers/references to other nodes. If there is a reason const
references to
On Tue, May 31, 2011 at 11:00 AM, Maciej Stachowiak m...@apple.com wrote:
I agree that const should be used for logical constness. The rule should
not be merely doesn't alter any data members of this object but rather
does not alter observable state of this object or vend any type of pointer
I agree that const should be used for logical constness. The rule should
not be merely doesn't alter any data members of this object but rather
does not alter observable state of this object or vend any type of pointer
or reference by which observable state of this object could be altered.
Hi there.
Since a couple of days ago (when?), our trac/wiki is not appearing as
relevant on google search results anymore.
I guess google blacklisted the site because of some sort of spam or a
redirect against the rules.
Does anyone know if something changed recently? Does someone has a
google
Hello fellow WebKittens,
Recently many non-WebKitGTK+ developers have been kind enough to debug
failures that only show up on WebKitGTK+. Since WebKitGTK+ typically
tracks bleeding-edge GNOME, compiling can be a daunting task for those
not up on the latest GNOME releases. In particular, some of
Someone could check:
https://www.google.com/webmasters
I no longer have access (but I could go through the process of getting
access if needed).
-eric
On Tue, May 31, 2011 at 1:37 PM, Ademar Reis ademar.r...@openbossa.orgwrote:
Hi there.
Since a couple of days ago (when?), our trac/wiki is
On May 31, 2011, at 12:08 PM, Geoffrey Garen wrote:
I agree that const should be used for logical constness. The rule should
not be merely doesn't alter any data members of this object but rather
does not alter observable state of this object or vend any type of pointer
or reference by
Hi,
On Tue, May 31, 2011 at 4:37 PM, Maciej Stachowiak m...@apple.com wrote:
I agree that one useful distinction is whether a particular kind of object
is every manipulated via const pointers or references. If we never use const
references/pointers to a particular kind of object, then it is
On May 31, 2011, at 5:55 PM, Brent Fulgham wrote:
Hi,
On Tue, May 31, 2011 at 4:37 PM, Maciej Stachowiak m...@apple.com wrote:
I agree that one useful distinction is whether a particular kind of object
is every manipulated via const pointers or references. If we never use const
On May 31, 2011, at 8:44 PM, Maciej Stachowiak wrote:
For example, the compiler does not tell you that the following implementation
of Node::previousSibling() (currently in our code!) is totally wrong from the
logical const perspective:
Node* previousSibling() const { return
15 matches
Mail list logo
