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

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

Is enum a suitable way to implement a "local define?"

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

Contents

  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 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

#42723

On 09/04/14 01:39, James Kuyper wrote:
> On 04/08/2014 06:27 PM, BartC wrote:

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

I like to think of "static" as meaning "static allocation", i.e., a
fixed address and lifetime throughout the program, and minimal scope and
linkage.  Although that combines two different concepts in one keyword,
it applies to both file scope and block scope "static" - and I think
that reduces the confusion a little.

One difference between the uses is that at file scope you should use
"static" whenever possible, as it makes the program more modular,
reduces namespace collisions, and lets the compiler generate better code
(sometimes removing the "static" data or function altogether).  In block
scope, on the other hand, you should normally only use "static" if you
actually need it, as it generally makes code less efficient.  An
exception is block scope const's with compile-time known initialisers -
making these "static const" is generally a good idea.


I would have preferred "static" to mean only the static allocation part,
that internal linkage was the default in C, and that an extra keyword
(such as "export" or "public") would be needed to give an object or
function external linkage.  Defaulting to global external linkage was a
fundamental error in the C language design, IMHO.  But it is too late to
change now.

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

#42727

On 04/09/2014 03:16 AM, David Brown wrote:
> On 09/04/14 01:39, James Kuyper wrote:
...
>> 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.
...
> I like to think of "static" as meaning "static allocation", i.e., a
> fixed address and lifetime throughout the program, and minimal scope and
> linkage.  Although that combines two different concepts in one keyword,
> it applies to both file scope and block scope "static" - and I think
> that reduces the confusion a little.

But you can get a fixed address and lifetime throughout the program
without using the 'static' keyword, just by declaring the object at file
scope. Similarly, you can get minimal scope and linkage without using
the 'static' keyword, just by declaring the object with block scope.

It was a mistake to use the same keyword for making both kinds of
distinctions - it causes frequent confusion - and I think that trying to
create a merged concept that justifies that mistake is a further mistake.
-- 
James Kuyper

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

#42730

On 09/04/14 13:27, James Kuyper wrote:
> On 04/09/2014 03:16 AM, David Brown wrote:
>> On 09/04/14 01:39, James Kuyper wrote:
> ...
>>> 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.
> ...
>> I like to think of "static" as meaning "static allocation", i.e., a
>> fixed address and lifetime throughout the program, and minimal scope and
>> linkage.  Although that combines two different concepts in one keyword,
>> it applies to both file scope and block scope "static" - and I think
>> that reduces the confusion a little.
> 
> But you can get a fixed address and lifetime throughout the program
> without using the 'static' keyword, just by declaring the object at file
> scope. Similarly, you can get minimal scope and linkage without using
> the 'static' keyword, just by declaring the object with block scope.
> 

You can't get file scope with internal linkage without using "static".

> It was a mistake to use the same keyword for making both kinds of
> distinctions - it causes frequent confusion - and I think that trying to
> create a merged concept that justifies that mistake is a further mistake.
> 

I agree that the two concepts should not have been mixed (as noted in
the part of my post that you snipped here).  So I am not trying to
justify it - I am just trying to give a meaning to the "static" keyword
which covers its practical effects.  I have found it helpful in the past
when answering the common question "what does "static" mean in C?", so I
repeated it here in case other people found it helpful.

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

#42736

David Brown <david.brown@hesbynett.no> writes:
> On 09/04/14 13:27, James Kuyper wrote:
[...]
>> It was a mistake to use the same keyword for making both kinds of
>> distinctions - it causes frequent confusion - and I think that trying to
>> create a merged concept that justifies that mistake is a further mistake.
>
> I agree that the two concepts should not have been mixed (as noted in
> the part of my post that you snipped here).  So I am not trying to
> justify it - I am just trying to give a meaning to the "static" keyword
> which covers its practical effects.  I have found it helpful in the past
> when answering the common question "what does "static" mean in C?", so I
> repeated it here in case other people found it helpful.

An object defined within a function definition has block scope,
automatic storage duration, and no linkage by default.  The "static"
keyword changes the storage duration from automatic to static,
without affecting the scope or linkage.

