From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-04-24 11:53:27
>From: "Justin M. Lewis" <boost_at_[hidden]>
> Everyone is ignoring the possibility of objects that can't be copied in
> this, too. Some objects intentionally hide their operator =, making
> returning it from a function impossible.
It's not ignored; it's covered by the earlier mentioning of using T & or
const T &, as appropriate, in the function signature.
> And, I think a lot of people are missing a big part of the point here.
> can enforce the use of making it explicit at the point of invocation that
> the param is changing. The compiler will give an error if a c_out or
> c_in_out object isn't passed. You can't enforce a naming convention or
> commenting at the point of invocation, at least not everywhere, like where
> work. So, by writing a function using these objects, it's a guarantee
> anyone who uses my functions has to make it explicit what the effect of
> calling my functions is.
Well, you can still get the same effect, without it. With your classes, the
caller has to explicitly state that the function may modify some parameters,
and the compiler checks for this. In the same way, the caller can declare
variables "const", and in this way state the opposite - that the function
may _not_ change them, and the compiler checks for this.
In other words:
Using standard C++:
const int may_not_change=...;
In a const-correct program, a variable not marked as "const" is an
indication that it may change, just like your classes indicate the opposite.
An advantage of this approach is that it's idiomatic usage, so anyone
maintaining the code (including adding new functions), don't need to know
about the particular way it's done here (if using in_out() and out()).
In summary: Use "const", and teach your co-workers to use it, as well. It's
good, healthy, low-calorie, and found in every modern compiler. :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk