home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 241,484 of 243,242   
   bart to David Brown   
   Re: New and improved version of cdecl   
   26 Oct 25 15:12:42   
   
   From: bc@freeuk.com   
      
   On 25/10/2025 16:18, David Brown wrote:   
   > On 25/10/2025 14:51, bart wrote:   
   >   
   >> This is another matter. The CDECL docs talk about C and C++ type   
   >> declarations being 'gibberish'.   
   >>   
   >> What do you feel about that, and the *need* for such a substantial   
   >> tool to help understand or write such declarations?   
   >>   
   >> I would rather have put some effort into fixing the syntax so that   
   >> such tools are not necessary!   
      
   > And I'd love to hear your plan for "fixing" the syntax of C - noting   
   > that changing the syntax of C means getting the C standards committee to   
   > accept your suggestions, getting at least all major C compilers to   
   > support them, and getting the millions of C programmers to use them.   
      
   I have posted such proposals in the past (probably before 2010).   
      
   I can't remember the exact details, but I think it is possible to   
   superimpose LTR type syntax on top of the existing language.   
      
   It's clear however that nobody would be interested in actually doing   
   that. I might have done it as a proof of concept, but with little   
   appetite (it only fixes a fraction of what I'd like to change).   
      
   If creating such a proposal today, I think it would require two new   
   keywords, for example:   
      
      ref       replaces '*' for pointer modifiers   
      func      marks functions otherwise there is too much ambiguity and   
                confusion   
      
   The above two could be type-spec starter symbols. In addition, a '['   
   could also start a type-spec (we don't want a third 'array' keyword).   
      
   So, in the new scheme, either of these symbols can start a new typespec:   
      
      ref   
      [   
      
   A type starting with T (built-in or user-defined type) is a regular   
   type-spec.   
      
   'func', is normally used inside the the type for function pointer: 'ref   
   func'. At the start, I suppose it could be used to declare regular   
   non-pointer functions.   
      
   Examples:   
      
      ref int p, q, r;           // int *p, *q, *r;   
      [N]int a, b, c;            // int a[N], b[N], c[N];   
      ref []int p;               // int (*p)[];  I think   
      [N]ref int q;              // int *q[N];   
      ref func(int, int)float F  // float (*F)(int,int);   
      ref ref[M][N]double x      // pointer to pointer to array ...   
      
   If you wanted to make it CDECL-clear, then make these tweaks:   
      
   - use 'pointer to' as an alias to 'ref'   
      
   - Require 'array' before [ in my examples   
      
   - Require 'returning' after ')'   
      
   (In this scheme, parentheses only occur around parameter lists.)   
      
   Old and new can be mixed, but they need to be distinct sequences:   
      
      ref func(int*, ref int)float F   
      
      int* G(ref func()void);   
      
   So, anywhere where a type could start in the current syntax, that can be   
   old or new.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca