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

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

on the order of the const-keyword

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

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#163226

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?
> 

Nothing.

Both mean that the array is made of "const char" elements - after you
have initialised the array, you can't change them.


A lot of people prefer the "const on the left" arrangement :

	const int x = 123;

It is very common to use this ordering - many programmers feel it is
more natural.


Some people prefer the "const on the right" arrangement (known as "east
const") :

	int const x = 123;

The argument there is that it is more consistent, especially in C++
(which has a few other possible uses of the word "const").



It is fair to say that the "east const" is more consistent when you have
more complicated declarations involving pointers with "const" applied to
different parts.  That does not mean that it is the clearest way to
write simple declarations, which are far more common.  So opinions
differ here.  You have to learn to understand the placement options as
you will see both when you read other people's code, and you have to
decide for yourself which you choose in your own code (unless you are
using a set of style guidelines that forces the decision on you).


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".  This fits well with the usual best tactic
for parsing most types - start from the right and work left.

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

#163229

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;

const applies neither to the first long nor the second, but to the 
complete type 'long long'. It's in the middle!

This is interesting as there are now three placements for 'const' rather 
than two. As well, of course, as any combination of all three:

    const int const unsigned const long const long const x;

All you can really advise is:

  * Identify the base type: the part before you get to the bit that 
marks the end of the base type, any of: variable/function/param name, (, 
  *, comma or ).

* If there is at least one const anywhere in that base type, then the 
whole base type is const.

 > This fits well with the usual best tactic
 > for parsing most types - start from the right and work left.

Yeah, so the type of 'c' here:

   int *a(void), *b[77], (*c)[5][10];

according to your method, is:

   array 10 of array 5 of pointer to (skipping a/b modifiers) int

The actual type is:

   pointer to array 5 of array 10 of int

Which is pretty much the opposite!

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

#163238

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.  If you are writing a compiler and want to be sure it is
as standards-compliant as you can, 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, 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.

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

#163244

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.

> 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.

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

#163245

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.

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

#163256

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.

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

#163258

Manfred <noname@add.invalid> writes:

> 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?

[...]

>>> 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.

It's really education we're talking about here.  Education is not quite
a scientific area; it's a philosophical one in the Bertrand Russell
sense of philosophy: if there were a clear answer to how to do it, it'd
be called science.  (See the first few pages of his ``A History of
Western Philosophy''.)

Because we don't know what is the right approach, we should more or less
provide them all.  More or less, of course.  And it is a very good idea
to present to students your opinion such as --- this is the right
approach **for sure** and there are other silly approaches too because
some people are too blind to see.

Consider this very thread.  A novice is looking at this and getting a
clear picture of the cloud that education in this area is.  (It's like
that in every area, actually.)  That's (evidently) a fact --- locally at
the very least.

One of the great friends of students is moving-ahead.  You realize
you've got an education when you look back, but to look back you must
move ahead.  So it is a good idea to come up with a modus operandi, even
if it's broken.  This is an important piece of the scientific method:
come up with a hypothesis and stress it until it breaks.

But, of course, if the student can't understand the hypothesis (because
it's too complex), then it might be a useless one.  There are multiple
levels of students --- there are researcher-students, students-students,
children-students.

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

#163259

Manfred <noname@add.invalid> writes:

> On 10/29/2021 6:30 PM, David Brown wrote:

>> 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.

The simple rule goes wrong for even simpler cases:

  int a[3][5];
  double f(double);

If you start at the name, the rule is to read to the right, and only
switch to reading left when you have to (which needs to be tied down).
This is because []s and ()s bind more tightly than *:

   int *a[10];
        >>>>>     "a is an array of 10"
   <<<<<          "pointers to int"

The reference to "inside out" means you need to finish off parentheses
before moving outside:

   int (*a)[10];
        <<          "a is a pointer to"
          >>>>>     "an array of 10"
    <<<<            "int"

Mind you, I don't usually do it this way.  I read the declarator (the
part that decorates the name) like I do expressions.  I don't vocalise

   *a[10]

in an expression like 

   *a[10] = 42

I know the precedence and associativity so I know this is indexing 'a' and
dereferencing the result, as opposed to

  (*a)[10] = 42

which dereferences a pointer and indexes the result.

-- 
Ben.

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

#163257

On 29/10/2021 17:30, David Brown wrote:
> On 29/10/2021 17:45, Bart wrote:

>> 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.

It actually makes compilation simpler, if you knew for example that the 
pattern was always:

    [const] [unsigned/signed] [long [long] / short] int

As to the advantages of deprecating it, the behaviour of most compilers, 
using default options, is to be incredibly lax about things that I 
consider irresponsibly dangerous.

So people continue their bad coding habits, because they are not like 
you in devising a strict dialect of the language, and implementing that 
dialect via sets of compiler options.

> And there may conceivably be some odd program with
> code like this

Or maybe you write the code by accident. Then you are either puzzled why 
it doesn't work, or don't notice, until it puzzles someone else.

  - 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.

It can be easier than you think. My own compiler disallows many things I 
consider unacceptable. But for the purposes of compiling legacy code, I 
require one special option to be specified.

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

#163242

David Brown <david.brown@hesbynett.no> writes:

