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.

 

[arnuld]

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 <enum> rather than #define. K&R2 use #define all the time.
should I change my style ?

 

[Chris Dollin]

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

 

[Bartc]

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.

 

[Keith Thompson]

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

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

 

[Ian Collins]

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

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.

 

[arnuld]

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

 

[Ian Collins]

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.

 

[arnuld]

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 ?

 

[Barry Schwarz]

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]

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

 

[Ian Collins]

including a 'static' (classwide) data member


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


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?

 

[pereges]

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.

 

[santosh]

I have always found that using const is only a choice rather than a
necessity.

Yes. Most things in life are just choices.

But this is just my opinion, I'm sure the experts here will
differ.

The point of const (in C) is to help the compiler to do more checks on
your source. Consider this trivial program:

#include <stdio.h>

int main(void) {

long double pi = 3.1415926535897932384626433832795029L;
long double r;

puts("Enter radius of circle:");
scanf("%Lf", &r);
printf("Area of the circle is: %Lf\n", pi * (r * r));
return 0;
}

Now imagine this as a part of a much larger program or function.
Obviously 'pi' holds the value of a constant and should not be changed.
However if some other code in your program happens to modify 'pi' your
compiler will silently accept the modification and your program will
start giving you wrong or inaccurate results. This is where
qualifying 'pi' with const will start paying off. Now anywhere a direct
change is made to 'pi' the compiler will give you a diagnostic warning
you of it, so you can correct the code and prevent undefined behaviour.

As someone else said, const may appear rather meritless for small,
one-man programs, but it will start paying dividends when the program
grows larger and is developed by a team, even in spite the quirkiness
of C's const.

PS. You can still attempt to write to a const object and evade compiler
warnings by writing through a pointer, but that's far less likely to
happen in real code than direct in-advertant modification.

 

[David Thompson]

Which feature?

The feature of C++ that Keith described and I slightly corrected, that
a const variable(!) of integer or enum type initialized by a constant
expression is acceptable in a constant expression. (And the which, or
something like it, the upthread discussion suggested for C.)

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