Re: [OT] A bit confused on pointers...
Re: [OT] A bit confused on pointers...
- Subject: Re: [OT] A bit confused on pointers...
- From: Steve Checkoway <email@hidden>
- Date: Fri, 30 Dec 2005 09:16:27 -0800
On Dec 30, 2005, at 8:45 AM, Greg Herlihy wrote:
C++ programmers will tend to put the * or & (for references) near
the type
(where it makes more sense for readability and maintainability.)
And since
the entire type-before-the-name convention in C/C++ is something of
a failed
experiment, the declarations are best made on separate lines for
the same
reasons:
int* b;
int* a;
Many people do different things. I use
int foo;
int *bar;
int& baz = foo;
The reason for the & next to the int is mostly because I will never
declare multiple references on the same line. That said, it's
probably bad to be so inconsistent and others do it other ways.
It's also useful when declaring types:
typedef struct {
int x;
int y;
} Point, *PointPtr;
A C++ programmer would likely name the struct "Point" and use a
typedef to
name PointPtr.
Probably not. Since there is no need to include the struct keyword
when using struct Point in c++, most people would likely not typedef
it. As for PointPtr, there's no point to that in most cases and it
doesn't really help readability.
Then there is the & operator, which is often used in conjunction
with pointers; and of course, this character does have a different
meaning when used as a binary operator.
But there's never any ambiguity about whether the operator is unary
or binary in an expression.
Never? The * operator is inherently ambiguous. Consider:
a * b;
Is b a pointer to a or is the expression a multiplied by b? Without
any
context it is impossible to know for sure. Either interpretation
constitutes
a legal expression in C.
Not true. That expression always means a multiplied by b in c. (In c+
+ there might be some ambiguity as to which operator*() to use from
things like template specializations and the like.) That can never be
interpreted as dereferencing b.
a and *b are both rvalues and the grammar prohibits two rvalues from
being adjacent. If you try, you get a parse error:
$ cat parse.c
int main()
{
int a, b;
a b;
return 0;
}
$ gcc parse.c
parse.c: In function 'main':
parse.c:4: error: parse error before 'b'
Nothing you can do can force a * to be anything but multiplication
though.
If I change it to int a, *b; ((int)a) * b; (where the cast is to
prevent gcc from thinking a is a function) then I get:
parse.c:4: error: invalid operands to binary *
- Steve
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden