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


Groups > comp.lang.c > #163208

Re: on the order of the const-keyword

From Bart <bc@freeuk.com>
Newsgroups comp.lang.c
Subject Re: on the order of the const-keyword
Date 2021-10-28 22:54 +0100
Organization A noiseless patient Spider
Message-ID <slf67a$pu0$1@dont-email.me> (permalink)
References (2 earlier) <a25df1f0-687b-4489-8f2f-6daa35593040n@googlegroups.com> <994066a9-5940-4d1c-8df4-517905174930n@googlegroups.com> <slf1ic$qcv$1@dont-email.me> <7697a67c-fc7e-4b7c-b53f-38076b50cde2n@googlegroups.com> <aadf2b60-6c41-434a-8c19-8fc2a60bff15n@googlegroups.com>

Show all headers | View raw


On 28/10/2021 22:07, Thiago Adams wrote:
> On Thursday, October 28, 2021 at 5:57:38 PM UTC-3, Thiago Adams wrote:

>> in this C99 sample c HAS storage. it exists.
>> Now lets consider we have this "constant".
>>
>> struct X { int i; };
>> void F(struct X* x) {}
>> constant struct X c = { . i = 1 }; //no storage
>>
>> int main() {
>> F(& (struct X) {.i = 1});
>> F(&c); //what happens here?
>> }
>>
>> When we call F(&c) some variable should be instantiated.?
>>
>> At the end it could work as enumerators work today
>>
>> enum { A = 1 };
>> void F(int* i) {}
>> void F2(int i) {}
>> int main() {
>> F(&A); //error: lvalue required as unary '&' operand
>> F2(A); //OK
>> }
>>
>> sometimes a local variable would be created, except for int double etc..
> 
> The reason why this features does not exist today may be because for complex
> types we can create a const variable and reuse it.
> and use defines for int double etc.

Below is a summary, in the first 3 Y/N columns, of the three different 
ways C has to create named constants.

It's set up so that a Y response is the more desirable.

Here, enums tick nearly all the boxes, so that it is odd that #define 
and const T seem more popular. But then, 'enum' was really intended for 
other purposes (defining related names with incrementing values), so it 
might itself seem odd to use it arbitrarily.

My 'constant' feature ticks all the boxes plus it doesn't look weird to use.


   Characteristic              #define  const T  enum  'constant'

   Normal scope?                N        Y        Y      Y
   Any numeric type?            Y        Y        N      Y
   Avoids storage (5)           Y        N (3)    Y      Y
   Use in non-VLA  bounds       Y        N        Y      Y
   Won't create a VLA?          Y        N        Y      Y
   Use in static array bounds   Y        N        Y      Y
   Use in switch-case labels    Y        N        Y      Y
   Evaluate once (1)            N        Y        Y      Y
   Prohibit & address-of        Y        N        Y      Y
   Prohibit Pass by ref         Y        N        Y      Y
   Impossible to modify?        Y        N (2)    Y      Y
   Reduce const exprs?          Y        ? (3)    Y      Y
   Unambiguous meaning (4)      N        Y        Y      Y

   (1) With #define A ((B+C)*D) etc, at each place A is used, it will 
expand that expression, and need to parse it and reduce, possibly 100s 
of times

   (2) It's possible to modify via casts

   (3) Depends on compiler's optimisation abilities

   (4) With #define, using the same ((B+C)*D) example each time A is 
expanded, it will use whatever B, C, D names are in scope at that point, 
potentially generating a different value of A each time.

   (5) Apart from immediate operands, some hardware may require storage 
for certain float operands for example. But this is not accessible to C 
programs.

Back to comp.lang.c | Previous | NextPrevious 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