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

Groups > comp.lang.c > #163256

Re: on the order of the const-keyword

Show all headers | View raw

On 10/29/2021 6:30 PM, David Brown wrote:
> On 29/10/2021 17:45, Bart wrote:
>> On 29/10/2021 15:31, David Brown wrote:
>>> On 29/10/2021 12:30, Bart wrote:
>>>> On 29/10/2021 09:03, David Brown wrote:
>>>>> On 28/10/2021 17:50, Meredith Montgomery wrote:
>>>>>> These seem legal declarations in C:
>>>>>>
>>>>>>      const char msg[9] = "warming:";
>>>>>>      char const msg[9] = "warming:";
>>>>>>
>>>>>> What's the difference between them?
>>>>
>>>>> The general rule is "const applies to the thing just to the left of it,
>>>>> unless there is nothing to the left of it and it then applies to the
>>>>> thing to the right of it".
>>>> The trouble is the 'thing' will be just a token, not a complete type, so
>>>> here:
>>>>
>>>>      long const long x;
>>>
>>> And how /exactly/ do you think this kind of thing is helping someone
>>> learning the language?  No one writes code like that, so it is simply
>>> not an issue.
>>
>> They presumably do do so (even if it's indirectly via macros), otherwise
>> most alternatives for writing the same type would long have been
>> deprecated from the language, with tighter rules as to the placement and
>> number of 'const' attributes.
>>
> 
> Why?  What would be the advantages of deprecating it?  It would make no
> difference to people writing C, but mean extra checks would have to be
> added to compliant compilers as well as changes to the grammar in the
> standards document.  And there may conceivably be some odd program with
> code like this - perhaps something with a history so far back that it
> used macros instead of typedefs and ended up with such results.  All in
> all, making such changes would be all effort and no gain.
> 
>>> If you are writing a compiler and want to be sure it is
>>> as standards-compliant as you can,
>>
>> Think about why that might be necessary.
>>
>>> you need to know about this sort of
>>> thing - no one else does.
>>>
>>> You seem to have an irresistible urge to spread your own confusions,
>>
>> I like to give the unadorned facts. Have a look at my first post again.
>> I say exactly what C allows you to write. Knowing that type declarations
>> can be a free-for-all is handy when encountering anything unusual.
>>
>>> and
>>> to highlight the worst possible complications of the language.  It is as
>>> unhelpful for a poster like this OP as those who quote the details of
>>> standards, or go off on tangents about how they want to add weird
>>> extensions to their own compilers.  How about just giving the guy some
>>> useful advice and general rules, rather than every obscure exception to
>>> those rules?
>>>
>>> This thread (not just your replies, but those from several others) is
>>> why comp.lang.c has a reputation for being useless to people looking for
>>> help with the C language.
>>
>> Your advice to read declarations from right to left I think was not
>> helpful either, being incorrect except in the simplest cases involving
>> only * modifiers and associated consts.
>>
> 
> In other words, it applies fine to the large majority of declarations.
> You can add "inside out" to it to cover more cases.
> 
> I understand that this is a simplification - but that's what people need
> at the start.
> 
> 
> 

Not sure about that, at least not this kind of simplification.
I think Bart made a good point, in noting that the right-to-left rule 
does not work well in some case, notably with pointers to arrays, which 
is something to be considered at any level of C knowledge.
So, as a first a simplification that can be wrong with some declaration 
that, although unfriendly to the novice, can actually be found in real 
code, runs the risk of being more confusing than helpful for the less 
experienced.
The second problem is that when such less experienced happens to read 
the standard's definition (which will happen at some point for any 
serious programmer), they will have the problem that the simplification 
is nowhere near the wording of the standard, so again risk of more 
confusion than help.

 From all the answers that have been given here, I think that one of 
James Kuypers' (the one citing the standard's distinction between 
'declaration-specifiers' and 'init-declarator-list') is the most useful, 
because /that/ is how declarations work in C, plain and simple, even if 
their description is not that simple.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-28 12:50 -0300
  Re: on the order of the const-keyword Bart <bc@freeuk.com> - 2021-10-28 17:25 +0100
    Re: on the order of the const-keyword "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-10-28 10:10 -0700
      Re: on the order of the const-keyword Guillaume <message@bottle.org> - 2021-10-28 20:40 +0200
      Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 00:07 -0300
        Re: on the order of the const-keyword James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-29 00:48 -0400
    Re: on the order of the const-keyword Thiago Adams <thiago.adams@gmail.com> - 2021-10-28 12:56 -0700
      Re: on the order of the const-keyword Thiago Adams <thiago.adams@gmail.com> - 2021-10-28 13:18 -0700
        Re: on the order of the const-keyword Bart <bc@freeuk.com> - 2021-10-28 21:35 +0100
          Re: on the order of the const-keyword Thiago Adams <thiago.adams@gmail.com> - 2021-10-28 13:57 -0700
            Re: on the order of the const-keyword Thiago Adams <thiago.adams@gmail.com> - 2021-10-28 14:07 -0700
              Re: on the order of the const-keyword Bart <bc@freeuk.com> - 2021-10-28 22:54 +0100
              Re: on the order of the const-keyword Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-28 15:37 -0700
                Re: on the order of the const-keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-29 00:02 +0100
        Re: on the order of the const-keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-28 22:10 +0100
        Re: on the order of the const-keyword Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-28 15:13 -0700
        Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 00:40 -0300
    Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-28 23:48 -0300
  Re: on the order of the const-keyword James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-28 13:04 -0400
    Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 00:34 -0300
  Re: on the order of the const-keyword David Brown <david.brown@hesbynett.no> - 2021-10-29 10:03 +0200
    Re: on the order of the const-keyword Bart <bc@freeuk.com> - 2021-10-29 11:30 +0100
      Re: on the order of the const-keyword David Brown <david.brown@hesbynett.no> - 2021-10-29 16:31 +0200
        Re: on the order of the const-keyword Bart <bc@freeuk.com> - 2021-10-29 16:45 +0100
          Re: on the order of the const-keyword David Brown <david.brown@hesbynett.no> - 2021-10-29 18:30 +0200
            Re: on the order of the const-keyword Manfred <noname@add.invalid> - 2021-10-30 00:32 +0200
              Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 20:03 -0300
              Re: on the order of the const-keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-30 01:10 +0100
            Re: on the order of the const-keyword Bart <bc@freeuk.com> - 2021-10-29 23:51 +0100
    Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 12:22 -0300
      Re: on the order of the const-keyword David Brown <david.brown@hesbynett.no> - 2021-10-29 18:34 +0200
        Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 17:04 -0300

csiph-web