Re: [boost] Re: in/out parameters, codingstylesandmaintenance

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?

No.

> 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
reference)

f(a);
g(a);
h(a);

you _know_ a won't change, _regardless_ of who wrote f(), g() and h(), and
what they do.

However, in this code:

int a=123;
int b=456;

f(a,b);
g(in_out(a),b)
h(a,b);

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.

Regards,

Terje