const is not const

[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[i] 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?

[jacob navia]

Szabolcs Nagy wrote:

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[i] 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...

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Andrey Tarasevich]

Szabolcs Nagy wrote:

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[i] 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.

--
Best regards,
Andrey Tarasevich

[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[i] 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.

--
Er*********@sun .com

[jacob navia]

Andrey Tarasevich wrote:

Szabolcs Nagy wrote:

>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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Keith Thompson]

Szabolcs Nagy <ns*******@gmai l.comwrites:

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.

[...]

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Szabolcs Nagy]

Eric Sosman wrote:

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[i] 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

[CBFalconer]

Eric Sosman wrote:

>

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

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home .att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Eric Sosman]

CBFalconer wrote:

Eric Sosman wrote:
... 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. :-)

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

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Philip Potter]

Eric Sosman wrote:

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

--
Philip Potter pgp <atdoc.ic.ac. uk