12/30/05 5:45 AM, "Camillo Lugaresi" <camillo.lists (AT) gmail (DOT) comwrote:
30/dic/05, at 11:10, Andreas Mayer wrote:
>
>Am 29.12.2005 um 21:39 Uhr schrieb Clark Cox:
>
what is confusing about the syntax?
If (ptr) is a pointer, then (*ptr) is whatever it points at
>
>Umm what's *not* confusing about that syntax?
>
>* is usually associated with multiplication.
>
>And as Pontus pointed out, it doesn't help that the same symbol is
>used in the declaration of pointers. To make things worse, it's
>customary to write int *ptr instead of int* ptr, which would
>be more accurate in my opinion. The '*' modifies the type, after
>all, not the identifier.
Wrong!
int *a, b;
What type is b? int. If you want two pointers to int, write:
int *a, *b;
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;
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.

>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.
Greg
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com
This email sent to bsdarchive (AT) developershed (DOT) com

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

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Dec 30, 2005, at 11:16 AM, Steve Checkoway wrote:

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.

Not if "a" is a type name (which makes "b" a pointer to an "a")

Thus the need for context (is "a" a variable or a type) to
disambiguate it.

e.g:

typedef unsigned long a;
unsigned long b;

a * b;

vs:

unsigned long a;
unsigned long b;

a * b;

Both are legal and completely different interpretations of what "a *
b" means.

Glenn Andreas gandreas (AT) gandreas (DOT) com
<http://www.gandreas.com/wicked fun!
quadrium | build, mutate, evolve | images, textures, backgrounds, art

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Dec 30, 2005, at 9:38 AM, glenn andreas wrote:

typedef unsigned long a;
unsigned long b;

a * b;

Ah yes. Clearly I didn't think about typedefing something to a. I was
thinking of using it for multiplication and for dereferencing.
Actually, your code won't compile because you redeclare b:

$ gcc -Wall -x c -c - <<EF
typedef unsigned long a;
unsigned long b;
>
a * b;
EF
<stdin>:4: error: conflicting types for 'b'
<stdin>:2: error: previous declaration of 'b' was here
- Steve

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

30/dic/05, at 17:45, Greg Herlihy wrote:
12/30/05 5:45 AM, "Camillo Lugaresi" <camillo.lists (AT) gmail (DOT) com
wrote:
>
>30/dic/05, at 11:10, Andreas Mayer wrote:

Am 29.12.2005 um 21:39 Uhr schrieb Clark Cox:

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.

Alright, I'll give you that: it is ambiguous if you don't know
whether a is a type or a variable. But if you don't know what a is,
you cannot tell what the statement means, and if the compiler doesn't
know what a is, it cannot compile the statement. Thus, that syntactic
ambiguity changes "I can't tell what this code does/I can't compile
it" into "I can't tell what this code does/I can't compile it", ie it
has no bearing altogether. :-)

Camillo

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com