const problem

[arnuld]

I have declared an int as const but compiler still says that it is not a
const:

include <stdio.h>
#include <stdlib.h>


int main()
{
const int MAXSIZE = 100;
char ac[MAXSIZE] = "abc";
char *pc;

for( pc = ac; *pc != '\0'; ++pc )
{
printf("%c\n", *pc);
}


return EXIT_SUCCESS;
}

============ OUTPUT ==============
[arnuld@raj C]$ gcc -ansi -pedantic -Wall -Wextra test.c
test.c: In function `main':
test.c:8: warning: ISO C90 forbids variable-size array `ac'
test.c:8: error: variable-sized object may not be initialized
[arnuld@raj C]$



K&R2 section 2.4, says:

"For an array, the const qualifier says that elements will not be
altered."



but I can't even compile the program.




[arnuld@raj C]$ gcc --version
gcc (GCC) 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.



--

http://lispmachine.wordpress.com/

Please remove capital 'V's when you reply to me via e-mail.

[Eric Sosman]

Re: const problem

arnuld wrote:

I have declared an int as const but compiler still says that it is not a
const:
[...]

This is Question 11.8 in the comp.lang.c Frequently
Asked Questions (FAQ) list, <http://www.c-faq.com/>.

--
Eric Sosman
esosman@ieee-dot-org.invalid

[arnuld]

Re: const problem

On Mon, 14 Apr 2008 18:12:37 +0500, arnuld wrote:

I have declared an int as const but compiler still says that it is not a
const:

...[SNIP]...

K&R2 section 2.4, says:
>
"For an array, the const qualifier says that elements will not be
altered."

but I can't even compile the program.

I got it here: http://c-faq.com/ansi/constasconst.html


but I really don't understand the FAQ statement:


" ..... an object so qualified is a run-time object which cannot
(normally) be assigned to. The value of a const-qualified object is
therefore not a constant expression in the full sense of the term,..."


It is read-only at run-time ? I don't understand, can someone please
explain ?



" ........When you need a true compile-time constant,
use a preprocessor #define (or perhaps an enum)"

I prefer using <enumrather than #define. K&R2 use #define all the time.
should I change my style ?




--

http://lispmachine.wordpress.com/

Please remove capital 'V's when you reply to me via e-mail.

[Chris Dollin]

Re: const problem

arnuld wrote:

I have declared an int as const but compiler still says that it is not a
const:

In C, variables declared const are not constant-expressions.

They just aren't; there are probably good-enough reasons.

(For an int const, you can use an enum.)

--
"What would that matter, if it made a good book?" /Gaudy Night/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[Bartc]

Re: const problem

"Chris Dollin" <chris.dollin@h p.comwrote in message
news:ftvmd8$dph $1@news-pa1.hpl.hp.com. ..

arnuld wrote:
>

>I have declared an int as const but compiler still says that it is not a
>const:

>
In C, variables declared const are not constant-expressions.
>
They just aren't; there are probably good-enough reasons.
>
(For an int const, you can use an enum.)

This keeps coming up. Wouldn't it be better to just fix const so that it
works like const in Pascal for example?

I think existing const (==readonly attribute) must be left as it is because
of code that uses pointers to them. Proper consts wouldn't allow pointers to
them at all. So an alternative is needed.

Using #define is not really satisfactory (scope problems and so on). And
using enum is a workaround.

--
Bart

[Keith Thompson]

Re: const problem

arnuld <arnVuld@ippiVm ail.comwrites:

>On Mon, 14 Apr 2008 18:12:37 +0500, arnuld wrote:

>

>I have declared an int as const but compiler still says that it is not a
>const:

>

>...[SNIP]...

>

>K&R2 section 2.4, says:
>>
> "For an array, the const qualifier says that elements will not be
> altered."

>

>but I can't even compile the program.

