Re: [boost] Re: in/out parameters, codingstylesandmaintenance

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-03 21:45:39

----- Original Message ----- 
From: "Noel Yap" <Noel.Yap_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Saturday, May 03, 2003 5:45 PM
Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance

> "Justin M. Lewis" wrote:
> >
> > Again, like I said, everything new has some associated learning curve,
and a
> > lot of what goes into boost is NEW.
>
> The interface to the smart pointers is not new -- it exists in
> std::auto_ptr<>.

So what, the interface to smart_ptrs might not be, but you ignored all of
the other examples.  Your argument is basically that we should avoid new
things whenever possible, because people would have to learn how to use
them.  And as I pointed out there are very old C ways of doing everything we
do in C++, but we all learned C++ anyway, because there are advantages to
the new C++ way of doing things.

>
> >  That quantity library that's being
> > discussed, that's NEW, it would require a learning curve.  Your random
> > library, that's new as well.  How about the spirit parser?
>
> We're discussing ways of passing parameters.  There are older ways of
> doing this.  The newer ways have a well-established and standard
> interface.
>

And, I'm proposing a yet newer way of doing this that definetly has
advantages over the old way.

> > So, which solution has the best long term maintainability?  I think mine
> > does, since it makes the intent 100% clear.  So, in 5 years, there's
still
> > no question as to what's happening.
>
> Do you know what's happening with:
>
>   void f( std::auto_ptr< T > t_ );
>
> I think in five years, this idiom will still exist as well.  Moreover,
> it's already part of the standard.
>
> Let's say std::dumb_ptr<> were added to the standard.  The above could
> be replaced by:
>
>   void f( std::dumb_ptr< T const > t_ );
>
> the only difference being the memory management of t_ at the call site
> (unless, of course, within f, t_ is passed into another function).
>
> What is necessary to change it to:
>
>   void f( std::c_in< T > t_ );
>
> My guess is that the function definition would have to change as well no
> matter what since it's now not using pointer notation.
>
> Noel

Again, how do you differentiate the use of a dumb_ptr that's just you using
a pointer, because the function is expecting data that has been allocated
with new, from an out, or in_out param?

> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>