An object defined outside any function definition has file
scope, static storage duration, and external linkage by default.
The "static" keyword changes the linkage from external to internal,
without affecting the scope or storage duration.

I don't think there's any reasonable way to view those as a single
meaning.

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

#42750

On 09/04/14 17:32, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 09/04/14 13:27, James Kuyper wrote:
> [...]
>>> It was a mistake to use the same keyword for making both kinds of
>>> distinctions - it causes frequent confusion - and I think that trying to
>>> create a merged concept that justifies that mistake is a further mistake.
>>
>> I agree that the two concepts should not have been mixed (as noted in
>> the part of my post that you snipped here).  So I am not trying to
>> justify it - I am just trying to give a meaning to the "static" keyword
>> which covers its practical effects.  I have found it helpful in the past
>> when answering the common question "what does "static" mean in C?", so I
>> repeated it here in case other people found it helpful.
> 
> An object defined within a function definition has block scope,
> automatic storage duration, and no linkage by default.  The "static"
> keyword changes the storage duration from automatic to static,
> without affecting the scope or linkage.
> 
> An object defined outside any function definition has file
> scope, static storage duration, and external linkage by default.
> The "static" keyword changes the linkage from external to internal,
> without affecting the scope or storage duration.
> 
> I don't think there's any reasonable way to view those as a single
> meaning.
> 

I am aware of the technical standards-language details here, and I agree
that the two cases can't be combined at that level.  But most C
programmers don't understand about linkage - they just know that some
data can be accessed from other C files, and some cannot.  It can be
helpful to give such inexperienced programmers an idea that links the
two uses of "static" - it helps familiarise them with the keyword and
its uses.  I am not suggesting it as an accurate definition.

So if you don't like the explanation of "static" that I gave, that's
fine.  If someone relatively new to C finds it helpful in getting to
grips with some of C's concepts and keywords, then that's fine too.

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

#42753

On 04/10/2014 05:03 AM, David Brown wrote:
...
> I am aware of the technical standards-language details here, and I agree
> that the two cases can't be combined at that level.  But most C
> programmers don't understand about linkage - they just know that some
> data can be accessed from other C files, and some cannot.  It can be
> helpful to give such inexperienced programmers an idea that links the
> two uses of "static" - it helps familiarise them with the keyword and
> its uses. ...

That's the key point of disagreement - I don't think it can be helpful.
I think it would be far more helpful to teach them how to clearly
distinguish the two meanings. That means you'll have to teach them not
only about linkage and storage duration, but also about scope, since
that's what determines which of the two meanings applies. That is a lot
to learn for a beginner - but those three topics are also very important
things that a beginner should learn about fairly early.
-- 
James Kuyper

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

#42755

On 10/04/14 13:27, James Kuyper wrote:
> On 04/10/2014 05:03 AM, David Brown wrote:
> ...
>> I am aware of the technical standards-language details here, and I agree
>> that the two cases can't be combined at that level.  But most C
>> programmers don't understand about linkage - they just know that some
>> data can be accessed from other C files, and some cannot.  It can be
>> helpful to give such inexperienced programmers an idea that links the
>> two uses of "static" - it helps familiarise them with the keyword and
>> its uses. ...
> 
> That's the key point of disagreement - I don't think it can be helpful.
> I think it would be far more helpful to teach them how to clearly
> distinguish the two meanings. That means you'll have to teach them not
> only about linkage and storage duration, but also about scope, since
> that's what determines which of the two meanings applies. That is a lot
> to learn for a beginner - but those three topics are also very important
> things that a beginner should learn about fairly early.
> 

Maybe you are right here.  Which method is the most helpful at any given
time will vary, but I will consider your points next time the occasion
arises.  Giving people a single sort-of explanation of "static" has
helped in the past, but as they say "past performance is no guarantee of
future results" :-)

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

#42760

