Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #138760 > unrolled thread

Shorthand ~> pointers

Back to article view | Back to comp.lang.c

Contents

  Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-19 21:31 -0500
    Re: Shorthand ~> pointers bitrex <user@example.net> - 2018-12-20 03:29 -0500
      Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 06:40 -0500
    Re: Shorthand ~> pointers Andrew Smallshaw <andrews@sdf.org> - 2018-12-20 10:23 +0000
      Re: Shorthand ~> pointers Bart <bc@freeuk.com> - 2018-12-20 11:15 +0000
        Re: Shorthand ~> pointers David Brown <david.brown@hesbynett.no> - 2018-12-20 13:46 +0100
          Re: Shorthand ~> pointers mark.bluemel@gmail.com - 2018-12-20 05:04 -0800
            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 05:11 -0800
      Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 03:25 -0800
      Re: Shorthand ~> pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-20 11:51 +0000
        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 06:54 -0500
          Re: Shorthand ~> pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-20 12:17 +0000
            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 07:21 -0500
              Re: Shorthand ~> pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-20 14:18 +0000
                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 09:26 -0500
            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 04:29 -0800
              Re: Shorthand ~> pointers mark.bluemel@gmail.com - 2018-12-20 04:46 -0800
              Re: Shorthand ~> pointers David Brown <david.brown@hesbynett.no> - 2018-12-20 15:00 +0100
        Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-20 14:26 +0000
          Re: Shorthand ~> pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-20 15:03 +0000
          Re: Shorthand ~> pointers James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-20 07:05 -0800
    Re: Shorthand ~> pointers "Fred.Zwarts" <F.Zwarts@KVI.nl> - 2018-12-20 11:16 +0100
      Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 07:16 -0500
    Re: Shorthand ~> pointers Bart <bc@freeuk.com> - 2018-12-20 12:39 +0000
      Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 08:20 -0500
        Re: Shorthand ~> pointers Bart <bc@freeuk.com> - 2018-12-20 14:02 +0000
          Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 09:15 -0500
            Re: Shorthand ~> pointers Bart <bc@freeuk.com> - 2018-12-20 17:48 +0000
      Re: Shorthand ~> pointers Juha Nieminen <nospam@thanks.invalid> - 2018-12-21 11:36 +0000
        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 08:05 -0500
          Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 14:56 +0000
            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 10:03 -0500
              Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 15:35 +0000
                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 10:41 -0500
                  Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-21 15:41 +0000
                  Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 17:04 +0000
                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 12:23 -0500
          Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 14:57 +0000
            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 10:20 -0500
              Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 15:37 +0000
                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 10:42 -0500
                  Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-21 15:42 +0000
                  Re: Shorthand ~> pointers David Brown <david.brown@hesbynett.no> - 2018-12-21 17:39 +0100
                  Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 17:05 +0000
                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 12:24 -0500
                      Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-21 23:49 -0800
                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-22 13:05 -0500
                          Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-22 16:38 -0800
          Re: Shorthand ~> pointers Juha Nieminen <nospam@thanks.invalid> - 2018-12-22 18:39 +0000
            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-22 13:42 -0500
              Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-22 16:23 -0800
                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-22 21:52 -0500
                  Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-22 20:26 -0800
                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-22 23:54 -0500
                      Re: Shorthand ~> pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-23 12:43 +0000
                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 08:34 -0500
                          Re: Shorthand ~> pointers James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-23 08:09 -0800
                            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 11:56 -0500
              Re: Shorthand ~> pointers Juha Nieminen <nospam@thanks.invalid> - 2018-12-23 08:24 +0000
                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 08:24 -0500
                  Re: Shorthand ~> pointers Bart <bc@freeuk.com> - 2018-12-23 15:28 +0000
                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 12:15 -0500
                      Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-23 17:24 +0000
                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 12:35 -0500
                          Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-23 17:39 +0000
                            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 14:07 -0500
                              Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-23 19:17 +0000
                                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 14:52 -0500
                                  Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-23 21:14 +0000
                                  Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-23 21:36 +0000
                                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 19:24 -0500
                                      Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-24 10:14 +0000
                                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 07:53 -0500
                                          Re: Shorthand ~> pointers gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-24 14:16 +0000
                                            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 10:17 -0500
                                          Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-24 15:36 +0000
                                            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 10:43 -0500
                                              Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-24 15:46 +0000
                                              Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-24 14:16 -0800
                                                Re: Shorthand ~> pointers Melzzzzz <Melzzzzz@zzzzz.com> - 2018-12-24 22:36 +0000
                                                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 18:35 -0500
                                                  Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-24 15:44 -0800
                                                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 18:55 -0500
                                                      Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-25 22:20 -0800
                                                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 05:32 -0500
                                                          You are so full of shit (Was: Shorthand ~> pointers) gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-26 14:10 +0000
                                                            Re: You are so full of .. (Was: Shorthand ~> pointers) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 09:47 -0500
                                                              Re: You are so full of shit (Was: Shorthand ~> pointers) gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-26 15:21 +0000
                      Re: Shorthand ~> pointers Ian Collins <ian-news@hotmail.com> - 2018-12-24 08:26 +1300
                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 15:02 -0500
                        Re: Shorthand ~> pointers Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-28 08:21 -0800
                      Re: Shorthand ~> pointers nobody@example.org (Scott) - 2018-12-25 03:56 +0000
                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 23:55 -0500
                          Re: Shorthand ~> pointers Richard Damon <Richard@Damon-Family.org> - 2018-12-25 10:14 -0500
                            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-25 10:36 -0500
                    Re: Shorthand ~> pointers Juha Nieminen <nospam@thanks.invalid> - 2018-12-24 14:22 +0000
                      Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-24 15:47 -0800
              Re: Shorthand ~> pointers Reinhardt Behm <rbehm@hushmail.com> - 2018-12-23 16:31 +0800
                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 08:28 -0500
    Re: Shorthand ~> pointers nobody@example.org (Scott) - 2018-12-21 01:14 +0000
      Re: Shorthand ~> pointers "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2018-12-21 03:23 +0100
        Re: Shorthand ~> pointers nobody@example.org (Scott) - 2018-12-21 09:45 +0000
          Re: Shorthand ~> pointers David Brown <david.brown@hesbynett.no> - 2018-12-21 12:05 +0100
          Re: Shorthand ~> pointers Vir Campestris <vir.campestris@invalid.invalid> - 2018-12-21 21:24 +0000
            Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 21:47 +0000
            Re: Shorthand ~> pointers David Brown <david.brown@hesbynett.no> - 2018-12-22 16:09 +0100
              Re: Shorthand ~> pointers Richard Damon <Richard@Damon-Family.org> - 2018-12-22 11:49 -0500
                Re: Shorthand ~> pointers Bart <bc@freeuk.com> - 2018-12-22 18:41 +0000
                  Re: Shorthand ~> pointers Anton Shepelev <anton.txt@gmail.com> - 2018-12-22 21:48 +0300
                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-22 14:00 -0500
                      Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-22 19:08 +0000
                        Re: Shorthand ~> pointers fir <profesor.fir@gmail.com> - 2018-12-22 16:42 -0800
                      Re: Shorthand ~> pointers Richard Damon <Richard@Damon-Family.org> - 2018-12-22 17:10 -0500
                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-22 17:42 -0500
                          Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-23 10:19 +0000
                            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 08:40 -0500
                Re: Shorthand ~> pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-25 21:00 +0000
      Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 07:57 -0500
    Re: Shorthand ~> pointers Bonita Montero <Bonita.Montero@gmail.com> - 2018-12-24 14:38 +0100
      Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 10:26 -0500
        Re: Shorthand ~> pointers Bonita Montero <Bonita.Montero@gmail.com> - 2018-12-28 13:35 +0100

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

