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 ) );
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.
> 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
-- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk