On May 9, 8:50=A0am, "cr88192" <cr88...@[EMAIL PROTECTED]
> wrote:
> "pete" <pfil...@[EMAIL PROTECTED]
> wrote in message
>
> news:a--dnSl1Xs7fW7_VnZ2dnUVZ_scAAAAA@[EMAIL PROTECTED]
>
> > deepak wrote:
> >> Hi Experts,
>
> >> I'm getting this compilation error while trying to access a member in
> >> structure.
> >> at what time we will get this error message?
>
> > When you use a dot operator (.)
> > when you should be using an arrow operator (->)
> > instead.
>
> now, a mystery, maybe somone will know:
> why exactly is it that . and -> were originally made to be separate
> operators anyways?...
>
> what exactly is the cost of, say, a compiler implementor being lazy and
> treating both cases as equivalent? (well, apart from maybe the risk of a
> user writing code which will promptly break if used on a more
> standards-conformant compiler...).
I understand . and -> to do different things:
s.f accesses field f of struct s
p->f accesses field f of a struct pointed to by p. I think
equivalent to (*p).f.
Allowing (*p).f and p.f to be equivalent surely is a bad idea,
breaking the type system in an unnecessary way, and rendering code
less readable:
struct r *a, b; /* Hidden away somewhere */
x =3D a.f; /* These look seductively similar */
y =3D b.f; /* until you write: */
a =3D b; /* Error */
C doesn't allow dotted selections on a value other than for field
access, otherwise it would be clear that, when p is a pointer,
sometimes you want to access a property of the pointer, and not the
thing it points to; inventing a property .bytes:
size =3D p.bytes; /* Bytes in the pointer */
size =3D (*p).bytes; /* Bytes in the thing it points to */
This doesn't work well with -> however: p->bytes. In fact -> is an
ugly construct only tolerated because (*p). is worse! Pascal syntax
for this stuff is cleaner:
p {a pointer value}
p^ {the record p points to}
p^.f {field of the record p points to}
p.f {error}
p.bytes {bytes in the pointer}
p^.bytes {bytes in the record}
--
Bartc
|
