On Thu, Jun 2, 2011 at 1:02 PM, Geoffrey Garen <gga...@apple.com> wrote:
> Perhaps we could at least encourage const-correctness for newly-written > classes? By this I mean both adherence to the logical-constness rules you > stated earlier as well as not adding non-const accessors and members unless > needed -- otherwise it's easy to just err on the side of never using const > anywhere. > > > I'm still not convinced that it's meaningful to talk about a "const-correct > class". The const that you put on a member function only has meaning when > somebody uses a const pointer or reference to your class. More importantly, > any design issues raised or bugs caught by const only get tested when > somebody uses a const pointer or reference to your class. > > So, the key to const-correctness is deciding when to use const pointers and > const references -- once you're using a const pointer or reference, the > compiler will tell you which member functions need to be const. > Hmm. Relying on compilers to check constness is inherently scary because they check physical constness, which is neither a superset nor subset of logical constness, which is what we want to be checking. At least in my head, my design process is generally "the class should expose as few APIs as possible, and they should be const wherever possible (without violating logical constness)". Obviously in some sense classes aren't built in a vacuum and their external users determine the APIs they expose, but I don't like the "constness is determined purely by external need" route because it leads to problems like "the first user of this class wanted to mutate everything, so I made no members const, and now I can't trivially add a non-mutating const usage because it requires plumbing constness through everywhere". Maybe what I'm trying to say is that it's generally feasible to design with "make usage patterns const where possible" in mind, but it's harder to retrofit. Or maybe I'm saying it's easier to make things non-const later than to make them const. PK
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev