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]

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
es*****@ieee-dot-org.invalid

[arnuld]

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]

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]

"Chris Dollin" <ch**********@h p.comwrote in message
news:ft******** **@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]

arnuld <ar*****@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) <ks***@mib.or g>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"Bartc" <[e-mail] rites:

"Chris Dollin" <ch**********@h p.comwrote in message
news:ft******** **@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) <ks***@mib.or g>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

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]

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]

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.