From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-04-24 15:57:23
"Justin M. Lewis" wrote:
>
> The point all along is that this gives you the ability to enforce
> explicitness. It gives you the ability to enforce a design principle, to a
> reasonable degree, even if the caller doesn't know what he's doing, or,
> isn't paying attention. Like I said, it falls under the same principle as
> using private data. If we could trust the users of our classes to NOT break
> the rules, there'd be no reason to have an explicit way of enforcing the
> design rules. But, since it's obvious that given the opportunity people
> will violate the design rules, and directly access class data, given the
> opportunity, and not use the given interface, we all make our data private,
> and force people to go through our public interface to modify the state of
> our objects.
So then what's wrong with:
void f( T const& obj_ ); // f will not change obj_
void f( T& obj_ ); // f may change obj_
> Well, the same thing goes here. We have a design principle that people will
> violate on the caller side. People won't comment the code properly, or mark
> the function to show that the parameters are changing. So, here's a way to
> force them to.
Can you explain the difference between:
f( const_cast< T const& >( _obj ) );
and
f( in_out( _obj ) );
> And, as for making const variables in the function isn't a very effective
> way of handling this problem. I may not want the data to be constant, I may
> want to modify it all over the place, I may pass it to all kinds of
> functions that take const references, but, that doesn't mean I want it const
> throughout my function. So, the only way to make that method work would be
> to do something like:
> int x;
> const int &x_const = x;
>
> and keep 2 instances of each variable around that DOESN'T change, which
> would certainly become a maintenance nightmare. Since, I think it's
> probably the norm that functions NOT modify their parameters.
See above.
> With the wrapper classes I proposed, you only need to mark the parameters
> that DO change, which would be the rare case, rather than the common case,
> which is what you propose marking.
And what would happen if someone doesn't use this nifty new class?
In fact, it sounds like you don't even need a class:
#define in_out( obj ) obj
Noel
-- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.