David Brown <david.brown@hesbynett.no> writes:
> On 09/04/14 17:32, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 09/04/14 13:27, James Kuyper wrote:
>> [...]
>>>> It was a mistake to use the same keyword for making both kinds of
>>>> distinctions - it causes frequent confusion - and I think that trying to
>>>> create a merged concept that justifies that mistake is a further mistake.
>>>
>>> I agree that the two concepts should not have been mixed (as noted in
>>> the part of my post that you snipped here).  So I am not trying to
>>> justify it - I am just trying to give a meaning to the "static" keyword
>>> which covers its practical effects.  I have found it helpful in the past
>>> when answering the common question "what does "static" mean in C?", so I
>>> repeated it here in case other people found it helpful.
>> 
>> An object defined within a function definition has block scope,
>> automatic storage duration, and no linkage by default.  The "static"
>> keyword changes the storage duration from automatic to static,
>> without affecting the scope or linkage.
>> 
>> An object defined outside any function definition has file
>> scope, static storage duration, and external linkage by default.
>> The "static" keyword changes the linkage from external to internal,
>> without affecting the scope or storage duration.
>> 
>> I don't think there's any reasonable way to view those as a single
>> meaning.
>
> I am aware of the technical standards-language details here, and I agree
> that the two cases can't be combined at that level.  But most C
> programmers don't understand about linkage - they just know that some
> data can be accessed from other C files, and some cannot.  It can be
> helpful to give such inexperienced programmers an idea that links the
> two uses of "static" - it helps familiarise them with the keyword and
> its uses.  I am not suggesting it as an accurate definition.

If most C programmers don't understand linkage, then they need to learn.

> So if you don't like the explanation of "static" that I gave, that's
> fine.  If someone relatively new to C finds it helpful in getting to
> grips with some of C's concepts and keywords, then that's fine too.

I honestly fail to see how any explanation of the two meanings of
"static" that doesn't (a) acknowledge that the two meanings are entirely
different, and (b) explain what those two meanings are could be useful.

Hypothetically, if C used two different keywords for the two uses, would
you even consider trying to explain them as if they were a single
concept?

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

#42764

Keith Thompson <kst-u@mib.org> wrote:

(snip)
> I honestly fail to see how any explanation of the two meanings of
> "static" that doesn't (a) acknowledge that the two meanings are 
> entirely different, and (b) explain what those two meanings 
> are could be useful.
 
> Hypothetically, if C used two different keywords for the two uses, 
> would you even consider trying to explain them as if they were 
> a single concept?

Why use words instead of random combinations of meaningless letters?
(Well, I don't know about non-english speakers, who might consider
them meaningless.)  The words are supposed to remind us of the
meaning and use for that keyword. If a keyword has a meaning
unrelated to its normal meaning (or even CS meaning) that is
confusing to users.

-- glen

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

#42765

On 04/10/2014 12:36 PM, glen herrmannsfeldt wrote:
...
> meaning and use for that keyword. If a keyword has a meaning
> unrelated to its normal meaning (or even CS meaning) that is
> confusing to users.

That's precisely why using "static" to give an identifier "internal
linkage" was a bad idea - but the deed has been done, the need to
maintain backwards compatibility prevents fixing it, so now we have to
deal with it.

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

#42737

On 04/09/2014 09:32 AM, David Brown wrote:
...
>> scope. Similarly, you can get minimal scope and linkage without using
>> the 'static' keyword, just by declaring the object with block scope.
>>
> 
> You can't get file scope with internal linkage without using "static".

File scope isn't minimal; it's the largest scope available. And "no
linkage" is more minimal than "internal linkage".

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

#42739

David Brown <david.brown@hesbynett.no> wrote:
> On 09/04/14 01:39, James Kuyper wrote:

(snip)
>> 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.

I thought it was four or five, but I haven't been counting.
But most of them don't have the meaning that "static" should
have.
 
(big snip)

> I like to think of "static" as meaning "static allocation", i.e., a
> fixed address and lifetime throughout the program, and minimal scope and
> linkage.  Although that combines two different concepts in one keyword,
> it applies to both file scope and block scope "static" - and I think
> that reduces the confusion a little.