#138760 — Shorthand ~> pointers

I've had the idea to introduce the ~> symbol for shorthand pointers.

These are pointers which access uniquely named child member objects
without having to traverse the child member hierarchy to get there:

     // Define a structure hierarchy example
     struct SGrandChild
     {
         s32  gcint;
     };

     struct SChild
     {
         SGrandChild  gc;
     };

     struct SExample
     {
         SChild* child;
     };

     // Use in code:
     SExample* e = generate_new_e();
     e->child->gc.gcInt = 5;     // Traditional access
     e~>gcInt           = 5;     // Shorthand access

It would only work for uniquely named members, but could also be
used from a relative point where, from that point down the rest
of the hierarchy it is then unique.

-- 
Rick C. Hodgin

[toc] | [next] | [standalone]

#138762

On 12/19/2018 09:31 PM, Rick C. Hodgin wrote:
> I've had the idea to introduce the ~> symbol for shorthand pointers.
> 
> These are pointers which access uniquely named child member objects
> without having to traverse the child member hierarchy to get there:
> 
>      // Define a structure hierarchy example
>      struct SGrandChild
>      {
>          s32  gcint;
>      };
> 
>      struct SChild
>      {
>          SGrandChild  gc;
>      };
> 
>      struct SExample
>      {
>          SChild* child;
>      };
> 
>      // Use in code:
>      SExample* e = generate_new_e();
>      e->child->gc.gcInt = 5;     // Traditional access
>      e~>gcInt           = 5;     // Shorthand access
> 
> It would only work for uniquely named members, but could also be
> used from a relative point where, from that point down the rest
> of the hierarchy it is then unique.
> 

