Re: [boost] Re: class proposal

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.