Re: Thoughts about the new standard

On Sep 5, 7:54 am, Francis Glassborow
<francis.glassbo...@xxxxxxxxxxxxxx> wrote:
Keith Thompson wrote:
Andrew Poelstra <apoels...@xxxxxxxxxxxxxx> writes:
On Thu, 2008-09-04 at 13:17 -0700, JSmith wrote:
And while you are at it, make the "." and "->" operators synonymous.
There is no reason any longer for the distinction.
Yes there is. (If you're trying to make a clever comment, don't
surround it with unintelligent ones.)
[...]

If you're going to assert that there's such a reason, you might want
to say what it is.  It's not an entirely silly idea.

I'm not saying that making "." and "->" synonymous would be a good
idea, but it actually wouldn't break any code or introduce any
ambiguity.  If the left hand side is a struct or union, either "."  or
"->" acts as the current "." does.  If the left hand side is a pointer
to a struct or union, either "." or "->" acts as as the current "->".
Otherwise, it's an error.  Existing code would continue to work; some
code that's currently illegal would start to work.

For example, ptr.member, (*ptr).member, and ptr->member would all be
equivalent.

I've worked in a language (Ada) that uses "." for the equivalent of
both of C's "." and "->" operators.  It's not a problem.

*If* this change were to be made, I'd want to make "." work as "->",
but not vice versa, and I'd deprecate "->", encouraging the use of "."
for both operations.

I wouldn't have minded if C had originally used "." for both, and not
added the "->" operator at all.  But dropping "->" altogether would
break most existing code (as JSmith implicitly acknowledges), and just
making them equivalent would cause too much confusion.  I don't think
this particular egg is worth unscrambling.

And there's something to be said for using different symbols for "."
and "->" anyway.

I once wrote an article on why it was fortunate that C actually had both
'.' and '->'. From the C perspective the '->' is just semantic sugar
because the compiler could always have worked it out. However the
beneficiary was not C but C++. The whole of C++ smart pointer technology
is based on the distinction between the two operators :-)

We can be certain that C++ will never get rid of operator -> so I think
that C should not spend time considering doing so. OTOH making . and ->
synonyms in C would seem to be reasonable and does not appear to present
any problems.

FWIW - I don't remember all the details, but in the original version
of C, the separation was necessary. Concepts of structs, fields
(members) and pointers were not as clean as they are now.
Unfortunately as the language evolved the concepts got cleaned up a
lot, but the syntax wasn't simplified as it could have been.

The benefit of the change is that in many situations, it would
unnecessary to specify whether an object is a struct, or a pointer to
a struct. It would be easy to change from local variables to malloc'd
memory, for example, with very little code change, etc.
.

Relevant Pages
Loading