Boost logo

Boost :

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

"Justin M. Lewis" <boost_at_[hidden]> skrev i meddelandet
> And, in response to Bo Persson's latest response, since I can't reply to
> 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:
> _in_2nd_param_3rd_param_used_to_generate_1st_param(int &x, int &y, const
> &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
> 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
> sure that x and y change, without looking it up? No. So, how would you
> 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.

> naming isn't a realistic solution to this problem. And, while you may
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at