Prev: performance of hash_map in combination with strings on vstudio 2003
Next: performance of hash_map in combination with strings on vstudio 2003
From: Jorgen Grahn on 2 Apr 2010 00:55
On Mon, 2010-03-29, Seungbeom Kim wrote:
> On 2010-03-29 14:18, Peter C. Chapin wrote:
>> Daniel T. wrote:
>>> It doesn't even really communicate intent if you are putting the const in
>> after the fact because you happened to notice (or a tool told you) that the
>> value didn't happen to get modified.
>> I understand what you mean and I've thought about that too. I think there is
>> still value in adding const even if after the fact. The tool says, "by the
>> way... this value is never modified." In response I add something that will
>> trigger a compile error later on if I modify the value without review. That
>> seems like a good thing. If my existing code takes advantage of the object's
>> constantness without the const actually being present, I run the risk of
>> silently invalidating my existing code when I make future modifications.
> Then how do you distinguish something that "is meant to" be const from
> something that "happens to" be const?
> I can imagine that adding const for the latter leads to the developer
> later scratching his/her head mumbling, "Why did I/they put const here?
> Did I/they really mean it or was it just accidental? Can I remove it
> safely? I don't know..."
I think you're maybe talking about different things:
- const in interfaces (const member functions, const references as
- const as a purely local thing (local variables which are const, the
void foo(const int) case)
In the latter case, I use const "because I can", if it helps
readability. I don't hesitate to remove it again if that works out
In the former case, I prefer to use const only for things which
logically should be const.
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]