Re: "<>", a relational operator?

On Tue, 10 May 2005 17:15:51 +0200, Richard Edgar <rge21@xxxxxxxxxxx>
wrote:

> Paul Van Delst wrote:
>
> >> I keep wondering when programming in C, why there is a "." and a "->"
> >> separator?
> >> I know: the compiler will complain if I use the wrong one, but that is
> >> exactly my point: the compiler ***knows*** which one I should have used, so why are
> >> so why are there two?
> >
> >
> > Huh. My lone C book tells me that
> > pointer_to_structure -> member_name
> > is equivalent to
> > (*pointer_to_structure).member_name
> > Weird.
>
> Indeed. I suspect that part of the answer lies in the fact that C's
> pointers are just integers, so some extra visual 'aid' might be useful
> to remind people what's a pointer, and what's a 'real' structure.
>
No they aren't. They are just addresses -- or at least aren't required
to be more than just an address; an implementation is _permitted_ to
keep additional bounds/etc. information but not required, there isn't
much support for optimizing it, and users don't expect or demand it,
so sensible implementors don't. But they are distinct from integers,
and in particular have strides -- fixed ones, except for C99 VLA
types. And in Standard (portable) C there are significant restrictions
on comparing and computing them. OTOH in BCPL and B pointers were
truly just (computable) integers, and memory uniformly word-oriented.

I believe it had more to do with C's philosophy of "you only get what
you see". Remember C was designed as a System Implementation Language
(for Unix), not a general application language, where the philosophy
is more often "that's what I want; do whatever it takes". You only get
a dereference when you ask for it -- and with pass-by-value arguments,
you only get aliasing and/or change-to-outside when you ask. C also
has no whole array operations; if you want something done to all (or
many) elements of an array, you must do it yourself -- although for
array of char (character strings) (and now wide-char) in particular
there are standard library routines -- not core syntax -- for some
common operations. Originally it didn't have struct assignment (or
pass or return) although those were added. It is probably some kind of
tribute to the human spirit that C has been used so extensively for
applications without more failures than have in fact occurred.

> Of course, I know well the feeling (going back to my BASIC days) of
> "Well, if you _know_ that there's a missing ")" why don't you just put
> it in yourself?"
>
> :-)
>
As glen says there was more effort put into this in batch days. My
favorite was one time I fed an empty deck to PL/C -- or rather I
submitted an empty deck to someone who gave it to someone else who
submitted the job, after which someone else burst the printouts and
gave them to someone else who filed them where I could get them -- and
it constructed a complete and nearly "valid" (though useless) program
effectively out of thin air. DWIM indeed!

> > <sarcasm>Maybe the -> was introduced to save all those darn,
> > useless keystrokes? Sort of like how
> > ++i
> > is the same as
> > i = i + 1
> > Or is it
> > i++?
> > </sarcasm>
>
The side effect is the same as either; the result of i = i+1 is the
value after modification which is the same as ++i but not i++. This
(obviously) matters only if the result is used. (In C++ if i is of a
class type there is the further difference that prefix conventionally
returns a reference that doesn't require copying and allows further
operations, while postfix returns a value that does and may not.)

> ISTR being told by someone who'd written a C compiler that the standard
> was rather vague on the meaning of
>
> i = i++ * ++i;
>
> which has rather different results depending on when i gets incremented...
>
As James says, the Standard isn't vague at all -- this is specifically
undefined. (Unlike some other cases that are undefined by omission,
and thus sometimes harder to identify.) It isn't even required to
produce _any_ result. Like some other cases of Undefined Behavior this
was intended to allow for different implementations that (AFAIK all)
do produce _some_ result, but for more or less good reasons different
and possibly even invalid ones. Plus the principle that if you want a
given order, you should (and easily can) code it explicitly.

- David.Thompson1 at worldnet.att.net
.

Relevant Pages

  • Re: memory management
    ... I don't have a copy of the standard available to ... Accessing out of declared bounds of an array is ... floating-point and very occasionally pointers. ... This is called the 'struct hack', see 2.6 in the C FAQ at the usual ...
    (comp.lang.ada)
  • Re: Realloc and pointer arithmetics
    ... through an AVL tree that managed void* data. ... the C standard does not. ... My frist thought was actually to store into the tree pointers to array ...
    (comp.lang.c)
  • Re: execve and char const *
    ... a limitation of the ISO C standard, ... these functions do not modify either the array of pointers ...
    (comp.unix.programmer)
  • Re: contiguity of arrays
    ... >equality operators on pointers. ... >int main ... One could find wording in the standard supporting both views. ... so they do compose an array of 3 int. ...
    (comp.lang.c)
  • Re: Differance between Array and Pointers
    ... Well, except that arrays tend to be much larger than pointers, and the ... An array is a contiguous region of memory containing N elements of M ... indexing vs. a loop). ...
    (comp.arch.embedded)