I usually use static for look-up tables, that is, initialized
arrays. Partly that is from the K&R days where auto arrays couldn't
have initializers. 

It probably is true on many current processors that access to
stack (auto) data is faster than static, but then the auto
array has to be reinitialized (copied from somewhere) on each
entry to the function.
 
(snip)

> I would have preferred "static" to mean only the static allocation part,
> that internal linkage was the default in C, and that an extra keyword
> (such as "export" or "public") would be needed to give an object or
> function external linkage.  Defaulting to global external linkage was a
> fundamental error in the C language design, IMHO.  But it is too late to
> change now.

Well, in other languages it is something like "external" that
gives external linkage. I was never quite sure where the funny C
rules on "extern" came from, as other languages don't have that rule,
and still manage to work.  Well, partly it is a side effect of
static variables always being initialized.

-- glen

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

#42740

On 09-Apr-14 13:36, glen herrmannsfeldt wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> I like to think of "static" as meaning "static allocation", i.e.,
>> a fixed address and lifetime throughout the program, and minimal
>> scope and linkage.  Although that combines two different concepts
>> in one keyword, it applies to both file scope and block scope
>> "static" - and I think that reduces the confusion a little.
> 
> I usually use static for look-up tables, that is, initialized arrays.
> Partly that is from the K&R days where auto arrays couldn't have
> initializers.
> 
> It probably is true on many current processors that access to stack
> (auto) data is faster than static,

The top of the stack is almost certainly in cache whereas the static
data won't be unless you've used it recently, but OOO mechanisms on most
"current processors" should be able to hide that difference.

If both are in (or both out) of cache, though, access speed should be
identical unless your lookup tables are stored in ROM or Flash, which is
a whole 'nother matter entirely.

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]

#42754

On 09/04/14 21:11, Stephen Sprunk wrote:
> On 09-Apr-14 13:36, glen herrmannsfeldt wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> I like to think of "static" as meaning "static allocation", i.e.,
>>> a fixed address and lifetime throughout the program, and minimal
>>> scope and linkage.  Although that combines two different concepts
>>> in one keyword, it applies to both file scope and block scope
>>> "static" - and I think that reduces the confusion a little.
>>
>> I usually use static for look-up tables, that is, initialized arrays.
>> Partly that is from the K&R days where auto arrays couldn't have
>> initializers.
>>
>> It probably is true on many current processors that access to stack
>> (auto) data is faster than static,
> 
> The top of the stack is almost certainly in cache whereas the static
> data won't be unless you've used it recently, but OOO mechanisms on most
> "current processors" should be able to hide that difference.

That's true - but if you are initialising the stack table, you need to
copy all the data from a source into the stack.  The source is unlikely
to be in cache in advance, so this copying will take some time.

> 
> If both are in (or both out) of cache, though, access speed should be
> identical unless your lookup tables are stored in ROM or Flash, which is
> a whole 'nother matter entirely.
> 

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

#42713

On 09/04/14 00:27, 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.
>
> With C, you can write 5678, but not &5678.
>

OK...

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

OK...

But note that xyz will not necessarily have an address unless you ask 
for one (with &) and make use of that address.  Local variables 
typically stay in registers or are optimised away completely - they only 
naturally have an address if the register set overflows onto the stack 
(or if you force them to have an address using &).

And "static const" objects will not have an address or allocated memory 
unless you ask for the address, or if a specific memory location gives 
the most efficient code.

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

I don't know why you would want this.  It is not exactly a common typo - 
so the way to stop yourself from writing &abc is simply don't write it.

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

A "const" is not a variable - it is a constant object.  So instead of 
introducing some sort of new type of constant to the language, I would 
rather take the existing const concept and extend it slightly (as it is 
in C++) to cover the remaining needs for constants.  That is far 
simpler, clearer and easier than having a new type of constant - and it 
already exists in C++.

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

"const" is not a hint to the compiler about variables - it is a specific 
direction that this object will be constant, and will never be changed. 
  (It is /possible/ to do so using casts, but the result is clearly 
undefined behaviour, and cannot be achieved by accident due to the 
explicit casts needed, and all the compiler error messages and/or 
diagnostic warnings.)