>
I got it here: http://c-faq.com/ansi/constasconst.html
>
but I really don't understand the FAQ statement:
>
" ..... an object so qualified is a run-time object which cannot
(normally) be assigned to. The value of a const-qualified object is
therefore not a constant expression in the full sense of the term,..."
>
It is read-only at run-time ? I don't understand, can someone please
explain ?

[...]

C's "const" doesn't meant "constant"; it means "read-only", which is a
weaker condition. It merely means that you're not allowed to modify
the object after it's been initialized.

In the absence of VLAs (variable-length arrays, a C99-specific
feature), C90 requires a *constant* expression as an array dimension,
such as

int arr[10];

This:

const int not_a_constant = 10;

doesn't create a constant expression, any more than this does:

const int not_a_constant_ either = rand();

The fact that one of these is initialized with a constant expression
makes no real difference, at least as far as the language is
concerned. (The language *could* have been specified so that a const
declaration creates an actual constant if the initializer is a
constant expression, but it wasn't.)

However, the compiler is still allowed to treat ``not_a_constan t'' as
constant *internally*, replacing any reference to it with the value
10. It just can't be used in a context that requires an actual
constant expression.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Re: const problem

"Bartc" <bc@freeuk.comw rites:

"Chris Dollin" <chris.dollin@h p.comwrote in message
news:ftvmd8$dph $1@news-pa1.hpl.hp.com. ..

>arnuld wrote:
>>

>>I have declared an int as const but compiler still says that it is not a
>>const:

>>
>In C, variables declared const are not constant-expressions.
>>
>They just aren't; there are probably good-enough reasons.
>>
>(For an int const, you can use an enum.)

>
This keeps coming up. Wouldn't it be better to just fix const so that it
works like const in Pascal for example?

In theory, yes.

I think existing const (==readonly attribute) must be left as it is because
of code that uses pointers to them. Proper consts wouldn't allow pointers to
them at all. So an alternative is needed.

I don't think pointers would be a problem. For example, C++ did
change the semantics of const. In essence, if an object is declared
"const" and its initializer is a constant expression, then any
reference to the object is a constant expression. This allows things
like this:

const int n = 5;
switch (some_expr) {
case n: /* not allowed in C */
...*/
...
}

while still permitting non-constant const declarations:

const int const_but_not_c onstant r = rand();

One problem with this idea is that, even if it were added in the next
revision of the C standard, it would be many years before you could
count on widespread compiler support. That's not a reason to reject
the idea, but you won't be able to use it any time soon (unless you
switch to C++).

It's also possible that it could break some existing code in ways I
haven't thought of.

Using #define is not really satisfactory (scope problems and so on). And
using enum is a workaround.

Agreed. The enum trick only works for constants of type int, and it's
really not what the "enum" construct was meant for. (Nevertheless,
it's a neat trick, and I wouldn't hesitate to use it.)

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[arnuld]

Re: const problem

On Mon, 14 Apr 2008 08:47:59 -0700, Keith Thompson wrote:

C's "const" doesn't meant "constant"; it means "read-only", which is a
weaker condition. It merely means that you're not allowed to modify
the object after it's been initialized.

object is read only and can't be modified once initialized but then it is
not const which means it is writable :-\

However, the compiler is still allowed to treat ``not_a_constan t'' as
constant *internally*, replacing any reference to it with the value 10.

I am pretty much confused by these statements. It looks like the
C has the same complexity of C++.

It just can't be used in a context that requires an actual constant
expression.

okay, I, finally, think that it is much better idea to not to use const at
all. enum is fine for int constants and #define for everything else.




--

http://lispmachine.wordpress.com/

Please remove capital 'V's when you reply to me via e-mail.

[Ian Collins]

Re: const problem

arnuld wrote:

>On Mon, 14 Apr 2008 08:47:59 -0700, Keith Thompson wrote:

>

>C's "const" doesn't meant "constant"; it means "read-only", which is a
>weaker condition. It merely means that you're not allowed to modify
>the object after it's been initialized.

>
object is read only and can't be modified once initialized but then it is
not const which means it is writable :-\
>

