request for member in something not a structure or union

[deepak]

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?

Thanks,
Deepak

[pete]

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.

--
pete

[Nick Keighley]

On 8 May, 10:12, deepak <deepakpj...@gm ail.comwrote:

I'm getting this compilation error while trying to access a member in
structure.
at what time we will get this error message?

thirteen o'clock

perhaps if you posted the code and the error message
we would have more chance of diagnosing your problem.

--
Nick Keighley

[Richard Heathfield]

deepak said:

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?

Often you'll see something of the kind when you have a pointer to a struct,
but you're pretending it's a struct.

time_t tt = time(NULL);
struct tm *ptr = localtime(&tt);

Minute = ptr.tm_min; /* error - ptr is not a struct, but a pointer */

Minute = ptr->tm_min; /* a fix */

Of course, this is really just a guess, and the exact fix may differ,
depending on your code (which I can't see).

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[viza]

Hi

On May 8, 10:12 am, deepak <deepakpj...@gm ail.comwrote:

>
I'm getting this compilation error while trying to access a member in
structure.

You have used the . operator where it isn't allowed.

Perhaps you need to replace it with -(if what is to the left of it
is a pointer to a struct) or perhaps it just needs to be removed. It
is hard to say without seeing the part of the code.

HTH

viza

[cr88192]

"pete" <pf*****@mindsp ring.comwrote in message
news:a-*************** *************** @earthlink.com. ..

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...).

--
pete

[Bart]

On May 9, 8:50*am, "cr88192" <cr88...@NOSPAM .hotmail.comwro te:

"pete" <pfil...@mindsp ring.comwrote in message

news:a-*************** *************** @earthlink.com. ..

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 = a.f; /* These look seductively similar */
y = b.f; /* until you write: */
a = 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 = p.bytes; /* Bytes in the pointer */
size = (*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

[Richard Tobin]

In article <04************ *************** *******@y21g200 0hsf.googlegrou ps.com>,
Bart <[e-mail] rote:

>Allowing (*p).f and p.f to be equivalent surely is a bad idea,
breaking the type system in an unnecessary way

It doesn't break the type system at all. It just makes . a (more)
polymorphic operator, or alternatively introduces another automatic
conversion.

-- Richard
--
:wq

[Keith Thompson]

ri*****@cogsci. ed.ac.uk (Richard Tobin) writes:

In article <04************ *************** *******@y21g200 0hsf.googlegrou ps.com>,
Bart <[e-mail] rote:

>>Allowing (*p).f and p.f to be equivalent surely is a bad idea,
breaking the type system in an unnecessary way

It doesn't break the type system at all. It just makes . a (more)
polymorphic operator, or alternatively introduces another automatic
conversion.

Right.

There are languages that allow the prefix to the "." "operator"
to be either a structure or a pointer to structure. Usually this
is done by making "." polymorphic, accepting either a structure or
a poitner as its prefix. (It's already polymorphic in the sense
that the prefix can be of any structure type.)

IMHO the "C-like" way to do this would have been to say that the
prefix to the "." "operator is *always* a pointer to struct, and
that an expression of struct type, if and only if it's followed by
".", decays to a pointer to the struct. This would be analagous
to the behavior of [], which acts as if it operated on an array
but really only operates on a pointer that results from a conversion.

Footnote 1: Replace "struct" with "struct or union" in the above.

Footnote 2: I put the word "operator" in quotation marks because "."
isn't really an operator; its right "operand" is not an expression.

Footnote 3: This scheme would work only when the struct-to-pointer
conversion is possible, i.e., when the struct expression is
actually the value of an object (otherwise there's nothing
to point to). This could cause problems for things like
function_return ing_struct().me mber. (I think we already have such
problems when indexing into an array that's a member of a struct
returned by a function; where's the array object that the converted
pointer points to?)

Footnote 4: Obviously Ritchie *didn't* decide to define "." this
way, either by the conversion method or by making it polymorphic.
I wouldn't look for any deeper meaning in this decision. Probably
he just thought of accessing a member of a structure directly and
accessing the same member via a pointer to the structure as two
distinct operations, calling for two distinct syntaxes (or perhaps
the decision was inherited from B or BCPL). It's a decision that
could reasonably have been made either way.

--
Keith Thompson (The_Other_Keit h) <ks***@mib.or g>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bart]

On May 9, 7:32*pm, Keith Thompson <[e-mail] rote:

rich...@cogsci. ed.ac.uk (Richard Tobin) writes:

In article <040c71a7-071d-4b9c-b7ad-06335aff0...@y2 1g2000hsf.googl egroups.com>,
Bart *<b...@freeuk.c omwrote:

>Allowing (*p).f and p.f to be equivalent surely is a bad idea,
breaking the type system in an unnecessary way

It doesn't break the type system at all. *It just makes . a (more)
polymorphic operator, or alternatively introduces another automatic
conversion.

Right.

There are languages that allow the prefix to the "." "operator"
to be either a structure or a pointer to structure. *Usually this
is done by making "." polymorphic, accepting either a structure or
a poitner as its prefix. *(It's already polymorphic in the sense
that the prefix can be of any structure type.)

IMHO the "C-like" way to do this would have been to say that the
prefix to the "." "operator is *always* a pointer to struct, and
that an expression of struct type, if and only if it's followed by
".", decays to a pointer to the struct. *This would be analagous
to the behavior of [], which acts as if it operated on an array
but really only operates on a pointer that results from a conversion.

So the left side side of "." is not just a struct type, but any chain
of pointers to a struct, multi-dereferenced as necessary to get at the
struct that "." needs? (This shows up a weakness in -which can only
deal with one dereference at a time.)

Workable, but just seems to lack a certain amount of rigour. And
throws away useful information from the source (now: s *must* be a
struct in s.f; "p" *must* be a pointer to a struct in p->f).

And it loses the possibility of being able to select an attribute of
the pointer using dot notation (although C doesn't have anything like
this, at present).
--
Bartc