I think you are mixing up the use of "const" in definitions such as 
"static const int xyz = 123;", and its use in function arguments 
(especially for pointers), such as "size_t strlen(const char* s)".

With the "const" declaration, you are telling the compiler that the 
object will /never/ change value after its definition - so it can 
happily use the initialisation value directly in code.  For externally 
defined constants, the compiler does not know the initialisation value - 
it is forced to put the constant into memory so that other modules can 
access it.  But the memory can be read-only memory, and the compiler can 
rely on the unchanging nature of the object.  For "static const" 
objects, the compiler does not have to put it into memory, but can use 
the initialisation value directly as a compile-time fixed value.  It is 
a mere quirk of C language definitions that disallow the use of static 
consts for things like array sizes.

When you use the const qualifier in a function argument, like 
"strlen(const char* s)", you are telling the compiler that you will not 
change anything through the pointer "s".  It is not a hint - it is a 
promise, and the compiler will hold you to it (with error messages) and 
can take advantage of the knowledge that the data will be unchanged.

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

You are arguing for language extensions, and you don't even understand 
the basics of C as it is?

At file level (i.e., not inside a function), "static" objects and 
functions are local to the file - they have no external linkage, and 
other compilation units cannot refer to them.  Unless the objects escape 
because you take their address and pass it on to another module through 
function calls, then the compiler knows everything about the "static" 
object's usage during compilation.  In the case of a "static const", if 
the initialisation value can be used directly in the code then it does 
not need to make a memory location for the constant object.  In the case 
of functions, the compiler can do more optimisation or inlining because 
it does not have to follow standard calling conventions.

Functions and objects that are not "static" have external linkage - 
other modules can refer to them by name, so they must follow standard 
calling conventions and memory placement (unless you are using link-time 
optimisations, of course).


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

"const" objects, like variables, are initialised to 0 if you don't give 
an explicit initialisation.

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

"const" objects, like variables, must be initialised to compile-time 
constants if they are at file scope (or function-local statics).  When 
they are used locally in functions, they don't exist until the function 
is run - of course they can be initialised to any value that is 
available when the function is run.

>
> o 'const int' variables can, in certain circumstances, have their values
> changed, so will differ from what the compiler thinks they might be.

No, they cannot be changed - any attempt to change them is undefined 
behaviour.

(There is such as thing as a "volatile const" object, which is something 
that might be changed outside of the program but which is illegal to 
change from within the program.  Such objects are never compile-time 
constants.)

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

That is correct.  I don't know why, other than for historical reasons, 
[static] const objects cannot be used for things like array dimensions 
in C.  Such usage is legal in C++.  And yes, I propose that they gain 
the C++ features in C.

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