Pretty hard for me to distinguish between the two at a glance on my 
laptop monitor at a normal working distance. I'm headed towards middle 
age, not 20/20 in both eyes anymore and I'm squinting over here...

[toc] | [prev] | [next] | [standalone]

#138766

On 12/20/18 3:29 AM, bitrex wrote:
> On 12/19/2018 09:31 PM, Rick C. Hodgin wrote:
>> I've had the idea to introduce the ~> symbol for shorthand pointers.
>>
>> These are pointers which access uniquely named child member objects
>> without having to traverse the child member hierarchy to get there:
>>
>>      // Use in code:
>>      SExample* e = generate_new_e();
>>      e->child->gc.gcInt = 5;     // Traditional access
>>      e~>gcInt           = 5;     // Shorthand access
>>
>> It would only work for uniquely named members, but could also be
>> used from a relative point where, from that point down the rest
>> of the hierarchy it is then unique.
> 
> Pretty hard for me to distinguish between the two at a glance on my 
> laptop monitor at a normal working distance. I'm headed towards middle 
> age, not 20/20 in both eyes anymore and I'm squinting over here...

Mine too.  Maybe e~~>gcInt would be better, that way it would be
more visual that it's a shorthand.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#138763

On 2018-12-20, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> I've had the idea to introduce the ~> symbol for shorthand pointers.

> It would only work for uniquely named members, but could also be
> used from a relative point where, from that point down the rest
> of the hierarchy it is then unique.

What an absolutely horrid idea.  So adding a new variable to a
structure causes well-written code to break when it was fine before?
I can see that going down like a lead balloon in large code bases.

I really don't see the point in these "let's improve C" discussions
in the first place, as if an idea is ever going to get traction
simply by being posted here, but at least any proposals could have
had more that 10 seconds consideration by the OP before posting.

-- 
Andrew Smallshaw
andrews@sdf.org

[toc] | [prev] | [next] | [standalone]

#138764

On 20/12/2018 10:23, Andrew Smallshaw wrote:
> On 2018-12-20, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>> I've had the idea to introduce the ~> symbol for shorthand pointers.
> 
>> It would only work for uniquely named members, but could also be
>> used from a relative point where, from that point down the rest
>> of the hierarchy it is then unique.
> 
> What an absolutely horrid idea.  So adding a new variable to a
> structure causes well-written code to break when it was fine before?
> I can see that going down like a lead balloon in large code bases.

That already happens with scopes:

