From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-05-02 06:55:21
>From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>
> > your solution will cause more confusion, AFAICT. When you see:
> > foo(a, b, c)
> > Are you 100% sure, without looking at the docs or the API, that
> > a, b or c is not modified? The only plausible answer is: that depends,
> > if foo is retrofitted or not. *** That's the problem ***. Anything less
> > than 100% guarantee is false security.
> I do not agree with your point.
> Everybody know that pointer and reference parameters need to be declared
> const if you are not gonna change it.
> But there are some people that do not do this (see Microsoft API for
> examples). Does it make const globally unusable?
> From your standpoint it looks that I should not declare *my* parameters
> const just because there is somebody somewhere,
> who does not do this (because somebody or me who will become used to this
> technique would have fail sense of security).
I think there's a difference, here. const is enforceable documentation. In
the following code:
const int a=123; // This may also be a parameter (it may also be a const
you _know_ a won't change, _regardless_ of who wrote f(), g() and h(), and
what they do.
However, in this code:
unless you're 100% sure that f(), g() and h() follows the convention (and as
Joel Guzman pointed out, due to all of the existing API, that's a quite
small chance), then you _can't_ rely on b not being changed.
Thus, the comparison with const doesn't hold.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk