Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #42596 > unrolled thread
| Started by | partremmaps@gmail.com |
|---|---|
| First post | 2014-04-05 13:07 -0700 |
| Last post | 2014-04-07 23:48 -0700 |
| Articles | 20 on this page of 142 — 23 participants |
Back to article view | Back to comp.lang.c
Is enum a suitable way to implement a "local define?" partremmaps@gmail.com - 2014-04-05 13:07 -0700
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-05 13:55 -0700
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-05 14:14 -0700
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-06 22:18 +0200
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-06 13:28 -0700
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-06 16:35 -0400
Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-07 08:55 +1200
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-06 23:30 +0200
Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-07 10:12 +1200
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-06 18:22 -0400
Re: Is enum a suitable way to implement a "local define?" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-05 14:30 -0700
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-05 22:39 +0100
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-06 22:27 +0200
Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-07 08:52 +1200
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-06 23:20 +0100
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 02:17 +0200
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-06 19:00 -0700
Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-07 04:44 +0000
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 10:15 +0100
Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-07 18:32 +0000
Re: Is enum a suitable way to implement a "local define?" Kaz Kylheku <kaz@kylheku.com> - 2014-04-07 18:47 +0000
Re: Is enum a suitable way to implement a "local define?" Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-04-07 11:39 +0200
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 08:58 +0200
Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-07 19:34 +1200
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 09:41 +0100
Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-07 21:45 +1200
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 11:03 +0100
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 12:54 +0200
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 13:48 +0100
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 15:27 +0200
Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-07 23:00 +1200
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 11:31 +0200
Re: Is enum a suitable way to implement a "local define?" Les Cargill <lcargill99@comcast.com> - 2014-04-07 07:24 -0500
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 15:02 +0200
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 10:19 +0100
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 12:43 +0200
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 13:27 +0100
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 15:16 +0200
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 14:43 +0100
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 16:44 +0200
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 16:52 +0100
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-07 12:53 -0400
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-07 12:59 -0400
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 18:12 +0100
Re: Is enum a suitable way to implement a "local define?" Richard <rgrdev_@gmail.com> - 2014-04-07 18:27 +0100
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-08 23:22 +0100
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-08 18:44 -0400
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-09 00:22 +0100
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-08 09:39 +0200
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-08 23:27 +0100
Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-09 10:52 +1200
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-09 00:24 +0100
Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-09 11:32 +1200
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-09 08:58 +0200
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-08 19:54 -0400
Re: Is enum a suitable way to implement a "local define?" Kaz Kylheku <kaz@kylheku.com> - 2014-04-09 00:41 +0000
Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-08 23:05 +0000
Re: Is enum a suitable way to implement a "local define?" Stephen Sprunk <stephen@sprunk.org> - 2014-04-08 18:24 -0500
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-08 19:39 -0400
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-08 22:41 -0700
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-09 09:16 +0200
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-09 07:27 -0400
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-09 15:32 +0200
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-09 08:32 -0700
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-10 11:03 +0200
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 07:27 -0400
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-10 14:02 +0200
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-10 08:34 -0700
Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-10 16:36 +0000
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 12:58 -0400
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-09 11:36 -0400
Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-09 18:36 +0000
Re: Is enum a suitable way to implement a "local define?" Stephen Sprunk <stephen@sprunk.org> - 2014-04-09 14:11 -0500
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-10 13:55 +0200
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-09 02:35 +0200
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-08 23:05 -0700
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-09 09:45 +0200
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-09 08:19 -0700
Re: Is enum a suitable way to implement a "local define?" Richard <rgrdev_@gmail.com> - 2014-04-10 09:08 +0100
Re: Is enum a suitable way to implement a "local define?" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-10 02:57 -0700
Re: Is enum a suitable way to implement a "local define?" Richard <rgrdev_@gmail.com> - 2014-04-10 11:50 +0100
Re: Is enum a suitable way to implement a "local define?" Seungbeom Kim <musiphil@bawi.org> - 2014-04-10 11:37 -0700
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 14:52 -0400
Re: Is enum a suitable way to implement a "local define?" Kaz Kylheku <kaz@kylheku.com> - 2014-04-10 18:53 +0000
Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-10 19:36 +0000
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 15:59 -0400
Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-10 20:12 +0000
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 16:18 -0400
Re: Is enum a suitable way to implement a "local define?" Martin Shobe <martin.shobe@yahoo.com> - 2014-04-11 10:24 -0500
Re: Is enum a suitable way to implement a "local define?" Martin Shobe <martin.shobe@yahoo.com> - 2014-04-11 14:36 -0500
Re: Is enum a suitable way to implement a "local define?" David Thompson <dave.thompson2@verizon.net> - 2014-05-25 16:44 -0400
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-10 12:47 -0700
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 16:05 -0400
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-10 13:34 -0700
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 16:59 -0400
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-10 16:01 -0700
Re: Is enum a suitable way to implement a "local define?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-14 21:24 -0700
Re: Is enum a suitable way to implement a "local define?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-14 21:36 -0700
Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-15 05:26 +0000
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-15 07:18 -0400
Re: Is enum a suitable way to implement a "local define?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-18 09:01 -0700
Please ignore trolls Noob <root@127.0.0.1> - 2014-04-09 15:26 +0200
Re: Please ignore trolls David Brown <david.brown@hesbynett.no> - 2014-04-09 15:38 +0200
Re: Please ignore trolls James Kuyper <jameskuyper@verizon.net> - 2014-04-09 12:02 -0400
Re: Please ignore trolls Kaz Kylheku <kaz@kylheku.com> - 2014-04-09 19:18 +0000
Re: Please ignore trolls "BartC" <bc@freeuk.com> - 2014-04-10 20:18 +0100
Re: Please ignore trolls James Kuyper <jameskuyper@verizon.net> - 2014-04-10 15:49 -0400
Re: Please ignore trolls gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-10 20:14 +0000
Re: Please ignore trolls "BartC" <bc@freeuk.com> - 2014-04-11 14:35 +0100
Re: Please ignore trolls Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-11 07:35 -0700
Re: Please ignore trolls "BartC" <bc@freeuk.com> - 2014-04-11 15:51 +0100
Re: Please ignore trolls Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-04-12 15:48 +0000
Re: Please ignore trolls Kaz Kylheku <kaz@kylheku.com> - 2014-04-10 21:16 +0000
Re: Please ignore trolls "BartC" <bc@freeuk.com> - 2014-04-12 15:35 +0100
Re: Please ignore trolls Keith Thompson <kst-u@mib.org> - 2014-04-09 08:03 -0700
Re: Please ignore trolls gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-09 15:25 +0000
Re: Is enum a suitable way to implement a "local define?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-09 21:28 +0100
Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-10 08:39 +1200
Re: Is enum a suitable way to implement a "local define?" Kaz Kylheku <kaz@kylheku.com> - 2014-04-09 23:38 +0000
Re: Is enum a suitable way to implement a "local define?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-10 02:07 +0100
Re: Is enum a suitable way to implement a "local define?" Ike Naar <ike@iceland.freeshell.org> - 2014-04-09 05:18 +0000
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-09 08:05 -0700
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-07 08:33 -0700
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 17:16 +0100
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-07 11:07 -0700
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-08 09:49 +0200
Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-08 20:33 +1200
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-08 12:31 +0200
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-08 21:59 -0400
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-08 07:37 -0700
Re: Is enum a suitable way to implement a "local define?" Stephen Sprunk <stephen@sprunk.org> - 2014-04-08 08:35 -0500
Re: Is enum a suitable way to implement a "local define?" Seungbeom Kim <musiphil@bawi.org> - 2014-04-08 11:30 -0700
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-08 23:46 +0100
Re: Is enum a suitable way to implement a "local define?" Stephen Sprunk <stephen@sprunk.org> - 2014-04-08 18:28 -0500
Re: Is enum a suitable way to implement a "local define?" Seungbeom Kim <musiphil@bawi.org> - 2014-04-08 17:21 -0700
Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-09 09:07 +0100
Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-09 07:22 -0400
Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-06 16:25 -0700
Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 02:22 +0200
Re: Is enum a suitable way to implement a "local define?" Ike Naar <ike@iceland.freeshell.org> - 2014-04-06 06:08 +0000
Re: Is enum a suitable way to implement a "local define?" jacob navia <jacob@spamsink.net> - 2014-04-06 08:54 +0200
Re: Is enum a suitable way to implement a "local define?" partremmaps@gmail.com - 2014-04-07 23:48 -0700
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-07 16:52 +0100 |
| Message-ID | <4Sz0v.75086$Yw3.15453@fx15.am4> |
| In reply to | #42651 |
"David Brown" <david.brown@hesbynett.no> wrote in message
news:lhudkb$efu$1@dont-email.me...
> On 07/04/14 15:43, BartC wrote:
>> This is exactly why there needs to be a clear distinction between const
>> used
>> for readonly data, and const to name magic numbers, which is what I was
>> talking about.
>>
>
> No, there is /no/ need for such a distinction.
> And since "const" already does most of what we want, and in C++ it does
> everything we want, then the C world would be better off by just
> allowing "const" (or at least "static const") values to be used in the
> same way as they can in C++.
We'll have to disagree here. Take these four definitions:
constant int A = 1234; // proposed 'proper' constant
const int B = 1235;
int C = 1236;
int* D = &C;
They exhibit the following behaviour when used in a C expression:
Value Type ASM op
1233 1233 int load 1233
A 1234 int load A
B 1235 int load [B]
C 1236 int load [C]
D pointer to 1236 int* load [D]
*D 1236 int load [[D]]
&1233 illegal --- ---
&A illegal --- ---
&B pointer to 1235 int* load B
&C pointer to 1236 int* load C
&D ptr to ptr to 1236 int** load [D]
While in ASM code, it's more like this:
1233 1233 int
A 1234 int
B Pointer to 1235 int*
C Pointer to 1236 int*
D Ptr to ptr to 1236 int**
Notice that B and C have identical behaviour, while A is quite different,
and in fact it is the same as the naked constant '1233'.
I want the ability to explicitly control whether a named entity has A/naked
constant-like behaviour, or B/C behaviour.
You're saying we should just forget about such distinctions, and leave it up
to the compiler. Even though C has #define, enum and naked constants that
are A-like in their behaviour, we aren't allowed to formalise those and have
everything in a proper package ('constant') with the scope and type
attributes that you might expect.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-07 12:53 -0400 |
| Message-ID | <5342D800.7030507@verizon.net> |
| In reply to | #42654 |
On 04/07/2014 11:52 AM, BartC wrote: > "David Brown" <david.brown@hesbynett.no> wrote in message > news:lhudkb$efu$1@dont-email.me... ... >> And since "const" already does most of what we want, and in C++ it does >> everything we want, then the C world would be better off by just >> allowing "const" (or at least "static const") values to be used in the >> same way as they can in C++. > > We'll have to disagree here. Take these four definitions: > > constant int A = 1234; // proposed 'proper' constant > > const int B = 1235; > > int C = 1236; > > int* D = &C; > > They exhibit the following behaviour when used in a C expression: > > Value Type ASM op > > 1233 1233 int load 1233 > A 1234 int load A > B 1235 int load [B] I've learned only three assembly languages, none of which used precisely the same notation as you're using. How does "load A" differ from "load [B]"? The idea that there's a unique behavior associated with a C expression ignores the fact that the meaning of C expressions depend upon the context in which they are used. In particular, I'd expect quite different behavior for the expression 'x' in a=x, b=&x, c=sizeof(x), and d=_Alignof(x). In each of those four cases, I'd expect any decent implementation of C to generate exactly the same code whether x is 1233 or B, except for b=&1233, which I would expect to trigger a diagnostic message. It's not clear to me why different code would be generated for A than would be generated by explicit use of 1234. Could you explain that in more detail? ... > &B pointer to 1235 int* load B No, it's a pointer to B, which contains a representation of 1235. > &C pointer to 1236 int* load C That's a pointer to C, which is initialized with 1236, but need not have that same value at the time the pointer is actually used. > While in ASM code, it's more like this: > > 1233 1233 int > A 1234 int > B Pointer to 1235 int* > C Pointer to 1236 int* > D Ptr to ptr to 1236 int** That's a very peculiar ASM there - it looks a lot like C to me.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-07 12:59 -0400 |
| Message-ID | <5342D959.3050409@verizon.net> |
| In reply to | #42656 |
On 04/07/2014 12:53 PM, James Kuyper wrote: ... > > const int B = 1235; ... > ... I'd expect any decent > implementation of C to generate exactly the same code whether x is 1233 > or B, except for b=&1233, In both places where I wrote 1233, it should have been 1235.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-07 18:12 +0100 |
| Message-ID | <P0B0v.230008$4l4.85687@fx23.am4> |
| In reply to | #42656 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:5342D800.7030507@verizon.net... > On 04/07/2014 11:52 AM, BartC wrote: >> constant int A = 1234; // proposed 'proper' constant >> >> const int B = 1235; >> >> int C = 1236; >> >> int* D = &C; >> >> They exhibit the following behaviour when used in a C expression: >> >> Value Type ASM op >> >> 1233 1233 int load 1233 >> A 1234 int load A >> B 1235 int load [B] > > I've learned only three assembly languages, none of which used precisely > the same notation as you're using. How does "load A" differ from "load > [B]"? load A is load immediate. (mov eax,A in Intel format I think) (0 memory accesses) load [B] is load from memory (mov eax,[B]) (1 memory access) load [[C]] is a double memory access (eg mov esi,[C]; mov eax,[esi]). These don't correspond to any real processors. The number of memory accesses is more important. I'll reply to other points later. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard <rgrdev_@gmail.com> |
|---|---|
| Date | 2014-04-07 18:27 +0100 |
| Message-ID | <87sipp6oef.fsf@gmail.com> |
| In reply to | #42656 |
James Kuyper <jameskuyper@verizon.net> writes: > On 04/07/2014 11:52 AM, BartC wrote: >> "David Brown" <david.brown@hesbynett.no> wrote in message >> news:lhudkb$efu$1@dont-email.me... > ... >>> And since "const" already does most of what we want, and in C++ it does >>> everything we want, then the C world would be better off by just >>> allowing "const" (or at least "static const") values to be used in the >>> same way as they can in C++. >> >> We'll have to disagree here. Take these four definitions: >> >> constant int A = 1234; // proposed 'proper' constant >> >> const int B = 1235; >> >> int C = 1236; >> >> int* D = &C; >> >> They exhibit the following behaviour when used in a C expression: >> >> Value Type ASM op >> >> 1233 1233 int load 1233 >> A 1234 int load A >> B 1235 int load [B] > > I've learned only three assembly languages, none of which used precisely > the same notation as you're using. How does "load A" differ from "load [B]"? In just about any and all I toyed with years ago its direct and indirect. In fact pretty much like any language...
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-08 23:22 +0100 |
| Message-ID | <SJ_0v.147430$Bj3.36177@fx09.am4> |
| In reply to | #42656 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:5342D800.7030507@verizon.net... > On 04/07/2014 11:52 AM, BartC wrote: >> We'll have to disagree here. Take these four definitions: >> >> constant int A = 1234; // proposed 'proper' constant >> >> const int B = 1235; >> >> int C = 1236; >> >> int* D = &C; >> >> They exhibit the following behaviour when used in a C expression: > The idea that there's a unique behavior associated with a C expression > ignores the fact that the meaning of C expressions depend upon the > context in which they are used. In particular, I'd expect quite > different behavior for the expression 'x' in a=x, b=&x, c=sizeof(x), and > d=_Alignof(x). Suppose x *was* the number 7091; how many of those would still work? We are only talking about an alias for 7091, without turning it into a full variable which is the danger when you try a use an inappropriate feature (read-only variables) to implement something that really needs to be done properly. /Even if/ a smart-enough compiler can end up generating the same code. But see my reply to David Brown (time-stamped a similar time to this) which is longer. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-08 18:44 -0400 |
| Message-ID | <53447BDE.2050808@verizon.net> |
| In reply to | #42691 |
On 04/08/2014 06:22 PM, BartC wrote: > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:5342D800.7030507@verizon.net... >> On 04/07/2014 11:52 AM, BartC wrote: > >>> We'll have to disagree here. Take these four definitions: >>> >>> constant int A = 1234; // proposed 'proper' constant >>> >>> const int B = 1235; >>> >>> int C = 1236; >>> >>> int* D = &C; >>> >>> They exhibit the following behaviour when used in a C expression: > >> The idea that there's a unique behavior associated with a C expression >> ignores the fact that the meaning of C expressions depend upon the >> context in which they are used. In particular, I'd expect quite >> different behavior for the expression 'x' in a=x, b=&x, c=sizeof(x), and >> d=_Alignof(x). > > Suppose x *was* the number 7091; how many of those would still work? ... a=x, c=sizeof(x), and d=_Alignof(x). The only one disallowed would be &x, which is the same thing I've already said about 1233. Did you expect a different answer for 7091? What was the point of your question?
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-09 00:22 +0100 |
| Message-ID | <By%0v.133833$G64.1564@fx25.am4> |
| In reply to | #42694 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:53447BDE.2050808@verizon.net... > On 04/08/2014 06:22 PM, BartC wrote: >> "James Kuyper" <jameskuyper@verizon.net> wrote in message >> news:5342D800.7030507@verizon.net... >>> On 04/07/2014 11:52 AM, BartC wrote: >> >>>> We'll have to disagree here. Take these four definitions: >>>> >>>> constant int A = 1234; // proposed 'proper' constant >>>> >>>> const int B = 1235; >>>> >>>> int C = 1236; >>>> >>>> int* D = &C; >>>> >>>> They exhibit the following behaviour when used in a C expression: >> >>> The idea that there's a unique behavior associated with a C expression >>> ignores the fact that the meaning of C expressions depend upon the >>> context in which they are used. In particular, I'd expect quite >>> different behavior for the expression 'x' in a=x, b=&x, c=sizeof(x), and >>> d=_Alignof(x). >> >> Suppose x *was* the number 7091; how many of those would still work? ... > > a=x, c=sizeof(x), and d=_Alignof(x). The only one disallowed would be > &x, which is the same thing I've already said about 1233. Did you expect > a different answer for 7091? What was the point of your question? Sorry, I've lost the thread a bit! We were talking about constants, and variables, and ways to name a constant without turning it into a variable. Clearly I'm not putting across my ideas well, so I will leave it. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-04-08 09:39 +0200 |
| Message-ID | <li093i$svh$1@dont-email.me> |
| In reply to | #42654 |
On 07/04/14 17:52, BartC wrote:
> "David Brown" <david.brown@hesbynett.no> wrote in message
> news:lhudkb$efu$1@dont-email.me...
>> On 07/04/14 15:43, BartC wrote:
>
>>> This is exactly why there needs to be a clear distinction between const
>>> used
>>> for readonly data, and const to name magic numbers, which is what I was
>>> talking about.
>>>
>>
>> No, there is /no/ need for such a distinction.
>
>> And since "const" already does most of what we want, and in C++ it does
>> everything we want, then the C world would be better off by just
>> allowing "const" (or at least "static const") values to be used in the
>> same way as they can in C++.
>
> We'll have to disagree here. Take these four definitions:
>
> constant int A = 1234; // proposed 'proper' constant
>
> const int B = 1235;
>
> int C = 1236;
>
> int* D = &C;
>
> They exhibit the following behaviour when used in a C expression:
>
> Value Type ASM op
>
> 1233 1233 int load 1233
> A 1234 int load A
> B 1235 int load [B]
> C 1236 int load [C]
> D pointer to 1236 int* load [D]
> *D 1236 int load [[D]]
>
> &1233 illegal --- ---
> &A illegal --- ---
> &B pointer to 1235 int* load B
> &C pointer to 1236 int* load C
> &D ptr to ptr to 1236 int** load [D]
>
> While in ASM code, it's more like this:
>
> 1233 1233 int
> A 1234 int
> B Pointer to 1235 int*
> C Pointer to 1236 int*
> D Ptr to ptr to 1236 int**
>
> Notice that B and C have identical behaviour, while A is quite different,
> and in fact it is the same as the naked constant '1233'.
>
> I want the ability to explicitly control whether a named entity has A/naked
> constant-like behaviour, or B/C behaviour.
>
> You're saying we should just forget about such distinctions, and leave
> it up
> to the compiler. Even though C has #define, enum and naked constants that
> are A-like in their behaviour, we aren't allowed to formalise those and
> have
> everything in a proper package ('constant') with the scope and type
> attributes that you might expect.
>
Yes, we should forget about these distinctions. They are not true or
realistic anyway, so why try to pretend that they are?
Remember, a C compiler is /not/ a translator - it does not translate C
source code into assembly. It takes a /description/ or /specification/
of a task, written in the more-or-less carefully defined language C, and
generates object code that will have the same /visible/ effect as the
specified task.
Re-read that last paragraph, and think about it for a bit.
The compiler /will/ generate different types of code for different uses
of your objects here. If it knows the object in question cannot legally
be changed from 1234 (or whatever), then it can use that number directly
in the code - totally regardless of how it was defined. Conversely, if
it is more efficient to put a fixed constant in memory rather than
directly in code, then that is what the compiler will do. (This is a
common tactic on RISC processors, where loading a constant from memory
is often smaller and faster than using immediate addressing modes.)
I've said this all before, but until you understand that - until you
actually understand what C compilers /do/ - then we will be going round
in circles.
(Of course, there are some compilers that are so simple in construction
that they are basically translators, but that does not apply to "big"
compilers, and it is certainly not required by the C standards.)
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-08 23:27 +0100 |
| Message-ID | <TJ_0v.147431$Bj3.3238@fx09.am4> |
| In reply to | #42665 |
"David Brown" <david.brown@hesbynett.no> wrote in message
news:li093i$svh$1@dont-email.me...
> On 07/04/14 17:52, BartC wrote:
[On the distinction between an actual constant, a named actual constant, and
a variable that may or may not have a read-only attribute]
>> You're saying we should just forget about such distinctions, and leave
>> it up
> Yes, we should forget about these distinctions. They are not true or
> realistic anyway, so why try to pretend that they are?
> Remember, a C compiler is /not/ a translator - it does not translate C
> source code into assembly. It takes a /description/ or /specification/
> of a task, written in the more-or-less carefully defined language C, and
> generates object code that will have the same /visible/ effect as the
> specified task.
The distinction can be there in the /language/. Clearly not directly in C
because it doesn't have such a language construct, but some people who want
to code would like to have it because it makes certain things obvious and
not a consequence of a whim of a compiler writer.
With C, you can write 5678, but not &5678.
You can declare a variable xyz, and write as xyz to obtain the value, or as
&xyz to obtain its name (ie. a constant pointer value).
Why can't I declare abc as a synonym for 5678, but be stopped from writing
&abc? After all I can used #define or enum to declare abc, with some
limitations, and I can't write &abc then either.
Instead of a simple, logical extension to allow such a declaration, where it
will be completely obvious what it is and what it can do, you instead
propose using a *variable* for the purpose, which so many issues associated
with it that I hardly know where to start! But I will have a go:
o You expect users to apply a 'read-only' attribute to a /variable/, as a
hint to a compiler, so that it can pick up its initialisation value, if
there is one, and treat that as though it is a simple named constant. That
is going around the houses a little!
o It is necessary to use either 'static const int' or 'const int', although
I'm not sure what the difference is between them (that with static const, it
can only be initialised to a constant expression)?
o 'static const int' doesn't need an initialisation value! (Presumably this
is then set to zero, but for a mechanism designed to define constant values,
this is a bigger sin that omitting an explicit type.) ('const int' doesn't
need one either, and the value then is undefined.)
o 'const int' can be set to a runtime value! Presumably such a name cannot
be used as a simple named constant; or can it? The possibilities are
complicated.
o 'const int' variables can, in certain circumstances, have their values
changed, so will differ from what the compiler thinks they might be.
o '[static] const int]' exists now in C, yet cannot be used for dimensioning
arrays or switch case-values. Maybe I missed something in the discussion,
but why is that? And what will change in future as apparently you are not
proposing any new syntax.
o I've just tried using a 'const int' value to define an array, and this
time it worked. Then I realised I was probably creating a VLA. I don't want
to inadvertently construct VLAs!
So, full of difficulties, so I don't understand your objection to my very
simple proposal, which has few of those problems:
o The name created is *not* a variable
o The initialisation value is mandatory, and *must* be evaluable at
compile-time
o The value will *never* change, and you can never take its address
o It can be used to dimension non-VLA arrays, as switch case-values, and can
be used to construct other such values
> (Of course, there are some compilers that are so simple in construction
> that they are basically translators, but that does not apply to "big"
> compilers, and it is certainly not required by the C standards.)
You can't propose an essential language feature and then say you need an
elite compiler to implement it properly!
(And it might be true that some processors are not so good with immediate
values and they will require storage anyway; that should not affect the
abstract view of the language; if you are still going to separate naked
constants and named variables, then the idea of a named constant should also
be distinct.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-09 10:52 +1200 |
| Message-ID | <bqjctjF4crdU6@mid.individual.net> |
| In reply to | #42692 |
BartC wrote: <snip> > So, full of difficulties, so I don't understand your objection to my very > simple proposal, which has few of those problems: > > o The name created is *not* a variable > o The initialisation value is mandatory, and *must* be evaluable at > compile-time > o The value will *never* change, and you can never take its address > o It can be used to dimension non-VLA arrays, as switch case-values, and can > be used to construct other such values With the exception of not having an address, C++'s constexpr meets your requirements. I don't see why having an address is an issue if the value is immutable. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-09 00:24 +0100 |
| Message-ID | <Cy%0v.133834$G64.38931@fx25.am4> |
| In reply to | #42696 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:bqjctjF4crdU6@mid.individual.net... > BartC wrote: > > <snip> > >> So, full of difficulties, so I don't understand your objection to my >> very >> simple proposal, which has few of those problems: >> >> o The name created is *not* a variable >> o The initialisation value is mandatory, and *must* be evaluable at >> compile-time >> o The value will *never* change, and you can never take its address >> o It can be used to dimension non-VLA arrays, as switch case-values, and >> can >> be used to construct other such values > > With the exception of not having an address, C++'s constexpr meets your > requirements. I don't see why having an address is an issue if the value > is immutable. Possibly. But this is about C. As for my requirements, it's just having a simple feature the equivalent of Pascal's CONST, or any assembler's EQU, without having to drag variables into it, which is a much harder, and less natural way of achieving it. I don't know why I'm having such a hard time convincing people that it would be a good idea to have in C, because at present there is no satisfactory, general way of doing this. However, because this is about the C source language, it is less my concern now as I am moving away from actually having to use it. I just sort of feel sorry for people who continue to have to battle with such things! (If I generate C code, then my named constants get written out as naked constants in C, completely bypassing the problem. And I am currently moving away from that too, and generating native code directly, eliminating a lot of C compiler and language problems, but not all.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-09 11:32 +1200 |
| Message-ID | <bqjf8fF4crdU7@mid.individual.net> |
| In reply to | #42700 |
BartC wrote: > "Ian Collins" <ian-news@hotmail.com> wrote in message > news:bqjctjF4crdU6@mid.individual.net... >> BartC wrote: >> >> <snip> >> >>> So, full of difficulties, so I don't understand your objection to my >>> very >>> simple proposal, which has few of those problems: >>> >>> o The name created is *not* a variable >>> o The initialisation value is mandatory, and *must* be evaluable at >>> compile-time >>> o The value will *never* change, and you can never take its address >>> o It can be used to dimension non-VLA arrays, as switch case-values, and >>> can >>> be used to construct other such values >> >> With the exception of not having an address, C++'s constexpr meets your >> requirements. I don't see why having an address is an issue if the value >> is immutable. > > Possibly. But this is about C. The discussion looks like it is about an extension to C. C++'s constexpr would be a useful extension to C that meets your requirements. > As for my requirements, it's just having a simple feature the equivalent of > Pascal's CONST, or any assembler's EQU, without having to drag variables > into it, which is a much harder, and less natural way of achieving it. I > don't know why I'm having such a hard time convincing people that it would > be a good idea to have in C, because at present there is no satisfactory, > general way of doing this. A constexpr isn't a variable. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-04-09 08:58 +0200 |
| Message-ID | <li2r1p$pgi$1@dont-email.me> |
| In reply to | #42703 |
On 09/04/14 01:32, Ian Collins wrote:
> BartC wrote:
>> "Ian Collins" <ian-news@hotmail.com> wrote in message
>> news:bqjctjF4crdU6@mid.individual.net...
>>> BartC wrote:
>>>
>>> <snip>
>>>
>>>> So, full of difficulties, so I don't understand your objection to my
>>>> very
>>>> simple proposal, which has few of those problems:
>>>>
>>>> o The name created is *not* a variable
>>>> o The initialisation value is mandatory, and *must* be evaluable at
>>>> compile-time
>>>> o The value will *never* change, and you can never take its address
>>>> o It can be used to dimension non-VLA arrays, as switch case-values,
>>>> and
>>>> can
>>>> be used to construct other such values
>>>
>>> With the exception of not having an address, C++'s constexpr meets your
>>> requirements. I don't see why having an address is an issue if the
>>> value
>>> is immutable.
>>
>> Possibly. But this is about C.
>
> The discussion looks like it is about an extension to C. C++'s
> constexpr would be a useful extension to C that meets your requirements.
>
>> As for my requirements, it's just having a simple feature the
>> equivalent of
>> Pascal's CONST, or any assembler's EQU, without having to drag variables
>> into it, which is a much harder, and less natural way of achieving it. I
>> don't know why I'm having such a hard time convincing people that it
>> would
>> be a good idea to have in C, because at present there is no satisfactory,
>> general way of doing this.
>
> A constexpr isn't a variable.
>
In Pascal, however, some CONST's /are/ variables - in Borland Pascal
(and Delphi), a so-called "typed constant", such as "const i : integer =
123;", is equivalent to "static int i = 123;" in C - it is just a
persistent initialised variable. C is not alone among programming
languages in having the occasional bit of confusing syntax!
A constexpr is not a variable - and neither is a plain "const" or
"static const" in C.
"constexpr" for objects is useful in C++ because there "const" means "as
far as /you/ can tell, this thing is constant - you can't legally change
it, and you can rely on it looking unchanged". But an object in C++ can
be "const" and still have bits ("mutable" bits) that get changed behind
the scenes. So "constexpr" is an extra level above "const" to guarantee
that the object is absolutely fixed at compile-time. It's a level of
complication that is not really needed in C.
"constexpr" for functions, however, could be useful in C (as in C++) as
it marks a function for evaluation at compile time, and lets you use the
function and its results as compile-time constants.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-08 19:54 -0400 |
| Message-ID | <53448C25.1060404@verizon.net> |
| In reply to | #42700 |
On 04/08/2014 07:24 PM, BartC wrote: > > > "Ian Collins" <ian-news@hotmail.com> wrote in message > news:bqjctjF4crdU6@mid.individual.net... ... >> With the exception of not having an address, C++'s constexpr meets your >> requirements. I don't see why having an address is an issue if the value >> is immutable. > > Possibly. But this is about C. No, it's about modifications to C. Your proposal is to modify it by adding a new keyword 'constant'. However, many of us, while recognizing the validity of some of your complaints about the current C rules, consider the adoption of C++ rules to be a superior solution, if only because of improved compatibility with C++. > However, because this is about the C source language, it is less my concern > now as I am moving away from actually having to use it. I just sort of feel > sorry for people who continue to have to battle with such things! We don't battle with it very often. We use #defines if an integer constant expression is needed, and otherwise declare const-qualified object with static storage duration if we want tighter control over type safety and scope. Under the current rules, we can't do both, but that is seldom a big problem. I'd like to see the C++ rules adopted, but I'm not suffering from the fact that this hasn't been done yet. > (If I generate C code, then my named constants get written out as naked > constants in C, completely bypassing the problem. And I am currently moving > away from that too, and generating native code directly, eliminating a lot > of C compiler and language problems, but not all.) I strongly recommend that approach - you want tighter control over the generated code than C was ever intended to give you.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-09 00:41 +0000 |
| Message-ID | <20140408173919.922@kylheku.com> |
| In reply to | #42706 |
On 2014-04-09, Stefan Ram <ram@zedat.fu-berlin.de> wrote: > Introducing »constexpr« as a keyword might also only break a > very small number of existing C programs. Introducing *anything* only breaks those programs which are compiled with the equivalent of "compiler-name --iso-standard=2014". The one body of code that needs to be maintained is the header files of implementations, which are generally expected to work regardless of the dialect selection.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-08 23:05 +0000 |
| Message-ID | <li1vb0$oot$1@speranza.aioe.org> |
| In reply to | #42692 |
BartC <bc@freeuk.com> wrote: (snip) > The distinction can be there in the /language/. Clearly not directly in C > because it doesn't have such a language construct, but some people who want > to code would like to have it because it makes certain things obvious and > not a consequence of a whim of a compiler writer. > With C, you can write 5678, but not &5678. > You can declare a variable xyz, and write as xyz to obtain the value, or as > &xyz to obtain its name (ie. a constant pointer value). > Why can't I declare abc as a synonym for 5678, but be stopped from writing > &abc? After all I can used #define or enum to declare abc, with some > limitations, and I can't write &abc then either. Some years ago when C enum was added to Fortran (as part of the C interoperabity feature) I had wondered about this. For one, Fortran doesn't call by value, but normally (though not required) call by reference. (Call by value result is also allowed.) In C, enum constants are int, even when enum variables are not, but I believe in Fortran the constants are the same type (KIND) as variables. Otherwise, call by reference would fail. Also, you are not supposed to modify a constant. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-08 18:24 -0500 |
| Message-ID | <li20fu$3cu$1@dont-email.me> |
| In reply to | #42692 |
On 08-Apr-14 17:27, BartC wrote: > With C, you can write 5678, but not &5678. > > You can declare a variable xyz, and write as xyz to obtain the value, > or as &xyz to obtain its name (ie. a constant pointer value). Unless you give it "register" storage class. > Why can't I declare abc as a synonym for 5678, but be stopped from > writing &abc? You can do the latter, at least; see above. > o You expect users to apply a 'read-only' attribute to a /variable/, The term is "object", not "variable". > o 'const int' can be set to a runtime value! Presumably such a name > cannot be used as a simple named constant; or can it? The > possibilities are complicated. > > o 'const int' variables can, in certain circumstances, have their > values changed, so will differ from what the compiler thinks they > might be. If the object is "const int", then changing its value invokes UB. Things get trickier when you pass a pointer-to-int to a function taking pointer-to-const-int, since AFAIK the pointed-to value may change without the compiler's knowledge despite being const. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-08 19:39 -0400 |
| Message-ID | <5344889A.20407@verizon.net> |
| In reply to | #42692 |
On 04/08/2014 06:27 PM, BartC wrote:
> "David Brown" <david.brown@hesbynett.no> wrote in message
> news:li093i$svh$1@dont-email.me...
>> On 07/04/14 17:52, BartC wrote:
> [On the distinction between an actual constant, a named actual constant, and
> a variable that may or may not have a read-only attribute]
>
>>> You're saying we should just forget about such distinctions, and leave
>>> it up
>
>> Yes, we should forget about these distinctions. They are not true or
>> realistic anyway, so why try to pretend that they are?
>
>> Remember, a C compiler is /not/ a translator - it does not translate C
>> source code into assembly. It takes a /description/ or /specification/
>> of a task, written in the more-or-less carefully defined language C, and
>> generates object code that will have the same /visible/ effect as the
>> specified task.
>
> The distinction can be there in the /language/. Clearly not directly in C
> because it doesn't have such a language construct, but some people who want
> to code would like to have it because it makes certain things obvious and
> not a consequence of a whim of a compiler writer.
If you care which method the compiler writer uses, C isn't the language
for you. The whole point of using C is to save you the work of having to
specify such things, leaving it up to the compiler. If you don't trust
the compiler, don't use a language that gives the compiler a choice - C
is very deliberately NOT such a language.
...
> o It is necessary to use either 'static const int' or 'const int', although
> I'm not sure what the difference is between them (that with static const, it
> can only be initialised to a constant expression)?
It depends upon the scope. It's stupid that C gives two entirely
different meanings to 'static' (there's also a third one that's not
relevant to this question); but it's a historical artifact, and changing
the standard now to cleanly separate the two concepts would break too
much code.
At block scope, static determines whether the variable has automatic or
static storage duration. Now, you can't write code with defined behavior
that changes the value of the variable, and if it has automatic storage
duration, there's no way to write code with defined behavior that checks
what the value is between calls to the function. Therefore, a conforming
implementation could treat a "const int" precisely the same as a "static
const int", reducing unnecessary memory usage and unnecessary
re-initialization.
That's not quite true; a block scope "static const int" would have the
same exact address during every pass through function. That could also
be true if it had automatic storage duration, so is not itself a problem
- unless the function is directly or indirectly recursive, and compares
the addresses. It's not clear to me that optimizing "const int" by
treating it the same as "static const int" would be permitted for
recursive functions - which is an argument for explicitly using "static
const int".
At file scope, "static" determines whether the variable has internal or
external linkage. If it has internal linkage, and the program never
takes it's address, no actual storage need be allocated for it, the same
as at block scope. However, if it has external linkage, then there can
only be one definition for the variable across all of the translation
units that make up the program. It's value would have to be unknown in
every translation unit other than the one where it is defined. As a
result, it wouldn't be a compile time constant in those other modules,
which would pretty much destroy the whole point of defining such a
variable. Again, the preferred declaration is "static const int".
> o 'static const int' doesn't need an initialisation value! (Presumably this
> is then set to zero, but for a mechanism designed to define constant values,
> this is a bigger sin that omitting an explicit type.) ('const int' doesn't
> need one either, and the value then is undefined.)
You're apparently thinking of block scope. At file scope, "const int"
automatically has static storage duration, so it is initialized to 0 if
not explicitly initialized to anything else, just the same as for
"static const int".
> o 'const int' can be set to a runtime value! Presumably such a name cannot
> be used as a simple named constant; or can it? The possibilities are
> complicated.
The rule in C++, which people are saying should be adopted in C, applies
only to variables initialized with constant expressions. It would not
apply to variables initialized by runtime values.
> o 'const int' variables can, in certain circumstances, have their values
> changed, so will differ from what the compiler thinks they might be.
Not during their lifetimes, not with defined behavior.
> o '[static] const int]' exists now in C, yet cannot be used for dimensioning
> arrays or switch case-values. Maybe I missed something in the discussion,
> but why is that? And what will change in future as apparently you are not
> proposing any new syntax.
The proposal is to adopt C++ rules: a integer const variable initialized
with a integer constant expression is itself an integer constant
expression; as such, it would be usable in those contexts.
> o I've just tried using a 'const int' value to define an array, and this
> time it worked. Then I realised I was probably creating a VLA. I don't want
> to inadvertently construct VLAs!
In C as currently defined, it creates a VLA. With the proposed change,
it would automatically not be a VLA: the standard already says "If the
size is an integer constant expression and the element type has a known
constant size, the array type is not a variable length array type."
(6.7.6.2p4) so no additional changes would be needed to make that true.
> So, full of difficulties, so I don't understand your objection to my very
> simple proposal, which has few of those problems:
>
> o The name created is *not* a variable
I don't see this as any particular advantage (or disadvantage). In the
unlikely case that you need a const object initialized with the value of
a constant, so you can pass it's address to a function, you can
currently use &const_variable. With your rules, you'd have to use:
const int dummy = constant_value;
and then pass &dummy. It's an absolutely trivial inconvenience, because
there's seldom ever a need to do such things, but I don't see any
corresponding compensating conveniences.
> o The initialisation value is mandatory, and *must* be evaluable at
> compile-time
C++ has actually adopted this rule for const variables with static
storage duration, for precisely the same reason you've given for your
construct.
>> (Of course, there are some compilers that are so simple in construction
>> that they are basically translators, but that does not apply to "big"
>> compilers, and it is certainly not required by the C standards.)
>
> You can't propose an essential language feature and then say you need an
> elite compiler to implement it properly!
It doesn't require an elite compiler to implement this. This is standard
state-of-the art for C++ compilers, and has been for quite some time.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-08 22:41 -0700 |
| Message-ID | <lnlhvfawl3.fsf@nuthaus.mib.org> |
| In reply to | #42704 |
James Kuyper <jameskuyper@verizon.net> writes:
[...]
> The proposal is to adopt C++ rules: a integer const variable initialized
> with a integer constant expression is itself an integer constant
> expression; as such, it would be usable in those contexts.
The C++ rule, as I understand it, is that if a const-qualified object is
initialized with an integer constant expression, then the name of the
object (when not used in a context requiring an lvalue) is a constant
expression. The object itself is still an object.
const int a = 42;
double this_is_not_a_VLA[a];
const int *but_a_has_an_address = &a;
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web