It's not const at *compile* time, but it is at *run* time. Which is why
you can't use a const for an array size (which requires a compile time
constant).

>
>

>However, the compiler is still allowed to treat ``not_a_constan t'' as
>constant *internally*, replacing any reference to it with the value 10.

>
I am pretty much confused by these statements. It looks like the
C has the same complexity of C++.
>

With respect to const, C++ actually simplifies the rules. A const is a
compile and run time constant.

It is more that a little daft that a C compiler can replace a const int
with its constant value (at compile time), but can't use that value
(which it knows) where a compile time constant is required.

--
Ian Collins.

[arnuld]

Re: const problem

On Tue, 15 Apr 2008 17:12:53 +1200, Ian Collins wrote:

It's not const at *compile* time, but it is at *run* time. Which is why
you can't use a const for an array size (which requires a compile time
constant).

This explanation is simple enough to understand :)

With respect to const, C++ actually simplifies the rules. A const is a
compile and run time constant.

and when I 1st learned C++, I was blown away by the complexity of C++
const mechanism. Now it is not so, it was at the beginning.

It is more that a little daft that a C compiler can replace a const int
with its constant value (at compile time), but can't use that value
(which it knows) where a compile time constant is required.

so, in case of #define or enum:

a C compiler can replace a #define/enum with its value
(at compile time), and can use that value (which
it knows) where a compile time constant is required.


right ?



--

http://lispmachine.wordpress.com/

Please remove capital 'V's when you reply to me via e-mail.

[Ian Collins]

Re: const problem

arnuld wrote:

>
so, in case of #define or enum:
>
a C compiler can replace a #define/enum with its value
(at compile time), and can use that value (which
it knows) where a compile time constant is required.
>
>
right ?
>

Right.

--
Ian Collins.

[Barry Schwarz]

Re: const problem

On Tue, 15 Apr 2008 10:44:31 +0500, arnuld <arnVuld@ippiVm ail.com>
wrote:


snip

>so, in case of #define or enum:
>
a C compiler can replace a #define/enum with its value
(at compile time), and can use that value (which
it knows) where a compile time constant is required.

As far as #define is concerned, after the preprocessor gets done
substituting everything, the compiler will never see the #define name,
only the substituted value. Therefore, the compiler *must* use the
substituted value. If the substituted token is a self defining term,
then it can be used where a compile time constant is required.


Remove del for email

[David Thompson]

Re: const problem

On Mon, 14 Apr 2008 09:04:49 -0700, Keith Thompson <kst-u@mib.org>
wrote:
<snip>

I don't think pointers would be a problem. For example, C++ did
change the semantics of const. In essence, if an object is declared

including a 'static' (classwide) data member

"const" and its initializer is a constant expression, then any

and of an integer or enumeration type (in C++ enum types are distinct,
not just aliases for integer types as they are in C)

reference to the object is a constant expression. This allows <snip>

But most of the places C (or C++) requires a constant expression do
require integer (constant expression), including the example you gave
of a case label, and this feature is enough for those.

- formerly david.thompson1 || achar(64) || worldnet.att.ne t

[Ian Collins]

Re: const problem

David Thompson wrote:

On Mon, 14 Apr 2008 09:04:49 -0700, Keith Thompson <kst-u@mib.org>
wrote:
<snip>

>I don't think pointers would be a problem. For example, C++ did
>change the semantics of const. In essence, if an object is declared

>
including a 'static' (classwide) data member
>

>"const" and its initializer is a constant expression, then any

>
and of an integer or enumeration type (in C++ enum types are distinct,
not just aliases for integer types as they are in C)
>

>reference to the object is a constant expression. This allows <snip>

>
But most of the places C (or C++) requires a constant expression do
require integer (constant expression), including the example you gave
of a case label, and this feature is enough for those.
>

Which feature?

--
Ian Collins.

[pereges]

Re: const problem

I have always found that using const is only a choice rather than a
necessity. But this is just my opinion, I'm sure the experts here will
differ.