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

Groups > comp.lang.c > #89229

Re: efficient coding with literals and variables

Show all headers | View raw

On 2016-06-15, David Brown <david.brown@hesbynett.no> wrote:
> On 15/06/16 23:23, Ike Naar wrote:
>> On 2016-06-15, David Brown <david.brown@hesbynett.no> wrote:
>>> I think it is far nicer to put type qualifiers such as "const" or
>>> "volatile" at the start of the declaration - "const int", not "int
>>> const".  But that is personal opinion, and I'm not sure I can give a
>>> better justification than "I think it is nicer or clearer".  If others
>>> have better reasons for picking one way or the other, I'd be interested
>>> to hear.
>>
>> The terminology used in the C standard documents is "integer constant",
>> not "constant integer".
>>
>
> An "integer constant" is not the same thing as an object declared as a 
> "const int".  123 is an integer constant in C.  After "const int A = 
> 123;" and "int const B = 123;", neither A nor B are "integer constants".
>
> In all examples of the use of the "const" type qualifier in the C11 
> standard, type qualifiers come first, as in "const int".  There is a 
> inconsistency as to whether "const volatile int i" or "volatile const 
> int i" is the preferred ordering - both are used.  But type qualifiers 
> are always given before the type in the standard.

Imagine you want to declare pi as a nonmodifyable pointer-to-int:

  int * const pi;

The 'const' follows (i.e. appears after) the type (int *).
You cannot put the  'const' before the type, because

  const int * pi;

has a different meaning, namely, pi would be a modifyable pointer to an
'int const' or 'const int'.

Likewise, imagine you want to declare ppi as a nonmodifyable
pointer-to-pointer-to-int:

  int * * const pi;

Again, the 'const' appears after the type (int * *), and putting the 'const'
before the type (int * *) would give the declaration a different meaning.
In general, you can say that, as a rule, the 'const' appears after the type.
This holds in more complex examples as well:

  int * const * int const x;

means that x is a nonmodifyble pointer-to-nonmodifyable-pointer-to-int.

Only at the top level you have the freedom to put the 'const' before or
after the type:

  const int i;

or

  int const i;

So, the top level forms an exception to the rule that the 'const' comes
after the type.
I think that following the rule (always putting 'const' after the type)
makes more sense than following the exception (putting the 'const' after
the type except at the top level).

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

Thread

Re: efficient coding with literals and variables BartC <bc@freeuk.com> - 2016-06-14 20:53 +0100
  Re: efficient coding with literals and variables David Brown <david.brown@hesbynett.no> - 2016-06-15 08:59 +0200
    Re: efficient coding with literals and variables Keith Thompson <kst-u@mib.org> - 2016-06-15 10:01 -0700
      Re: efficient coding with literals and variables David Brown <david.brown@hesbynett.no> - 2016-06-15 19:47 +0200
        Re: efficient coding with literals and variables Keith Thompson <kst-u@mib.org> - 2016-06-15 11:47 -0700
    Re: efficient coding with literals and variables Ike Naar <ike@iceland.freeshell.org> - 2016-06-15 21:23 +0000
      Re: efficient coding with literals and variables David Brown <david.brown@hesbynett.no> - 2016-06-15 23:53 +0200
        Re: efficient coding with literals and variables Ike Naar <ike@iceland.freeshell.org> - 2016-06-15 22:41 +0000
          Re: efficient coding with literals and variables "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-15 18:54 -0400
            Re: efficient coding with literals and variables Ike Naar <ike@iceland.freeshell.org> - 2016-06-16 05:41 +0000
          Re: efficient coding with literals and variables David Brown <david.brown@hesbynett.no> - 2016-06-16 09:12 +0200
      Re: efficient coding with literals and variables Keith Thompson <kst-u@mib.org> - 2016-06-15 14:53 -0700

csiph-web