On Sep 30, 6:49 pm, Summercool <[EMAIL PROTECTED]> wrote:
> On Sep 30, 4:18 am, 7stud -- <[EMAIL PROTECTED]> wrote:
> > SpringFlowers AutumnMoon wrote:
> > > we have no way
> > > of knowing what we pass in could get changed.
> > Sure you do. You look at the function's signature. In order to use
> > someone else's library, you have to know the function's signature. And
> > the signature explicitly tells you whether the value you pass in could
> > be changed.
That's not really correct. It's more a case that if you don't
know what a function does, you don't use it. Regardless of the
language, calling a function without knowing what it does is a
sure recepe for disaster.
> do you mean in C++? I tried to find signature in two C++ books and it
> is not there. Google has a few results but it looks something like
> prototype. Is signature the same as the function prototype in the .h
> file? If so, don't we usually just include <___.h> and forget about
> the rest. Documentation is fine although in some situation, the
> descriptions is 2 lines, and notes and warnings are 4, 5 times that,
> and the users' discussing it, holding different opinion is again 2, 3
> times of that length. I think in Pascal and C, we can never have an
> argument modified unless we explicitly allow it, by passing in the
> pointer (address) of the argument.
In C, that's partially true; no part of the expressions involved
in the function invocation will be modified through the function
argument unless the address is specifically taken (or the
argument has array type). The situation in Pascal, C++, Ada and
most other languages is different; Pascal and C++ have reference
parameters (called VAR in Pascal), as well as value paramters,
Ada has in, inout and out parameters.
The situation in Java is somewhat more complicated; formally,
Java only has pass by value, and there's no way a function can
modify any of the arguments. In practice, however, if the
expression has an object type, the "value" is a pointer (called
reference in Java) to the object; if the object is a well
defined "value" type (e.g. java.lang.String), it will be
immutable, but entity objects don't follow this rule, and not
all value objects (e.g. java.awt.Dimension) are well designed.
> also i think for string, it is a bit different because by default,
> string is a pointer to char or the address of the first char in C and C
> ++.
Strings in C++ are class types, with full value semantics.
> So it is like passing in the address already. it is when the
> argument n is something like 1 that makes me wonder.
C++ requires an lvalue unless the reference is to a const, so
you cannot pass 1 to a C++ function and expect/worry about it
being changed. The same holds for most modern languages, I
think, although the mechanisms involved may differ. (I'd be
very surprised, for example, if Ada allowed anything but what in
C++ would be an lvalue to be passed to an inout or an out
parameter.) In most modern languages, however, you can
circumvent the controls with enough indirections.
--
James Kanze (GABI Software) email:[EMAIL PROTECTED]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
--
http://mail.python.org/mailman/listinfo/python-list