int a;              // A1
     {
         {
             a;      // reference A1

This works fine. Until somebody introduces a new scope for 'a' between 
these two:

int a;              // A1
     {int a;         // A2
         {
             a;      // now references A2

The code lower down now breaks. In this case, the code is still legal 
and the change could go undetected unless your compiler can warn you 
about shadowing. Which then means you won't be able to use such 
shadowing even when you want to.


> I really don't see the point in these "let's improve C" discussions
> in the first place, as if an idea is ever going to get traction
> simply by being posted here, but at least any proposals could have
> had more that 10 seconds consideration by the OP before posting.

So how did the myriad gcc extensions ever get 'traction'?

(I normally make short work of Rick's proposals, but this one I'm stil 
thinking about.)

-- 
bart

[toc] | [prev] | [next] | [standalone]

#138775

On 20/12/18 12:15, Bart wrote:
> On 20/12/2018 10:23, Andrew Smallshaw wrote:
>> On 2018-12-20, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>>> I've had the idea to introduce the ~> symbol for shorthand pointers.
>>
>>> It would only work for uniquely named members, but could also be
>>> used from a relative point where, from that point down the rest
>>> of the hierarchy it is then unique.
>>
>> What an absolutely horrid idea.  So adding a new variable to a
>> structure causes well-written code to break when it was fine before?
>> I can see that going down like a lead balloon in large code bases.
> 
> That already happens with scopes:
> 
> int a;              // A1
>     {
>         {
>             a;      // reference A1
> 
> This works fine. Until somebody introduces a new scope for 'a' between
> these two:
> 
> int a;              // A1
>     {int a;         // A2
>         {
>             a;      // now references A2
> 
> The code lower down now breaks. In this case, the code is still legal
> and the change could go undetected unless your compiler can warn you
> about shadowing. Which then means you won't be able to use such
> shadowing even when you want to.
> 

The key difference is that this is a change at the point of use of the
code, while the problem with ~> pointers is that an unrelated addition
in a different part of the code (perhaps a header somewhere) can break
the existing code.

I am not sure that this is a killer problem for the feature, but it is
definitely a disadvantage.  Even though I don't see your particular
example as being a parallel case of code breakage, there are plenty of
other ways for adding new code in one place to affect independent code.

Combined with the rather difficult to read syntax, and the limited
usage, it is not a feature that would get my vote.  (Not that Rick would
count my vote anyway!).

C and C++ already have language features that are convenient for such
short-hand coding:

	SExample* e = generate_new_e();

	// Traditional
	e->child->gc.gcInt = 5;

	// C
	SGrandChild * gc = &e->child->gc;
	gc->gcInt = 5;

	// C++
	auto& gc = e->child->gc;
	gc.gcInt = 5;


If the C syntax is not nice enough, then the C++ version could be adopted.


> 
>> I really don't see the point in these "let's improve C" discussions
>> in the first place, as if an idea is ever going to get traction
>> simply by being posted here, but at least any proposals could have
>> had more that 10 seconds consideration by the OP before posting.
> 

I'm assuming Rick's post is about suggestions for his own language,
rather than C.

> So how did the myriad gcc extensions ever get 'traction'?
> 

It's worth noting that gcc add very little in the way of extensions
these days.  Most of their C extensions were from the the pre-C99 days,
with a number of their ideas making it into the C99 standards.

It takes a lot to get an extension into C.  Merely being an
"improvement" is not enough.

> (I normally make short work of Rick's proposals, but this one I'm stil
> thinking about.)
> 

[toc] | [prev] | [next] | [standalone]

#138777

On Thursday, 20 December 2018 12:46:47 UTC, David Brown  wrote:

> I'm assuming Rick's post is about suggestions for his own language,
> rather than C.

I'm not sure he'd agree. He seems to think that ideas he's cooked up
for his mythical language should somehow become adopted into C and C++.

I have a suspicion he's hoping this faith will allow C or C++ to become
CAlive without him having to do anything other than generate hot air.

[toc] | [prev] | [next] | [standalone]

#138778

On Thursday, December 20, 2018 at 8:04:49 AM UTC-5, mark.b...@gmail.com wrote:
> On Thursday, 20 December 2018 12:46:47 UTC, David Brown  wrote:
> 
> > I'm assuming Rick's post is about suggestions for his own language,
> > rather than C.
> 
> I'm not sure he'd agree. He seems to think that ideas he's cooked up
> for his mythical language should somehow become adopted into C and C++.
> 
> I have a suspicion he's hoping this faith will allow C or C++ to become
> CAlive without him having to do anything other than generate hot air.

You hatred of me is on display, Mark, as always. :-(

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#138765

On Thursday, December 20, 2018 at 5:23:56 AM UTC-5, Andrew Smallshaw wrote:
> On 2018-12-20, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > I've had the idea to introduce the ~> symbol for shorthand pointers.
> 
> > It would only work for uniquely named members, but could also be
> > used from a relative point where, from that point down the rest
> > of the hierarchy it is then unique.
> 
> What an absolutely horrid idea.  So adding a new variable to a
> structure causes well-written code to break when it was fine before?
> I can see that going down like a lead balloon in large code bases.

Don't use it on large code bases then.  Or add constraints that
only variables prefixed u_ can be used that way, to indicate it's
designed or intended to be a unique name.  Think, Andrew.

> I really don't see the point in these "let's improve C" discussions
> in the first place, as if an idea is ever going to get traction
> simply by being posted here, but at least any proposals could have
> had more that 10 seconds consideration by the OP before posting.

There are constraining factors you do not consider or place
emphasis on, such as the future of the GUI editor's abilities.
A good editor would see the refactoring and immediately catch
all issues, offering to correct the ~> uses for you, converting
them to full pointers, or suggesting a different name, etc.

In addition, such a feature would not be suitable to use in all
coding scenarios.  But in many, it would be a nice feature to
have.  I am a fast typist, but I often get tired of using deep
references.  I will often add a new local variable, cast a portion
of the deep reference to it, use that, and let the compiler optimize
it away.  I shouldn't have to do that when the name is unique.

-----
You accuse me of not thinking the matter through, Andrew.  Look
in the mirror, sir.  And don't be so extreme ("an absolutely
horrid idea," "more than 10 seconds," etc.).  Other people may
have thoughts you've never considered.  You may learn something
by taking an attitude of asking questions, rather than asserting
your "conclusions" so brashly.  Something to consider in dealing
with living, breathing, feeling human beings.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#138767

Andrew Smallshaw <andrews@sdf.org> writes:

> On 2018-12-20, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>> I've had the idea to introduce the ~> symbol for shorthand pointers.
>
>> It would only work for uniquely named members, but could also be
>> used from a relative point where, from that point down the rest
>> of the hierarchy it is then unique.
>
> What an absolutely horrid idea.  So adding a new variable to a
> structure causes well-written code to break when it was fine before?

Break, in the sense of issue a diagnostic, yes, but I don't think it can
break in the sense of suddenly and silently meaning something else
because of the uniqueness requirement.

But I notice that since it works with pointers, you don't even need to
change a struct or union for this to happen.  Just altering the
visibility of an aggregate's members can trigger the change from a
unique to an ambiguous access.

It seems to me to be a "fix" of the wrong kind.  It avoids typing rather
then letting you say something you could not say before.  I.e. it's just
presentation, and as such could be provided by your editor or choice:

  struct S *sp;
  sp.

(auto-correct suggests sp->)

  sp->x

(auto-correct suggests sp->sub.inner->x)

Finally, why only ~> for pointers?  What's the . equivalent?  If you
twisted by arm, I'd have only ~ and make that work for both pointer and
direct member access.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#138768

On 12/20/18 6:51 AM, Ben Bacarisse wrote:
> But I notice that since it works with pointers, you don't even need to
> change a struct or union for this to happen.  Just altering the
> visibility of an aggregate's members can trigger the change from a
> unique to an ambiguous access.

It would work where either -> or . would work.

In CAlive, I no longer have any distinction between . and ->.  They
are both synonymous, and refer to child members of the parent thing.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#138771

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>

> In CAlive, ...

and there it is!  The real reason for posting C++ in the first place.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#138772

On 12/20/18 7:17 AM, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> In CAlive, ...
> and there it is!  The real reason for posting C++ in the first place.

The reason I post it in C and C++ is because I think this is a good
extension, and something that could also be integrated into both C
and C++ to make developers' lives better.

It would work for any language that is a compiled language where such
references must be known and can be resolved at compile-time.  Any
language with those traits could also benefit from this shorthand.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#138783

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On 12/20/18 7:17 AM, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>> In CAlive, ...
>> and there it is!  The real reason for posting C++ in the first place.
>
> The reason I post it in C and C++...

I said "for posting C++".  The code you posted (apart from any proposed
extension) was not C.  It would be polite to post C in a C group, and
C++ in a C++ group.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#138784

On 12/20/2018 9:18 AM, Ben Bacarisse wrote:
> I said "for posting C++".  The code you posted (apart from any proposed
> extension) was not C.  It would be polite to post C in a C group, and
> C++ in a C++ group.

When someone posts that they do not understand the code as written,
I'll point them your way, Ben.  It will give you the opportunity to
help people in need.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#138773

On Thursday, December 20, 2018 at 7:17:14 AM UTC-5, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > In CAlive, ...
> and there it is!  The real reason for posting C++ in the first place.

CAlive is an aggregate for all of my ideas.  But I also post them here
because I would like to see C and C++ extended and improved by incorpor-
ating some of those ideas.  I want developers to have better productivity
in their development.  I want their lives to be enhanced.  I want new
developers coming into the language to not be put off so easily by the
historical legacy choices made over decades that are still maintained
solely because "it's always been done that way."  I want things that make
sense, and sometimes that means changing the way things are done, or aug-
menting the way things are done to accommodate a new model.

You have this personal hatred of me and CAlive and will not look past
that hatred to see that I come here with things to add value to C and
C++ where applicable.  You project your own internal negativity onto me,
and it's not justified.  You should look at the positive side of things,
and not the negative.  You should realize that just maybe I do want to
aid the C and C++ communities, and am not just "pimping my toolset."

I want people to use CAlive, but it's a different philosophy than C or
C++.  I doubt there will be many existing C or C++ users who come over
to use it.  I am expecting it will be a new class of developer who
wants to use something C/C++-like, but that's not exactly C or C++.

CAlive will also integrate a high level language into its code base
natively.  It will allow for much more flexible runtime code, with
the sacrifice of performance.

It's a different tool than C or C++, but the features I post here
are features that would work with C or C++, and I post them so that
they could possibly be integrated into those languages to help their
developers be more productive and have better coding experiences.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#138776

On Thursday, 20 December 2018 12:30:07 UTC, Rick C. Hodgin  wrote:
> On Thursday, December 20, 2018 at 7:17:14 AM UTC-5, Ben Bacarisse wrote:
> > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > > In CAlive, ...
> > and there it is!  The real reason for posting C++ in the first place.
> 
> CAlive is an aggregate for all of my ideas.  But I also post them here
> because I would like to see C and C++ extended and improved by incorpor-
> ating some of those ideas.  

Produce an actual implementation of CAlive and show the value of your
ideas, and people _may_ take some notice. It's possible that some of
the ideas would be regarded as sufficiently valuable to be considered
for inclusion in some future standard. Simply spraying half-formulated
concepts into newsgroups isn't likely to achieve much.

...

> You have this personal hatred of me and CAlive ...

And here we go. I doubt anyone here cares enough about you to hate you,
Rick.

[toc] | [prev] | [next] | [standalone]

#138780

On 20/12/18 13:29, Rick C. Hodgin wrote:
> On Thursday, December 20, 2018 at 7:17:14 AM UTC-5, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>> In CAlive, ...
>> and there it is!  The real reason for posting C++ in the first place.
> 
> CAlive is an aggregate for all of my ideas.  But I also post them here
> because I would like to see C and C++ extended and improved by incorpor-
> ating some of those ideas.

You know fine that this is never going to happen.  You know this without
any doubts, due to three things:

1. C++ does not lightly incorporate new ideas in the language (it is
much easier to add things to the libraries).  C is almost completely
stagnated as a language - as language stability is considered one of the
most important strengths of the language.  (The world needs some
programming languages that change, some that are stable - not one "do
everything" language.)

2. Virtually all your proposals aired here have been rejected on purely
technical grounds by experienced C and/or C++ programmers.  This is not
because of who is making the proposal, or because people prefer to do
things "the way they have always been done".  Every proposal has its
advantages and disadvantages - the advantages must significantly
outweigh the disadvantages in order for an idea to be worth taking
further.  A challenge you have here is that you believe more choice,
more ways to write the same code, is an advantage - most experienced
programmers understand that it is a /disadvantage/.

3. Both C and C++ have their procedures for getting changes into the
languages.  Those procedures do not start with a posting in these
newsgroups - no matter how much any of us liked a proposal, we cannot
add it to the languages.  This is, however, not a bad place to air ideas
before moving on to serious proposal documents posted to the appropriate
mailing lists.


>  I want developers to have better productivity
> in their development.  I want their lives to be enhanced.  I want new
> developers coming into the language to not be put off so easily by the
> historical legacy choices made over decades that are still maintained
> solely because "it's always been done that way."  I want things that make
> sense, and sometimes that means changing the way things are done, or aug-
> menting the way things are done to accommodate a new model.

I believe your motives are genuinely that you want to help people.
However, I don't believe you have enough understanding of how most
programmers think and work, in order to be able to help them.  This is
shown in the proposals you make.  Your ~> suggestion would not help
programmers - it does not solve any problem that they currently have,
but would add confusion and increase the risk of adding problems.  When
people /are/ writing code that involves a lot of subitems and
references, there are already code-based solutions in C and C++.  And
Ben's suggestion of enhancing existing IDE's is a good one - no one will
complain if you want to add helpful features to an IDE or editor.

But you are wrong to think that people's motivations for rejecting your
ideas is because of legacy and "it's always been done that way".
Certainly these concepts are important - compatibility with existing
code, tools, programmers, and knowledge is vital.  Most of us are
willing to consider new things in our programming, but we need to see
the technical advantages of it.

You have this unfortunate tendency to see a problem (or, more often, a
minor inconvenience), think of a possible solution, and then latch on to
that solution as though it were an absolute perfect answer.  This causes
you to get upset when people tell you that answer is /not/ perfect, or
suggest better solutions.  If you kept more of an open mind, I think you
would get better results.

> 
> You have this personal hatred of me and CAlive and will not look past
> that hatred to see that I come here with things to add value to C and
> C++ where applicable.  You project your own internal negativity onto me,
> and it's not justified.  You should look at the positive side of things,
> and not the negative.  You should realize that just maybe I do want to
> aid the C and C++ communities, and am not just "pimping my toolset."
> 

I don't believe that Ben or others here have any kind of personal hatred
of you or your language.  Many people don't like a lot of your posts -
they see them as wildly off-topic and disruptive to the group.  That
does not mean they hate you personally.  I don't think anyone has the
slightest interest in CAlive - no one believes it will ever be ready, or
ever be significant.  That does not mean they hate it - they just do not
care about it.

Even though no one cares about CAlive, or thinks it will succeed in any
way, no one wishes you ill with the project.  People (such as myself) am
happy to give advice or suggestions, despite knowing that the tool will
never be useful to me personally.  I do the same for Bart's languages
when the occasion arises, or Jacob's C compiler which I also know I
never will use.

You assume negative comments are a sign of hatred, but they are not - it
is simply a sign that people do not judge your proposals to be
technically sound.  It is perhaps easier for you to assume that people
have non-technical motives for rejecting your suggestions, but you would
learn far more if you tried to understand why people say certain ideas
are bad.

[toc] | [prev] | [next] | [standalone]

#138785

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Andrew Smallshaw <andrews@sdf.org> writes:
>
>> On 2018-12-20, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>>> I've had the idea to introduce the ~> symbol for shorthand pointers.
>>
>>> It would only work for uniquely named members, but could also be
>>> used from a relative point where, from that point down the rest
>>> of the hierarchy it is then unique.
>>
>> What an absolutely horrid idea.  So adding a new variable to a
>> structure causes well-written code to break when it was fine before?
>
>Break, in the sense of issue a diagnostic, yes, but I don't think it can
>break in the sense of suddenly and silently meaning something else
>because of the uniqueness requirement.

Changing the language definition in such a way as to cause
existing code to not compile is by definition "breaking" it.

[toc] | [prev] | [next] | [standalone]

#138786

scott@slp53.sl.home (Scott Lurndal) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>Andrew Smallshaw <andrews@sdf.org> writes:
>>
>>> On 2018-12-20, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>>>> I've had the idea to introduce the ~> symbol for shorthand pointers.
>>>
>>>> It would only work for uniquely named members, but could also be
>>>> used from a relative point where, from that point down the rest
>>>> of the hierarchy it is then unique.
>>>
>>> What an absolutely horrid idea.  So adding a new variable to a
>>> structure causes well-written code to break when it was fine before?
>>
>>Break, in the sense of issue a diagnostic, yes, but I don't think it can
>>break in the sense of suddenly and silently meaning something else
>>because of the uniqueness requirement.
>
> Changing the language definition in such a way as to cause
> existing code to not compile is by definition "breaking" it.

I don't follow.  Is there are any existing correct code with that symbol
in it?  (There may be some obscure macro trick, but I can't think of one
off hand.)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web