pass by address

[Bill Cunningham]

Now there is something new I've never heard of til now from reading a C
book called "pass by address". Now am I understanding it right. I will use
this example.

I think scanf might be like this. The second parameter by wanting a pointer
is usually passed the address of the pointee using the ampersand (In know
there's an elipsis there). But a value is decalred and initialized. Their is
no pointer addresss involved. Is that "pass by address"?

int a=15;
scanf("%d\n",&n);

See no pointer address. But a pointee address is passed. The /value/ is 15.

Hope I'm clear.

 

[Bill Cunningham]

Now there is something new I've never heard of til now from reading a C
book called "pass by address". Now am I understanding it right. I will use
this example.

I think scanf might be like this. The second parameter by wanting a
pointer is usually passed the address of the pointee using the ampersand
(In know there's an elipsis there). But a value is decalred and
initialized. Their is no pointer addresss involved. Is that "pass by
address"?

int a=15;
scanf("%d\n",&n);

See no pointer address. But a pointee address is passed. The /value/ is
15.

Hope I'm clear.

Sorry my mistake. That should've been

scanf("%d\n",&a);

 

[Bill Cunningham]

Sorry my mistake. That should've been

scanf("%d\n",&a);

No value passed. No pointer address passed. If a value were passed
evidently a dereference would be needed. The value is obtained from the
passed "address" or a pointee that's not done here by the user anyway.

 

[Lew Pitcher]

Now there is something new I've never heard of til now from reading a
C
book called "pass by address". Now am I understanding it right. I will use
this example.

I think scanf might be like this. The second parameter by wanting a
pointer is usually passed the address of the pointee using the ampersand
(In know there's an elipsis there). But a value is decalred and
initialized. Their is no pointer addresss involved. Is that "pass by
address"?

int a=15;
scanf("%d\n",&n);

See no pointer address. But a pointee address is passed. The /value/ is
15.

Bill, think about this one a bit....

int a = 15;
int *p;

p = &a;

printf("%d\n",*p);
scanf("%d\n",p);

 

[Bill Cunningham]

Bill, think about this one a bit....

int a = 15;
int *p;

p = &a;

printf("%d\n",*p);
scanf("%d\n",p);

That's really simple to interpret. Anyway. You are passing to printf the
value stored at the pointee's address. With the scanf you are passing the
pointer's address. Since pointers can only hold addresses. I would say the
scanf example is "pass by address" and the printf example is "pass by
value". Is that right? But with scanf in your example; that's the first time
I've ever seen the /pointer's/ address passed. Usually it's the /pointee's/
address using the &. But then that second parameter is an elipses and I
haven't considered variable argument lists. Way over my head right now
anyway.

Bill


Bill


Bill

 

[Barry Schwarz]

That's really simple to interpret. Anyway. You are passing to printf the
value stored at the pointee's address. With the scanf you are passing the

In your terminology, the pointer points to the pointee. So this is
the same as saying you pass the value of the pointee.

pointer's address. Since pointers can only hold addresses. I would say the

No. With scanf you are passing the value of the pointer, not its
address. That value is the address of a, not of p.

scanf example is "pass by address" and the printf example is "pass by

You can, and usually do, say whatever you want but the simple fact is
that this is pass by value. The value happens to be an address. I
don't think anyone has ever said pass by int or pass by double so I
wonder why you consider this particular type of value worthy of
special terminology.

value". Is that right? But with scanf in your example; that's the first time
I've ever seen the /pointer's/ address passed. Usually it's the /pointee's/

Here you don't see the pointer's address passed, you see the pointer's
value passed. But you have seen a pointer's addressed passed just
within the past week. Go back and look at your previous messages
regarding strtol.

address using the &. But then that second parameter is an elipses and I
haven't considered variable argument lists. Way over my head right now
anyway.

You might have an easier time understanding things if you didn't keep
throwing in unrelated issues at the last minute. Variable argument
lists have nothing to do with whether you pass an object's value or
its address to a function. That decision is based entirely on the
requirements of the function.

 

[Barry Schwarz]

Now there is something new I've never heard of til now from reading a C
book called "pass by address". Now am I understanding it right. I will use
this example.

Throw the book away. It is just confusing you.

I think scanf might be like this. The second parameter by wanting a pointer
is usually passed the address of the pointee using the ampersand (In know
there's an elipsis there). But a value is decalred and initialized. Their is
no pointer addresss involved. Is that "pass by address"?

Pass by address means whatever you and the author of the book intend
it to mean. While it is true that there is no pointer OBJECT in this
code sample, there is a pointer VALUE being passed. The type of the
expression &n is pointer to int.

int a=15;
scanf("%d\n",&n);

See no pointer address. But a pointee address is passed. The /value/ is 15.

What do you mean by the phrase "no pointer address"? &n is an address
of type pointer to int.

 

[Kenny McCormack]

address using the &. But then that second parameter is an elipses and I
haven't considered variable argument lists. Way over my head right now
anyway.

You might have an easier time understanding things if you didn't keep
throwing in unrelated issues at the last minute. Variable argument
lists have nothing to do with whether you pass an object's value or
its address to a function. That decision is based entirely on the
requirements of the function.[/QUOTE]

YHBT

--
Modern Christian: Someone who can take time out from
complaining about "welfare mothers popping out babies we
have to feed" to complain about welfare mothers getting
abortions that PREVENT more babies to be raised at public
expense.

 

[Bill Cunningham]

In your terminology, the pointer points to the pointee. So this is
the same as saying you pass the value of the pointee.

Which happens to be 15.

No. With scanf you are passing the value of the pointer, not its
address. That value is the address of a, not of p.

That's what I said. The value of a pointer variable is an address. Which
is the address holding the 15.

You can, and usually do, say whatever you want but the simple fact is
that this is pass by value. The value happens to be an address. I
don't think anyone has ever said pass by int or pass by double so I
wonder why you consider this particular type of value worthy of
special terminology.

The book said pass by address. It's not my term.

 

[Bill Cunningham]

Throw the book away. It is just confusing you.

Pass by address means whatever you and the author of the book intend
it to mean. While it is true that there is no pointer OBJECT in this
code sample, there is a pointer VALUE being passed. The type of the
expression &n is pointer to int.


What do you mean by the phrase "no pointer address"? &n is an address
of type pointer to int.

Right but a *pointee's *address is passed. The a which in memory is an
int. Barry you are making things more confusing than they need to be. I
posted this to clear things up.

int a; //address of type in hold's value of 15 a variable.
int *p; //pointer's address
p=&a; //pointer's address contain's address of location in memory where
value is stored.

printf("%d",*p); // passed to printf value at address pointed to by p.

Does that make sense? This is the way I'm understanding it.

 

[Bill Cunningham]

[snip]

What do you mean by the phrase "no pointer address"? &n is an address
of type pointer to int.

The best explaination I've seen yet.
http://www.nongnu.org/c-prog-book/online/c620.html

 

[Kenny McCormack]

Surely they know?

You have to wonder. My sense (which seems also to be yours) is that they
know but just don't care. Which is really sad - sadder than if they didn't
know.

They might as well be pontificating to /dev/null - but this seems to bother
them not. Kind of like members of Congress spewing nonsense into the
Congressional Record at 3 in the morning - benefiting no one as no one is
listening.

--
"The God of the Old Testament is arguably the most unpleasant character
in all fiction: jealous and proud of it; a petty, unjust, unforgiving
control-freak; a vindictive, bloodthirsty ethnic cleanser; a misogynistic,
homophobic, racist, infanticidal, genocidal, filicidal, pestilential,
megalomaniacal, sadomasochistic, capriciously malevolent bully."

- Richard Dawkins, The God Delusion -

 

[Bill Cunningaham]

In your terminology, the pointer points to the pointee. So this is
the same as saying you pass the value of the pointee.


No. With scanf you are passing the value of the pointer, not its
address. That value is the address of a, not of p.


You can, and usually do, say whatever you want but the simple fact is
that this is pass by value. The value happens to be an address. I
don't think anyone has ever said pass by int or pass by double so I
wonder why you consider this particular type of value worthy of
special terminology.


Here you don't see the pointer's address passed, you see the pointer's
value passed. But you have seen a pointer's addressed passed just
within the past week. Go back and look at your previous messages
regarding strtol.


You might have an easier time understanding things if you didn't keep
throwing in unrelated issues at the last minute. Variable argument
lists have nothing to do with whether you pass an object's value or
its address to a function. That decision is based entirely on the
requirements of the function.

Barry I'm in no position to argue with you. I am only reading the book.
It seems to be a little simpler than others I've read. I try. If you say
there's no "pass by address" then there isn't. That's just what the book's
calling it. One tells me get a book, another get rid of the book. I
appreciate the help and that's why I ask but it's hard to connect with
someone through usenet. I don't expect it to be. Maybe scanf is a bad
example. I know this is so though...

int a=15;
int *p;
p=&a; // And my compiler complains about that. It calls it old style and
says = & if I remember right.

I am not giving up but maybe I shoud "regroup" take a break and reconsider
or something. Try at a different angle. If at first you don't succeed
well...They say try again.

 

[Bill Cunningaham]

In your terminology, the pointer points to the pointee. So this is
the same as saying you pass the value of the pointee.


No. With scanf you are passing the value of the pointer, not its
address. That value is the address of a, not of p.


You can, and usually do, say whatever you want but the simple fact is
that this is pass by value. The value happens to be an address. I
don't think anyone has ever said pass by int or pass by double so I
wonder why you consider this particular type of value worthy of
special terminology.


Here you don't see the pointer's address passed, you see the pointer's
value passed. But you have seen a pointer's addressed passed just
within the past week. Go back and look at your previous messages
regarding strtol.


You might have an easier time understanding things if you didn't keep
throwing in unrelated issues at the last minute. Variable argument
lists have nothing to do with whether you pass an object's value or
its address to a function. That decision is based entirely on the
requirements of the function.

Ok maybe I better back up and take things from another angle. I will be
studying this week though.

 

[Bill Cunningaham]

The best explaination I've seen yet.
http://www.nongnu.org/c-prog-book/online/c620.html

This is a good post above. It shows effort. I'm sure it will be ignored.

 

[James Kuyper]

On 05/03/2014 11:22 AM, Bill Cunningaham wrote:
....

When did you become "Cunning a ham"? I'll have to fix my filters.

 

[Barry Schwarz]

You have to wonder. My sense (which seems also to be yours) is that they
know but just don't care. Which is really sad - sadder than if they didn't
know.

They might as well be pontificating to /dev/null - but this seems to bother
them not. Kind of like members of Congress spewing nonsense into the
Congressional Record at 3 in the morning - benefiting no one as no one is
listening.

Yes, nothing we say will ever have any impact on Bill.

But if some poor newcomer happens upon this group looking for advice,
I think it would be nice if they could see something that tells them
to ignore Bill's absurdities.

 

[Keith Thompson]

int a=15;
int *p;
p=&a; // And my compiler complains about that. It calls it old style and
says = & if I remember right.

Really?

In very early versions of C, the compound assignment operators put
the "=" before the operator rather than after it. For example,
the old syntax to subtract 2 from i was
i =- 2;
rather than the modern
i -= 2;

This caused ambiguities if you didn't use enough whitespace,
resolved as usual via the "maximal munch" rule. For example:

i=-2;

would subtract 2 from i rather than assigning the value -2 to i.
Problems could occur for any unary operator that uses the same
symbol as a binary operator that can be part of a compound assignment
operator.

The syntax of compound assignment operators was changed before the
publication of K&R1 in 1978. Some older compilers would warn about
code that would be parsed differently under the old and new rules.
I've even used a compiler that would warn about it and then use the
old interpretation (it recognized modern operators in unambiguous
cases); fortunately we also had a more modern compiler available.

Bill, the compiler complaint you describe is consistent with
your using an old compiler that warns about code whose meaning
differs between the ancient and modern versions of the language.
As I recall, you use gcc, which certainly doesn't warn about such
things by default, and as far as I know cannot even be made to warn
about them.

And the code that was suggested to you upthread used:
p = &a;
which you changed for some reason to:
p=&a;

I'd be interested in knowing exactly what compiler you're using,
what OS you're using it on, and seeing the exact copy-and-pasted
diagnostic message from that compiler.

 

[glen herrmannsfeldt]

(snip)

In very early versions of C, the compound assignment operators put
the "=" before the operator rather than after it. For example,
the old syntax to subtract 2 from i was
i =- 2;
rather than the modern
i -= 2;

This caused ambiguities if you didn't use enough whitespace,
resolved as usual via the "maximal munch" rule. For example:

would subtract 2 from i rather than assigning the value -2 to i.
Problems could occur for any unary operator that uses the same
symbol as a binary operator that can be part of a compound assignment
operator.

The syntax of compound assignment operators was changed before the
publication of K&R1 in 1978. Some older compilers would warn about
code that would be parsed differently under the old and new rules.
I've even used a compiler that would warn about it and then use the
old interpretation (it recognized modern operators in unambiguous
cases); fortunately we also had a more modern compiler available.

I had a compiler that would do that around 1988. (As well as I
remember, both warn and then do the old way.) For some time,
I got used to putting in that extra space.

(My usual convention is not to put space around =, but to put
it around all the compound assignment operators.)

Bill, the compiler complaint you describe is consistent with
your using an old compiler that warns about code whose meaning
differs between the ancient and modern versions of the language.
As I recall, you use gcc, which certainly doesn't warn about such
things by default, and as far as I know cannot even be made to warn
about them.

Along with the X'1A', it is plenty long ago enough now.

-- glen

 

[Kaz Kylheku]

Throw the book away. It is just confusing you.

Yes; along with his collection of take-out menus, and washing instructions
labels on clothing.

"I think I understand delicate, but why do I have to wash my hands, and
be standing in cold water when doing it?"