This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C2X Proposal, merge '.' and '->' C operators


On Sat, Dec 21, 2019 at 11:11 AM Allan Sandfeld Jensen <linux@carewolf.com>
wrote:

> On Monday, 16 December 2019 14:51:38 CET J Decker wrote:
> > Here's the gist of what I would propose...
> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> >
> > In C, there are two operators . and -> used to access members of struct
> and
> > union types. These operators are specified such that they are always
> paired
> > in usage; for example, if the left hand expression is a pointer to a
> struct
> > or union, then the operator -> MUST be used. There is no occasion where .
> > and -> may be interchanged, given the existing specification.
> >
> > It should be very evident to the compiler whether the token before '.' or
> > '->' is a pointer to a struct/union or a struct/union, and just build the
> > appropriate output.
> >
> > The source modification for the compiler is very slight, even depending
> on
> > flag_c2x(that's not it's name).  It ends up changing a lot of existing
> > lines, just to change their indentation; but that shouldn't really count
> > against 'changed lines'.
> >
> > I'm sure, after 4 score and some years ('78-19) that it must surely have
> > come up before?  Anyone able to point me to those existing proposals?
> >
> What if you operate on a pointer to a pointer to a struct? Should the same
> operator just magically dereference everything until it is a struct?
>
> how does pointer to a pointer to a struct work now?  Does it somehow
involve ppStruct->->a ?



> I disagree with this proposal because separate a thing and a pointer to a
> thing is fundamental to C/C++, and providing short-cuts that confuse the
> two
> is doing a disservice to anyone that needs to learn it.
>
> It's not to the assembly though.

To me, it's not a matter of it being a shorthand, but to make JS code more
portable back to C (and C++ compiled C).


> Besides isn't this the wrong mailing list for this?
>
> Probably?  I thought it a better starting point than the bug list?  Where
would you suggest I go?  It doesn't look like C standards, unlike
es-discuss for ecma script, I couldn't find a open forum to discuss such
things... or even a github group like... https://github.com/tc39/proposals

J


> 'Allan
>
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]