[boost] Re: in/out parameters, codingstylesandmaintenance

From: Bo Persson (bop2_at_[hidden])
Date: 2003-05-03 06:45:18

"Justin M. Lewis" <boost_at_[hidden]> skrev i meddelandet
news:007b01c310eb$d04cf810$9b809aa6_at_justinslaptop...
>
> And, in response to Bo Persson's latest response, since I can't reply to
it
> directly because of some outlook express quirk.
>
> "My point was (should have been?) that you can choose names so that they
> tell
> you what is going on. There should be no need to add extra qualifiers to
> point out what you really intended."
>
> It's not that simple.  You can't name a function to tell you how every
> parameter to the function is being treated, unless you want function names
> like:
>
get_something_modifies_first_param_uses_2nd_param_to_generate_value_returned
> _in_2nd_param_3rd_param_used_to_generate_1st_param(int &x, int &y, const
int
> &z);

compute_x_and_y_from_y_and_z(x, y, z);

You should rather split the interface into two separate functions, if y is
updated separetely from x and z.

> Assume that sscanf isn't part of the standard C library, and it's
unfamiliar
> to everyone, the call looks like
> sscanf(mystr, "%d %d", &x, &y);
> can you really look at that and tell that mystr is constant, and can you
be
> sure that x and y change, without looking it up?  No.  So, how would you
go
> about naming a function like that so that it's effect is clear?

I would never, ever be able to come up with a function like sscanf. This is
C-style experimental overloading; in C++ terms sscanf is sort of overloaded
on the format string.

In C++ we can avoid all this by using stringstream.

>Proper
> naming isn't a realistic solution to this problem.  And, while you may
think
> the name makes the outcome clear, that doesn't mean that it's obvious to
> everyone else, so anyone who doesn't understand your naming convention is

Well, my naming convention is to use names that everyone can understand. :-)

We are no longer bound by linkers that cannot handle names over a few
characters in length (or 110 baud Teletype terminals and 12 k core memory),
so we don't have use names like sscanf, creat, printf, etc.

> still left in a position where they have to go looking up your functions,
> and any functions your function calls, to see if a parameter is changing.
> Making it ridiculously hard to determine which of the 100 calls in a
> function you're looking at might be modifying the data you're trying to
> trace.

I wouldn't write a function with a hundred calls either. :-)

>
> Justin
>

Bo Persson
bop2_at_[hidden]