const is not const

S

Szabolcs Nagy

is there a reason why const is not compile-time constant?

the usual example, where it'd be nice is array declaration:
const int N = 4;
float arr[N]

or one may want to use an enum for indices:
enum index {a,b,c,d,N};
float arr[N]

of course both are wrong and the solution is an ugly define
#define N 5

now i found another example where it would be nice to be able to
define compile-time constants:
const char * const a[] = {"a", "bb", "ccc"};
const char *b[] = {a[1], a[0], a[2], a[2]};

this is an error because a is not constant, which is a problem
since i don't know any elegant way to define b[] (let's say a and b
are globals in a one module c code)

(same problem with struct initialization)

any ideas?
 
J

jacob navia

Szabolcs said:
is there a reason why const is not compile-time constant?

the usual example, where it'd be nice is array declaration:
const int N = 4;
float arr[N]

or one may want to use an enum for indices:
enum index {a,b,c,d,N};
float arr[N]

of course both are wrong and the solution is an ugly define
#define N 5

The lcc-win32 C compiler accepts this as an extension.

I am not sure I got all the cases right though. The above example
compiles without problems. More problematic are the cases where the
constant "variable" would be used in a switch for instance.
now i found another example where it would be nice to be able to
define compile-time constants:
const char * const a[] = {"a", "bb", "ccc"};
const char *b[] = {a[1], a[0], a[2], a[2]};

this is an error because a is not constant, which is a problem
since i don't know any elegant way to define b[] (let's say a and b
are globals in a one module c code)

(same problem with struct initialization)

any ideas?




const char * const a[] = {"a", "bb", "ccc"};
const char **b[] = {&a[1], &a[0], &a[2], &a[2]};

That works but is ugly...
 
A

Andrey Tarasevich

Szabolcs said:
is there a reason why const is not compile-time constant?

the usual example, where it'd be nice is array declaration:
const int N = 4;
float arr[N]

It is OK in C99, but not OK in C89/90.
or one may want to use an enum for indices:
enum index {a,b,c,d,N};
float arr[N]

of course both are wrong and the solution is an ugly define
#define N 5

The version with enum is OK even in the "original" ANSI C (C89/90). I don't know
why you call it "wrong".
now i found another example where it would be nice to be able to
define compile-time constants:
const char * const a[] = {"a", "bb", "ccc"};
const char *b[] = {a[1], a[0], a[2], a[2]};

this is an error because a is not constant, which is a problem
since i don't know any elegant way to define b[] (let's say a and b
are globals in a one module c code)

(same problem with struct initialization)


Also OK in C99 for non-static objects.
any ideas?

Well, it was probably done this way just to make things a bit simpler in the
original revisions of the language. Simpler to the compiler implementers that is.
 
E

Eric Sosman

Szabolcs Nagy wrote On 11/07/07 09:01,:
is there a reason why const is not compile-time constant?

If someone answered "No," would you believe it?
the usual example, where it'd be nice is array declaration:
const int N = 4;
float arr[N]

Think about this one for a few moments:

extern const int N; /* defined elsewhere */
float arr[N]; /* ... but with what value? */
or one may want to use an enum for indices:
enum index {a,b,c,d,N};
float arr[N]

This is fine (after adding a semicolon).
of course both are wrong

No, only the first fails.
and the solution is an ugly define
#define N 5

now i found another example where it would be nice to be able to
define compile-time constants:
const char * const a[] = {"a", "bb", "ccc"};
const char *b[] = {a[1], a[0], a[2], a[2]};

this is an error because a is not constant, which is a problem
since i don't know any elegant way to define b[] (let's say a and b
are globals in a one module c code)


Do you prefer "elegant" to "effective?" If so,
do not use

const char astring[] = "a";
const char bstring[] = "bb";
const char cstring[] = "ccc";
const char * const a[] = { astring, bstring, cstring };
const char * b[] = {
bstring, astring, cstring, cstring };
(same problem with struct initialization)

Same solution, unless it fails to meet your
standards of elegance.
any ideas?

