Re: C++ more efficient than C?
On 8 Apr., 21:40, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
[snips]
On Tue, 08 Apr 2008 10:45:09 -0700, peter koch wrote:
Right. But this is only true in such trivial cases as the above where
you allow such an absurd name. Replace the name with some reasonable
one, such as square or fibonacci, and no one will be in doubt.
Really? Fine: try this:
string a, b;
a = somevalue;
b = trim(a);
In C++ you would never write as above. It would be
string a(somevalue);
string b(trim(a));
or
string a = somevalue;
string b = trim(a);
If the intent of trim is to act like the similar function in PHP - i.e.
to remove leading and trailing whitespace - what does this tell us about
the effect, if any, on a?
I would assume this would mean that there would be no effect on a. If
trim would trim its parameter, the name of the function would indicate
this.
Oh, right, nothing. Hmm. So what's a good name for this? How about, =
oh,
trim_which_modifies_its_parameter()? I don't want to type that.
to_trim would be my choice, as_trim being the non-modifying name in
those rare cases where I would be in doubt.
I have
heard others complain like you, but never found statements such as the
above to be a real problem.
Yet the problem remains: C++ makes the issue of whether a passed
parameter gets modified or not absolutely indeterminate at point of call
- meaning the poor bastard having to maintain the code has no hope, by
reading the portion of code he's trying to work on, of figuring out what
is actually going on.
This is not a particularly good design.
I can't see how else you could design the code (unless you suggest
demanding pointers for the parameters which is not at all clearer), so
lets not discuss the design of C++ here. It is designed as it is and
not anything we can really do anything about.
A much larger problem has been in absurd declaration such as the above.
Are you quite sure that it should read int x = 3; int y; (as you imply=
)
I implied that? Where? I wrote int x = 3, y; There's only one semi=
colon
in there, only one instance of "int". Why would you think this somehow
"implies" a completely different manner of writing code? Does your way
of writing it imply it should be re-done in Pascal? No? Why not? =
You
seem to be taking purely arbitrary paths, so why not that one?
It was just a remark about clarity - namely that I found your way of
declaring the variables unclear.
Also I do not see the connotion to Pascal. Here it was allowed (I
believe!) to declare several variables together - e.g. var i,j:
integer;
If you need to look at the code, you should know what func does anyway!
Why? Since it cannot modify the passed parameter, what it does is
fundamentally irrelevant to debugging the local problem. That is, unles=
s
someone invented a method of passing parameters which would then be
modified, but making this absolutely invisible to the maintenance
programmer looking at the calling code.
If you need to have a look at a piece of code, do you seriously
suggest that this can be done without at least a casual knowledge
about what called functions do?
Oh, yeah, they did exactly that, didn't they? Good, now instead of
focusing on *this* piece of code, one has to examine every called
function, not for its effects on output and the like, but its effects on
*local* variables it gives absolutely no indication it will be modifying.
Information hiding can be good. This sort is bad.
Certainly. That is why you choose your function (and variable) names
with care.
/Peter