What is wrong with constructing a VLA?  Do you know what a VLA actually 
/is/?  It is only legal in C to use a "const int" for the size of an 
array when you are defining a function-local array, and you are correct 
that it will be a VLA.  But the reason the syntax for a VLA and a 
fixed-size array is the same, is that they work in the same way and will 
lead to virtually identical code.  So it does not matter if the 
function-local array is "fixed" size 100 from using a literal (or 
#define, or enum), or VLA with a size given by a const or static const 
that is initialised to 100.

>
> So,  full of difficulties, so I don't understand your objection to my very
> simple proposal, which has few of those problems:

So, no difficulties at all - once you understand some basic C concepts.

>
> o The name created is *not* a variable

Nor is a "const" or "static const".

> o The initialisation value is mandatory, and *must* be evaluable at
> compile-time

The initialisation value for a "const" and "static const" at file scope 
must be compile-time constant, and will default to 0 if omitted. 
Function-local constants can be initialised any way you like (and any 
good compiler will warn you if you forget to initialise it).

> o The value will *never* change, and you can never take its address

The value of a "const" or "static const" will /never/ change.  You can 
take its address if you want, or not if you don't want.

> o It can be used to dimension non-VLA arrays, as switch case-values, and
> can
> be used to construct other such values

That's the only thing missing with C const today - and it should be 
easily remedied by copying the feature from C++.

>
>> (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!

Yes, I can propose an essential language feature (although I am not 
doing so - I am proposing a small but useful addition to an existing 
feature) and say good compilers will implement it well.  Poor compilers 
can easily implement constants as correct but inefficient code.

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

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

#42721

David Brown <david.brown@hesbynett.no> writes:
> On 09/04/14 00:27, BartC wrote:
[...]
>> 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:
>
> A "const" is not a variable - it is a constant object.  So instead of 
> introducing some sort of new type of constant to the language, I would 
> rather take the existing const concept and extend it slightly (as it is 
> in C++) to cover the remaining needs for constants.  That is far 
> simpler, clearer and easier than having a new type of constant - and it 
> already exists in C++.

You're conflating "const" and "constant" in a context where the
distinction is extremely relevant.

It's not entirely clear what the word "variable" should mean in C.  The
standard doesn't use the term; instead it uses "object".  Is a
const-qualified object a "variable"?  You could probably get three
different answers from three different people here; mine is that I avoid
using the word "variable" when there's any chance of confusion.

"const" in C simply means "read-only".  "Constant" refers to something
that can (and must) be evaluated at compile time, as in "integer
constant" (what some languages call an "integer literal") or a "constant
expression" (an expression that can be used as if it were a literal).

Remember that

    const int r = rand();

is perfectly valid (at block scope); r is const (read-only), but clearly
its value cannot be determined until run time.

[...]

> "const" is not a hint to the compiler about variables - it is a specific 
> direction that this object will be constant, and will never be changed. 

It's a direction that the object is *read-only*.

[...]

> I think you are mixing up the use of "const" in definitions such as 
> "static const int xyz = 123;", and its use in function arguments 
> (especially for pointers), such as "size_t strlen(const char* s)".

They're essentially the same thing.  In both cases, the "const" asserts
that the relevant object (xyz or *s) will not be modified.  In both
case, the compiler can optimize based on that assertion.  It just
happens to be able to optimize better when it can see what the initial
(and only) value is.

What the C++ rule does is take an object that's defined to be read-only
and make its name a compile-time constant.  IMHO it's a bit of a hack,
but it's a useful one that I'd like to see adopted in C.

[...]

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

#42724

On 09/04/14 08:05, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 09/04/14 00:27, BartC wrote:
> [...]
>>> 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:
>>
>> A "const" is not a variable - it is a constant object.  So instead of 
>> introducing some sort of new type of constant to the language, I would 
>> rather take the existing const concept and extend it slightly (as it is 
>> in C++) to cover the remaining needs for constants.  That is far 
>> simpler, clearer and easier than having a new type of constant - and it 
>> already exists in C++.
> 
> You're conflating "const" and "constant" in a context where the
> distinction is extremely relevant.

Perhaps - I certainly agree that we must be as clear as possible here.

I think one other aspect that we should make clear is when we are
talking about file level objects, and when we are talking about function
local objects.  There is a significant difference in what can and cannot
be done with "const" in these contexts, and I think that is adding to
Bart's confusion.

> 
> It's not entirely clear what the word "variable" should mean in C.  The
> standard doesn't use the term; instead it uses "object".  Is a
> const-qualified object a "variable"?  You could probably get three
> different answers from three different people here; mine is that I avoid
> using the word "variable" when there's any chance of confusion.

I view "variable" to mean something that can legally be changed after
its creation and initialisation.  Thus any object defined as "const"
will be a constant object, and not a variable.

> 
> "const" in C simply means "read-only".  "Constant" refers to something
> that can (and must) be evaluated at compile time, as in "integer
> constant" (what some languages call an "integer literal") or a "constant
> expression" (an expression that can be used as if it were a literal).

Yes, that's true (AFAIUI).  But I think we must carefully distinguish
between file scope const and block scope const, as the rules and effects
are different.

Because a file scope initialised "const" must be initialised by a
"constant expression", and it is read only, the compiler knows its value
at any time - and therefore any use of its value can be replaced by the
compile-time constant expression.  The exceptions here are for things
like array dimensions, which C disallows even though the compiler is
guaranteed the required knowledge to generate the code, and C++ can use
the const objects in such circumstances.

At block level (local to a function), const objects become constant
after their initialisation - you cannot legally change them.  But
(unless they are "static const") they do not necessarily have
compile-time constant values, and are therefore named read-only copies
of their initialisers.


> 
> Remember that
> 
>     const int r = rand();
> 
> is perfectly valid (at block scope); r is const (read-only), but clearly
> its value cannot be determined until run time.

Correct - but after its initialisation, and throughout its lifetime, "r"
is constant.

I believe Bart has been thinking mainly of file scope "const", but has
mixed in block scope differences too.  I wish I had thought of that
earlier - I think we could have had a clearer and simpler discussion if
the distinction had been made clear.

> 
> [...]
> 
>> "const" is not a hint to the compiler about variables - it is a specific 
>> direction that this object will be constant, and will never be changed. 
> 
> It's a direction that the object is *read-only*.
> 
> [...]
> 
>> I think you are mixing up the use of "const" in definitions such as 
>> "static const int xyz = 123;", and its use in function arguments 
>> (especially for pointers), such as "size_t strlen(const char* s)".
> 
> They're essentially the same thing.  In both cases, the "const" asserts
> that the relevant object (xyz or *s) will not be modified.  In both
> case, the compiler can optimize based on that assertion.  It just
> happens to be able to optimize better when it can see what the initial
> (and only) value is.

While that is true, the two uses of "const" here have different effects
because of the different levels of knowledge that the compiler has.  I
am trying to concentrate on the effects, implementations and practical
features (and limitations) of "const", rather than the language details.

> 
> What the C++ rule does is take an object that's defined to be read-only
> and make its name a compile-time constant.  IMHO it's a bit of a hack,
> but it's a useful one that I'd like to see adopted in C.
> 

Well, at least we agree on what we want in the end!

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

#42734

David Brown <david.brown@hesbynett.no> writes:
> On 09/04/14 08:05, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 09/04/14 00:27, BartC wrote:
>> [...]
>>>> 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:
>>>
>>> A "const" is not a variable - it is a constant object.  So instead of 
>>> introducing some sort of new type of constant to the language, I would 
>>> rather take the existing const concept and extend it slightly (as it is 
>>> in C++) to cover the remaining needs for constants.  That is far 
>>> simpler, clearer and easier than having a new type of constant - and it 
>>> already exists in C++.
>> 
>> You're conflating "const" and "constant" in a context where the
>> distinction is extremely relevant.
>
> Perhaps - I certainly agree that we must be as clear as possible here.

[...]

>> It's not entirely clear what the word "variable" should mean in C.  The
>> standard doesn't use the term; instead it uses "object".  Is a
>> const-qualified object a "variable"?  You could probably get three
>> different answers from three different people here; mine is that I avoid
>> using the word "variable" when there's any chance of confusion.
>
> I view "variable" to mean something that can legally be changed after
> its creation and initialisation.

That's not an unreasonable definition -- but it's still not entirely
unambiguous.  Someone might refer to a const-qualified object as a
"variable".  And a member of a non-const struct object is an object that
can be modified, but is it a variable or just part of one?  What about
an array element?  What about an object allocated by malloc()?

The words "const", "constant", and "object", have well-defined meanings
in C.  "Variable" doesn't.  I suggest just avoiding that word, at least
in this discussion.

>                                   Thus any object defined as "const"
> will be a constant object, and not a variable.

Um, no, it will be a *read-only* object.

>> "const" in C simply means "read-only".  "Constant" refers to something
>> that can (and must) be evaluated at compile time, as in "integer
>> constant" (what some languages call an "integer literal") or a "constant
>> expression" (an expression that can be used as if it were a literal).
>
> Yes, that's true (AFAIUI).  But I think we must carefully distinguish
> between file scope const and block scope const, as the rules and effects
> are different.
>
> Because a file scope initialised "const" must be initialised by a
> "constant expression", and it is read only, the compiler knows its value
> at any time - and therefore any use of its value can be replaced by the
> compile-time constant expression.  The exceptions here are for things
> like array dimensions, which C disallows even though the compiler is
> guaranteed the required knowledge to generate the code, and C++ can use
> the const objects in such circumstances.

There's not that much difference.  The name of a const-qualified object
is not a constant expression, regardless of where it's defined.
Optimizing compilers can evaluate any expression at compile time if they
have enough information.  A file-scope object might be defined in one
translation unit and declared in another; the compiler might see a
declaration "const int foo;" and have no way of knowing the value.

A compiler can replace:

    int n = 42;
    printf("n = %d\n", n);

by the equivalent of:

    puts("n = 42");

even though there's no "const" on the declaration.

> At block level (local to a function), const objects become constant
> after their initialisation - you cannot legally change them.  But
> (unless they are "static const") they do not necessarily have
> compile-time constant values, and are therefore named read-only copies
> of their initialisers.

The same is true of file-scope const objects.  Such an object has an
address, and the value of the initializer is stored at that address.
The ability to refer to that value without necessarily loading it from
memory is merely an optimization.

>> Remember that
>> 
>>     const int r = rand();
>> 
>> is perfectly valid (at block scope); r is const (read-only), but clearly
>> its value cannot be determined until run time.
>
> Correct - but after its initialisation, and throughout its lifetime, "r"
> is constant.

No, it's read-only, not constant.  In C, the word "constant"
refers to something that can be evaluated at compile time.  We can
reasonably discuss this only if we use words in ways that are
consistent with with the way they're defined by the C standard.

[...]

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

#42749

Keith Thompson <kst-u@mib.org> writes:

> David Brown <david.brown@hesbynett.no> writes:
>> On 09/04/14 08:05, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 09/04/14 00:27, BartC wrote:
>>> [...]
>>>>> 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:
>>>>
>>>> A "const" is not a variable - it is a constant object.  So instead of 
>>>> introducing some sort of new type of constant to the language, I would 
>>>> rather take the existing const concept and extend it slightly (as it is 
>>>> in C++) to cover the remaining needs for constants.  That is far 
>>>> simpler, clearer and easier than having a new type of constant - and it 
>>>> already exists in C++.
>>> 
>>> You're conflating "const" and "constant" in a context where the
>>> distinction is extremely relevant.
>>
>> Perhaps - I certainly agree that we must be as clear as possible here.
>
> [...]
>
>>> It's not entirely clear what the word "variable" should mean in C.  The
>>> standard doesn't use the term; instead it uses "object".  Is a
>>> const-qualified object a "variable"?  You could probably get three
>>> different answers from three different people here; mine is that I avoid
>>> using the word "variable" when there's any chance of confusion.
>>
>> I view "variable" to mean something that can legally be changed after
>> its creation and initialisation.


>
> That's not an unreasonable definition -- but it's still not entirely
> unambiguous.  Someone might refer to a const-qualified object as a
> "variable".  And a member of a non-const struct object is an object that
> can be modified, but is it a variable or just part of one?  What about
> an array element?  What about an object allocated by malloc()?
>
> The words "const", "constant", and "object", have well-defined meanings
> in C.  "Variable" doesn't.  I suggest just avoiding that word, at least
> in this discussion.

Without the application of "const" in any shape or form it has a very
well defined meaning. The clue is in what "variable" means and in
addition to that real humans are capable of understanding what someone
means when they say "a constant int" for example.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

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

#42751

On Thursday, April 10, 2014 9:08:29 AM UTC+1, Richard wrote:
> Keith Thompson <kst-u@mib.org> writes:
> 
> Without the application of "const" in any shape or form it has a very
> well defined meaning. The clue is in what "variable" means and in
> addition to that real humans are capable of understanding what someone
> means when they say "a constant int" for example.
> 
But programmers also say "that variable is a constant".
It's referenced by a symbol rather than a raw value, but the value doesn't change during the lifetime of
the program. However it might change if the program is compiled with different settings.

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

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

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

csiph-web