Learn how your tools work. Then use them if they work
well enough for your purposes, or abandon them and choose
other tools if not. Don't waste time whining that your
Phillips screwdriver doesn't turn Torx bolts.
 
J

jacob navia

Andrey said:
Szabolcs said:
is there a reason why const is not compile-time constant?

the usual example, where it'd be nice is array declaration:
const int N = 4;
float arr[N]

It is OK in C99, but not OK in C89/90.

Only within a function scope. Not at the global level.
 
K

Keith Thompson

Szabolcs Nagy said:
is there a reason why const is not compile-time constant?

Historical reasons. The "const" keyword didn't originally exist in C.
It was added in a way that tried not to break existing code.

Really "const" doesn't mean "constant"; it means "read-only".

[...]
or one may want to use an enum for indices:
enum index {a,b,c,d,N};
float arr[N]

of course both are wrong and the solution is an ugly define
#define N 5

An enum is actually a common way to declare a true constant:

enum { N = 5 };

This is arguably an abuse of "enum", since that's not really what it
was intended for, but it's sufficiently useful that I don't mind that.
Also, it's limited to declaring constants of type int.

[...]
 
S

Szabolcs Nagy

Eric said:
Szabolcs Nagy wrote On 11/07/07 09:01,:
is there a reason why const is not compile-time constant?

If someone answered "No," would you believe it? sure

Think about this one for a few moments:

extern const int N; /* defined elsewhere */
float arr[N]; /* ... but with what value? */
ok so it's extern's fault (damn you extern)
or one may want to use an enum for indices:
enum index {a,b,c,d,N};
float arr[N]

This is fine (after adding a semicolon).
sorry, for some reason i thought enum is not ok there and i was lazy
to try it out..
this is an error because a is not constant, which is a problem
since i don't know any elegant way to define b[] (let's say a and b
are globals in a one module c code)


Do you prefer "elegant" to "effective?" If so,
do not use

const char astring[] = "a";
const char bstring[] = "bb";
const char cstring[] = "ccc";
const char * const a[] = { astring, bstring, cstring };
const char * b[] = {
bstring, astring, cstring, cstring };

well, i can live with it but the original idea was so much nicer

thanks for the answers
 
C

CBFalconer

Eric said:
.... snip ...

Learn how your tools work. Then use them if they work well enough
for your purposes, or abandon them and choose other tools if not.
Don't waste time whining that your Phillips screwdriver doesn't
turn Torx bolts.

Well, they might if you heat the bits up to a dull red, hammer them
into a Torx head, remove and heat-treat. :) By then it probably
won't handle Phillips heads, though. :)
 
E

Eric Sosman

CBFalconer said:
Eric Sosman wrote:
... snip ...

Well, they might if you heat the bits up to a dull red, hammer them
into a Torx head, remove and heat-treat. :) By then it probably
won't handle Phillips heads, though. :)

Damn, you're right! I've seen other programmers do that;
worse, I've done it myself ...

"When your favorite tool is a hammer, every problem looks
like a nail."
 
P

Philip Potter

Eric said:
Damn, you're right! I've seen other programmers do that;
worse, I've done it myself ...

"When your favorite tool is a hammer, every problem looks
like a nail."

"When your favourite tool is a Java-shaped hammer, every problem looks
like a screw..."


Phil


PS I don't really dislike Java, but it's not as fun to poke fun at
genuinely useless languages like COBOL...
 
O

Old Wolf

Szabolcs Nagy wrote On 11/07/07 09:01,:
the usual example, where it'd be nice is array declaration:
const int N = 4;
float arr[N]

Think about this one for a few moments:

extern const int N; /* defined elsewhere */
float arr[N]; /* ... but with what value? */

Well, initialized consts would be constant expressions,
and uninitialized ones wouldn't be. (NB. You might need
to language lawyer that sentence a bit to make it rigorous).

I don't see a great problem here; 'that other language'
follows this approach.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,012
Latest member
RoxanneDzm

Latest Threads

Top