Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: faster than c |
| Date | 2015-04-23 13:41 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <mhaln0$nek$1@dont-email.me> (permalink) |
| References | (18 earlier) <871tjfq21s.fsf@kst-u.example.com> <mh16t9$6fb$1@dont-email.me> <kfnsibst6qv.fsf@x-alumni2.alumni.caltech.edu> <mh97oh$gca$1@dont-email.me> <b0692b7a-f0f2-47a0-8280-d6373f8d01c1@googlegroups.com> |
On 23/04/15 09:25, Öö Tiib wrote:
> On Thursday, 23 April 2015 01:37:09 UTC+3, David Brown wrote:
>> On 22/04/15 19:25, Tim Rentsch wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> [snip]
>>>>
>>>> I think basically I would like to be able to use a "const int"
>>>> defined object anywhere I can also use an "enum" constant or a
>>>> #define'd integer constant.
>>>
>>> I don't think you mean literally what you said.
>>>
>>
>> I should have qualified this to mean a const int with the definition
>> known to the compiler at the time - it could not work with externally
>> defined const int's.
>>
>> (In C++, a "const" definition without an extern declaration is viewed as
>> "static", which I think is a nice feature.)
>>
>> I want to be able to used const int's like this:
>>
>> const int bufferSize = 1024;
>> char buffer[bufferSize];
>>
>> const int A = 1;
>> const int B = 2;
>
> The 'const' declares intent of developer to not modify variable
> after declaration regardless if the value is known or not compile time.
>
> const int B = rand() % 42;
That is not valid for global (file scope or function static) data. I
should have said I was referring only to global constants (I had the
feeling I had missed something important).
For static lifetime constant data, you do need to have a compile-time
known initialiser.
>
>> void foo(int x) {
>> switch (x) {
>> case A : ...
>> break;
>> case B : ...
>> break;
>> }
>> }
>
> Lets try to take step further to see why it might be not good idea?
>
> Adding 'static' instead of 'const' to the variables 'bufferSize',
> 'A' and 'B', initializing these with constant expressions and not
> changing the values or passing the addresses of those anywhere will
> cause optimizing compilers to detect that those have compile-time
> known values all time. Such compiler will replace all usages with
> constants in produced binary despite the variables are declared
> mutable.
The variables are not mutable if they are "const". But yes, if they are
merely declared "static" but not "const", and they cannot escape and be
legally changed elsewhere, then the compiler can optimise by using the
constant value directly.
>
> So technically the language rules could be further relaxed to allow
> compiler to complain about 'case A:' only when it can't prove that 'A'
> is constant compile-time. However that would *require* such deep
> optimizer-level analysis from C compilers.
Agreed - it could be theoretically possible, but it would complicate the
language and the implementation because a "static int" could sometimes
be used as a label, sometimes not. It would be much easier to say that
it can be used as a label if and only if it is a "const" with a constant
initialiser (or perhaps only if it is a static constant, and therefore
/must/ have a constant initialiser).
>
>> In C, an identifier declared as a "const" is not a constant expression,
>> and can't be used as one - even though any attempt to modify it is
>> undefined behaviour. In C++, such identifiers /are/ constant
>> expressions and can be used in this way.
>
> I trust that C++ standardization committee have also realized that
> context-dependent dual meaning of 'const' ('immutable value' versus
> 'constant expression') was mistake. Otherwise why 'constexpr'
> was added to C++11?
>
As Ian said, constexpr covers other things and is "even more constant".
I am sure that the committee understand that the meaning of "const" can
be significantly different in different contexts, but I doubt if they
view it as a "mistake". (Does the C standards committee call the
multiple uses of "static" a mistake?) But even if you view it as a
mistake, it does not mean there is any good reason not to treat global
const objects (or local const objects with compile-time-constant
initialisers) as true constants, and letting you use them for buffer
sizes, etc.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 15:23 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-16 10:02 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 10:58 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 08:26 +1200
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-17 13:51 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 11:24 +1200
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-18 12:11 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:29 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-18 13:08 +0200
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 23:33 +1200
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-18 14:19 +0200
Re: faster than c raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:43 +0000
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-19 13:46 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-19 23:33 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 10:25 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-23 00:37 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 00:25 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-23 19:36 +1200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 09:10 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 09:19 +0200
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-23 13:41 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 10:36 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 09:25 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-24 04:45 -0700
Re: faster than c Bartc <bc@freeuk.com> - 2015-04-24 13:36 +0100
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-27 06:16 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 14:44 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:10 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:03 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 16:22 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:18 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 16:58 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 09:21 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-20 12:51 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 10:47 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 17:20 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:51 -0700
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-17 23:10 +0000
Re: faster than c raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:46 +0000
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:56 -0700
csiph-web