Re: [boost] Re: class proposal

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-04-24 14:48:02

>From: "Justin M. Lewis" <boost_at_[hidden]>

> Ugh, that's still missing the point.  Using T& or const T& still requires
> chasing down function prototypes when I'm trying to track where a variable
> MIGHT be changing.

I addressed that part in what followed: Use of const.

Therefore, I did not miss the point. However, did you get mine? The use of
const to achieve the same?

> And using meaningful variable names, int may_change,
> isn't even really feasible, and could be come much more complicated than
> simply saying
> func(out(myobj));

The "may_change", etc. was just to illustrate the example code.

> Let's say I have a non-copyable object that is a class member, I'm
certainly
> not going to name it m_myobj_may_change, that doesn't make sense

I've never suggested such a thing, either, that had nothing to do with the
point being made.

> This is like why we have private data in C++, because we KNOW that if we
> give people the opportunity they wouldn't use the proper methods to get
and
> set the internal data, so we don't trust people to properly use our
classes,
> we hide the data from them we don't want them to touch.  You're enforcing
> your design principle.  The same goes here, you would like for people to
> make it clear that when they call this function the variable being passed
in
> will be modified

Wait a minute, you have to make sure what goal you have. You said that using
T & and const T & only show at the _called_ side, not the caller's side, if
a variable may be modified. That's correct. Thus, you need no mechanism in
the function, itself, to show whether or not the parameters may change, as
the function signature shows that.

As I first understood your proposal, it was to be able to enforce the same
constraint on the caller's side: That the caller gets to determine what may
or may not be changed. This may be done using const, as shown.

Now, the function author, and the function user, both are able to determine
and enforce what may be changed, or not. So what's the problem?

What you're saying is that you'd like the function to enforce that the
caller specifies, in the calling code, what parameters may be changed, or
not (according to the function signature). Is this really the function's
responsibility? To force a certain way of using the function, because they
_may_ not know what they're doing? It may be hard to break this to them, but
if they don't know what they're doing, maybe they shouldn't use C++? :)

The point I was making is that if the function and the calling code is
written correctly, there's no problem. If someone uses a function, and calls
it with a non-const variable, and it takes a non-const reference, then,
frankly, they get what they ask for.

You make an analogy with classes. Yes, let's do that. If you try to access a
class's private member from outside the class (and not being a friend),  you
get an error. There's no way of changing that, by using in_out(), or
whatever. Likewise, if you try to call a function taking a non-const
reference, with a const object, you also get an error. Again, there's no
special syntax to get around that (short of casting).

> I can't count on them to conform on their own, so I come
> up with a mechanism that helps enforce it.

Again, this may not be the function's responsibility to enforce. Also,
people who are familiar with using const for the same purpose, may just find
such code harder to read.

> Look at systems programmers,
> there are instances where bits in registers marked reserved, that were
> actually still readable and writable, were used to store some extra data.
> Now, at least in the processors I've been working on, bits marked reserved
> are not writable.  The point here is, given the opportunity people will
> violate the rules, so the best you can do is make it more difficult to
> violate the rules.

Yes, but you do that by enforcing the constraints in _your_ functions, not
the calling code.

> That's really the point of this, it's an enforcable way of explicitly
> decorating the invocation of functions that change the params passed in.
> Keep that in mind, decorating the INVOCATION, to prevent me from having to
> chase down 100's of function prototypes to see which params are marked
const
> and which aren't.

You must of course do what you think is best in this situation. I just hope
you got my point that if the calling code uses const, you don't have to look
at the function signature, to determine what variables may or may not be
changed by a function.

Regards,

Terje