> 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?
>> 
>
> Nothing.
>
> Both mean that the array is made of "const char" elements - after you
> have initialised the array, you can't change them.
>
>
> A lot of people prefer the "const on the left" arrangement :
>
> 	const int x = 123;
>
> It is very common to use this ordering - many programmers feel it is
> more natural.
>
>
> Some people prefer the "const on the right" arrangement (known as "east
> const") :
>
> 	int const x = 123;
>
> The argument there is that it is more consistent, especially in C++
> (which has a few other possible uses of the word "const").
>
>
>
> It is fair to say that the "east const" is more consistent when you have
> more complicated declarations involving pointers with "const" applied to
> different parts.  That does not mean that it is the clearest way to
> write simple declarations, which are far more common.  So opinions
> differ here.  You have to learn to understand the placement options as
> you will see both when you read other people's code, and you have to
> decide for yourself which you choose in your own code (unless you are
> using a set of style guidelines that forces the decision on you).
>
>
> 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".  This fits well with the usual best tactic
> for parsing most types - start from the right and work left.

Pretty useful guidance.  Thank you.  I will try that from now on.

You spoke of consistency above, but your paragraphs sometimes skip one
line, sometimes two lines, sometimes three lines.  What's up with that?

                                  :-)

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

#163246

On 29/10/2021 17:22, Meredith Montgomery wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> 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?
>>>
>>
>> Nothing.
>>
>> Both mean that the array is made of "const char" elements - after you
>> have initialised the array, you can't change them.
>>
>>
>> A lot of people prefer the "const on the left" arrangement :
>>
>> 	const int x = 123;
>>
>> It is very common to use this ordering - many programmers feel it is
>> more natural.
>>
>>
>> Some people prefer the "const on the right" arrangement (known as "east
>> const") :
>>
>> 	int const x = 123;
>>
>> The argument there is that it is more consistent, especially in C++
>> (which has a few other possible uses of the word "const").
>>
>>
>>
>> It is fair to say that the "east const" is more consistent when you have
>> more complicated declarations involving pointers with "const" applied to
>> different parts.  That does not mean that it is the clearest way to
>> write simple declarations, which are far more common.  So opinions
>> differ here.  You have to learn to understand the placement options as
>> you will see both when you read other people's code, and you have to
>> decide for yourself which you choose in your own code (unless you are
>> using a set of style guidelines that forces the decision on you).
>>
>>
>> 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".  This fits well with the usual best tactic
>> for parsing most types - start from the right and work left.
> 
> Pretty useful guidance.  Thank you.  I will try that from now on.
> 
> You spoke of consistency above, but your paragraphs sometimes skip one
> line, sometimes two lines, sometimes three lines.  What's up with that?
> 
>                                   :-)
> 

It's to give you time to think and absorb the information underway!
Also, it gives a visual separation that is greater than I used for the
code snippets - so the spacing is intentional.  (I know your question
wasn't very serious.)

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

#163252

David Brown <david.brown@hesbynett.no> writes:

> On 29/10/2021 17:22, Meredith Montgomery wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> 
>>> 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?
>>>>
>>>
>>> Nothing.
>>>
>>> Both mean that the array is made of "const char" elements - after you
>>> have initialised the array, you can't change them.
>>>
>>>
>>> A lot of people prefer the "const on the left" arrangement :
>>>
>>> 	const int x = 123;
>>>
>>> It is very common to use this ordering - many programmers feel it is
>>> more natural.
>>>
>>>
>>> Some people prefer the "const on the right" arrangement (known as "east
>>> const") :
>>>
>>> 	int const x = 123;
>>>
>>> The argument there is that it is more consistent, especially in C++
>>> (which has a few other possible uses of the word "const").
>>>
>>>
>>>
>>> It is fair to say that the "east const" is more consistent when you have
>>> more complicated declarations involving pointers with "const" applied to
>>> different parts.  That does not mean that it is the clearest way to
>>> write simple declarations, which are far more common.  So opinions
>>> differ here.  You have to learn to understand the placement options as
>>> you will see both when you read other people's code, and you have to
>>> decide for yourself which you choose in your own code (unless you are
>>> using a set of style guidelines that forces the decision on you).
>>>
>>>
>>> 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".  This fits well with the usual best tactic
>>> for parsing most types - start from the right and work left.
>> 
>> Pretty useful guidance.  Thank you.  I will try that from now on.
>> 
>> You spoke of consistency above, but your paragraphs sometimes skip one
>> line, sometimes two lines, sometimes three lines.  What's up with that?
>> 
>>                                   :-)
>> 
>
> It's to give you time to think and absorb the information underway!
> Also, it gives a visual separation that is greater than I used for the
> code snippets - so the spacing is intentional.  (I know your question
> wasn't very serious.)

It wasn't, yes, but that's because I thought there wasn't a special
reason.  Now that I know there is, I'm impressed and a bit surprised, so
now I'm glad I asked.

Here's what I probably would have done.

--8<---------------cut here---------------start------------->8---
(*) Introduction

Lorem ipsum dolor... 

(*) Now to your question specifically

Lorem...

(*) Taking stock or something

Lorem ipsum...
--8<---------------cut here---------------end--------------->8---

If you think about it, your style up there is a a bit too implicit.  If
I'd like to give the reader some time to ponder, I would say that
explicitly --- dear reader, please take some time to ponder.  

Having said that, I never cast the return of malloc. :-)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web