Re: [boost] Re: class proposal

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-04-24 13:13:45

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.  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));

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, especially
when it's passed to functions that can't change it.  The only way around
that would be to create a reference to my object when I want to change it to
give it a meaninful name.  But, again, that would require the cooperation of
people using my library, and it's a solution I can't enforce.

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, I can't count on them to conform on their own, so I come
up with a mechanism that helps enforce it.  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.

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.

Justin

----- Original Message -----
From: "Terje Slettebø" <tslettebo_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Thursday, April 24, 2003 9:53 AM
Subject: Re: [boost] Re: class proposal

> >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.
> You
> > 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
> I
> > work.  So, by writing a function using these objects, it's a guarantee
> that
> > 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:
>
> Your suggestion:
>
> int may_not_change=...;
> in_out<int> may_change=...;
>
> f(may_not_change, may_change);
>
> Using standard C++:
>
> const int may_not_change=...;
> int may_change=...;
>
> f(may_not_change, may_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. :)
>
>
> Regards,
>
> Terje
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>