Re: why use -> (not .) with pointers?

Richard Tobin wrote: 
So would you favour having different operators for integer and
floating-point addition?


Actually, that could be debatable.
When I see so many programmers mixing integers and fp numbers in
expressions without quite knowing what they are doing (and sometimes
wondering why the heck they don't get the results they are expecting),
I'm thinking: why not different operators. At least, that would force
you to have a clear understanding of both what you want and what is
going to happen, without having to read dozens of pages of the standard
and praying that your compiler sticks to it...

 Is it a disaster that if foo is a function
pointer you can say foo(1) instead of (*foo)(1)?


You're making a point, but I don't see this as harmful as the "./->"
case. When you see foo(1), you immediately know while reading it
that foo is either a pointer to a function, or a function symbol.
There is no "function type" that you can use in C as a variable;
there are only function pointers. Functions themselves cannot be
C variables, just as you can't "instantiate" a void variable;
only pointers to void are legal.

Since I almost never use a pointer to function without checking
first if it's NULL or not, it's immediately clear what 'foo' is,
without having to browse through hundreds of lines of code...

Why is determining the action "guessing" in this case but not the
others?


In the case of using '.' instead of '->' for pointers to structures,
you loose sight of what the variable type is: is it a pointer to
a structure or a structure? That hinders readability in my opinion.

Then again, I use the Hungarian notation most of the time, so that
would not be that big a deal for me: but I know a lot of programmers
that don't. Then the source code would become hell to read.

High-level languages are meant to be highly readable by you and
by others. Readability should be a big part of programming.
Apparent syntax simplifications do more harm than good in my opinion.
In that particular case, that would tend to make the newer programmers
confuse pointer-types with non-pointer-types. And that would tend
to just plain confuse the more seasoned ones...
.

Relevant Pages

  • Re: A C++ Whishlist
    ... >> programmers. ... I am not advocating a general rule that all non-virtual members accept ... > move the pointer around... ...
    (comp.lang.cpp)
  • Re: malloc syntax
    ... > programmers. ... > misunderstanding of the whole point of having a pointer to void type. ... Now in C of course, other operations are defined, such as implicit casts ...
    (comp.lang.c)
  • Re: Moving to C#
    ... some point, to keep track of a pointer then I'm thinking that it would be a very elite profession indeed and the trades industry wouldn't be suffering for iron workers, carpenters, plumbers and the like as it is. ... Most upper level management doesn't know jack about programming anyway, so they can't filter out poor programmers. ... The pointer not being freed can easily be profiled and deteremined because you should have NO pointers left over when you are done. ... If you are writing flight control software and NOT running code through the proper quality control, then it doesn't matter what language/framework/OS you are using - someone is going to have a very bad day! ...
    (borland.public.delphi.non-technical)
  • Re: Help - string length question in C
    ... > confusion is when a pointer is passed as a function parameter. ... particularly if the function parameter is declared using ... Experienced C programmers are well aware of this problem ...
    (comp.programming)
  • Re: Null pointers
    ... > My strong opinion is that, on this particular point, I'm right and ... > trap on attempts to dereference a null pointer. ... should a zero location null pointer be, ... > The C language actually requires an attempt to read or write to the ...
    (comp.lang.c)