Re: [boost] Re: class proposal

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

I'd be against the idea of doing something like

const int x;
func1(x);
func2(x);
func3(const_cast<int &>(x));

When I see const on a variable I expect it to not change anywhere.  I'm
against violating const when possible, so I wouldn't do it as a general
design rule.  const would lose all meaning in a program where you started
const_casting all over.

And, as far as the macro goes
> #define in_out( obj ) obj
There's no guaranteed enforcement there.  People who feel like using it
might, those who don't feel like using it won't.  So, no one would have to
follow the rule.  With the classes, they're type checked at compile time, if
you don't specify func3(out(x)); with my method, it will not compile.
People calling my function would have to decorate the function call
appropriately.

----- Original Message -----
From: "Noel Yap" <Noel.Yap_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Thursday, April 24, 2003 1:57 PM
Subject: Re: [boost] Re: class proposal

> "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.
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>