From: Jorgen Grahn on
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
arguments etc).

- 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
better.

In the former case, I prefer to use const only for things which
logically should be const.

/Jorgen

--
// 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! ]