By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,950 Members | 1,032 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,950 IT Pros & Developers. It's quick & easy.

no need to precede function and array names with &

P: n/a
K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?

Sep 22 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
lovecreatesbea...@gmail.com wrote:
K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?
Presumably because they though it was worth saying, even though it's
not actually true.

--
Chris "2 out of 3 isn't bad" Dollin
The shortcuts are all full of people using them.

Sep 22 '06 #2

P: n/a
Chris Dollin wrote:
lovecreatesbea...@gmail.com wrote:
K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?

Presumably because they though it was worth saying, even though it's
not actually true.
When can an alternative which does not involve the & operator not be
found? (It doesn't have to be a better alternative, just an
alternative.)

Sep 22 '06 #3

P: n/a
Harald van Dijk wrote:
Chris Dollin wrote:
>lovecreatesbea...@gmail.com wrote:
K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?

Presumably because they though it was worth saying, even though it's
not actually true.

When can an alternative which does not involve the & operator not be
found? (It doesn't have to be a better alternative, just an
alternative.)
I don't understand the question (too many `not`s, I don't know whether
to cancel or emphasise). So hoping this strikes appropriately:

* you don't need to preceed a function name with an & to get its
address: the name will decay to that address in value context anyway.

* you don't need to preceed an array name with an & to get the address
of its first element: the name will decay to that address in value
context anyway.

* however, if you want the /address of the array/, as opposed to the
address of its first element, you have to use the & operator to
do so. (This is why I said "not actually true" above.)

As to why K&R thought it worth saying, presumably it's both worth
knowing and not obvious.

--
Chris "falling further in" Dollin
"I'm still here and I'm holding the answers" - Karnataka, /Love and Affection/

Sep 22 '06 #4

P: n/a
Chris Dollin wrote:
Harald van Dijk wrote:
Chris Dollin wrote:
lovecreatesbea...@gmail.com wrote:

K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?

Presumably because they though it was worth saying, even though it's
not actually true.
When can an alternative which does not involve the & operator not be
found? (It doesn't have to be a better alternative, just an
alternative.)

I don't understand the question (too many `not`s, I don't know whether
to cancel or emphasise). So hoping this strikes appropriately:
Sorry. What I meant is that I believe there is always an alternative
without the & operator, and I asked for a counterexample.
* however, if you want the /address of the array/, as opposed to the
address of its first element, you have to use the & operator to
do so. (This is why I said "not actually true" above.)
You don't. You can use a cast instead.

int main(void) {
int a[2];
int (*pa)[2] = (int (*)[2]) a;
}

And yes, & would be better, that's why I wrote the second sentence in
my previous message.

Sep 22 '06 #5

P: n/a
Harald van Dijk wrote:
Chris Dollin wrote:
>Harald van Dijk wrote:
Chris Dollin wrote:
lovecreatesbea...@gmail.com wrote:

K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?

Presumably because they though it was worth saying, even though it's
not actually true.

When can an alternative which does not involve the & operator not be
found? (It doesn't have to be a better alternative, just an
alternative.)

I don't understand the question (too many `not`s, I don't know whether
to cancel or emphasise). So hoping this strikes appropriately:

Sorry. What I meant is that I believe there is always an alternative
without the & operator, and I asked for a counterexample.
Oh, I see.
>* however, if you want the /address of the array/, as opposed to the
address of its first element, you have to use the & operator to
do so. (This is why I said "not actually true" above.)

You don't. You can use a cast instead.
Oh bother, you're right. But:

You can use a cast to do all sorts of thoroughly unsafe things;
I wouldn't like to use one when it was both completely unnecessary
and dangerous.
int main(void) {
int a[2];
int (*pa)[2] = (int (*)[2]) a;
}

And yes, & would be better, that's why I wrote the second sentence in
my previous message.
Indeed, & would be /lots/ better.

--
Chris "falling further in" Dollin
"Who are you? What do you want?" /Babylon 5/

Sep 22 '06 #6

P: n/a
Harald van Dijk wrote:
Chris Dollin wrote:
>Harald van Dijk wrote:
>>Chris Dollin wrote:
lovecreatesbea...@gmail.com wrote:

K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?
Presumably because they though it was worth saying, even though it's
not actually true.
When can an alternative which does not involve the & operator not be
found? (It doesn't have to be a better alternative, just an
alternative.)
I don't understand the question (too many `not`s, I don't know whether
to cancel or emphasise). So hoping this strikes appropriately:

Sorry. What I meant is that I believe there is always an alternative
without the & operator, and I asked for a counterexample.
>* however, if you want the /address of the array/, as opposed to the
address of its first element, you have to use the & operator to
do so. (This is why I said "not actually true" above.)

You don't. You can use a cast instead.

int main(void) {
int a[2];
int (*pa)[2] = (int (*)[2]) a;
}

And yes, & would be better, that's why I wrote the second sentence in
my previous message.
You could also have done:
FILE *f = (FILE*)a;

That does not mean it is correct, or will "work".
Don't cast, unless you absolutly know why it is ok to do
that cast.
Sep 22 '06 #7

P: n/a
Nils O. Selåsdal wrote:
Harald van Dijk wrote:
You don't. You can use a cast instead.

int main(void) {
int a[2];
int (*pa)[2] = (int (*)[2]) a;
}

And yes, & would be better, that's why I wrote the second sentence in
my previous message.
You could also have done:
FILE *f = (FILE*)a;
Yes, casts at times let you get away with broken code. You have not
explained how my code is broken. If my code is not broken, the fact
that it is far more fragile is not really relevant, considering I
already admitted it was bad style.

Sep 22 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.