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

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-03 22:23:07

I spent a lot of time doing COM and working in Win32 myself, the difference
was, in my experience, what I did in Win32, was usually pretty stand alone
and isolated.  I work on a HUGE verification environment now.  There are
over 2300 source files in the environment, a lot of the files stretch on for
10's of thousands of lines.  Some of the code was written when I was still
in highschool.  Now, we're at a unique point, where a lot of this is going
to be rewritten.  I've spent HOURS chasing function declarations all over
the source trying to find out what a function MIGHT do, in order to try to
understand code coverage analysis, and doing debugging work, and patching to
allow for new features.  A big part of the problem that I face all the time
is trying to determine where variables are changing.  It's just too much
work to go looking all of the functions up, and like I said, it would be
SOOO much easier to be able to just do a simple search for

x =
out(x)
in_out(x)

to sort through a 3k line function to see where in that mess my param is
changing, as opposed to searching for every place x is used, and then trying
to determine what the functions it's being passed to are doing.

I had this same issue working on the GNU MIPS assembler.  Wondering, does
this function call change the thing I'm trying to understand here?  And you
want to talk about nightmares, trying to trace these recursive macros back
to their origins.

So, if you haven't ever run across this problem, be glad, it's really just
no fun to deal with

----- Original Message ----- 
From: "Gregory Colvin" <gregory.colvin_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Saturday, May 03, 2003 8:06 PM
Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance

> On Saturday, May 3, 2003, at 20:46 America/Denver, Justin M. Lewis
> wrote:
> >> On Saturday, May 3, 2003, at 18:07 America/Denver, Justin M. Lewis
> >> wrote:
> >> From: "Gregory Colvin" <gregory.colvin_at_[hidden]
> ..
> >> Agreed.  And when they are necessary I am happy enough with
> >> pointers -- or at least my unhappiness is not reduced by
> >> any of various wrappers proposed here.
> >
> > The difference here is, at the call site you still get an explicit
> > description of how the data is being used, with just a pointer,
> > there's no
> > information given.
>
> Yes, I understand that.  But I spent many years in purgatory
> implementing
> and using COM and Win32 interfaces, with lots of out and in/out
> parameters,
> including doubly indirected pointers, and I just don't recall ever
> needing a
> facility like this.  The problem you are working hard to solve just
> isn't
> a problem in my experience, so I have zero willingness to clutter my
> code in
> an attempt to solve it.  Your mileage may vary, as ever.
>
> Anyway, I jumped into this thread mainly to opine that Noel's
> suggestions
> were not, so far as I could see, any better than your proposal, not to
> rehash what we have already discussed.
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>