const is not const

Discussion in 'C Programming' started by Szabolcs Nagy, Nov 7, 2007.

  1. 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?
     
    Szabolcs Nagy, Nov 7, 2007
    #1
    1. Advertising

  2. Szabolcs  Nagy

    jacob navia Guest

    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 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
     
    jacob navia, Nov 7, 2007
    #2
    1. Advertising

  3. 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 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
     
    Andrey Tarasevich, Nov 7, 2007
    #3
  4. Szabolcs  Nagy

    Eric Sosman Guest

    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.

    --
     
    Eric Sosman, Nov 7, 2007
    #4
  5. Szabolcs  Nagy

    jacob navia Guest

    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
     
    jacob navia, Nov 7, 2007
    #5
  6. Szabolcs Nagy <> writes:
    > 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_Keith) <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"
     
    Keith Thompson, Nov 7, 2007
    #6
  7. 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 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
     
    Szabolcs Nagy, Nov 7, 2007
    #7
  8. Szabolcs  Nagy

    CBFalconer Guest

    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
     
    CBFalconer, Nov 8, 2007
    #8
  9. Szabolcs  Nagy

    Eric Sosman Guest

    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
    lid
     
    Eric Sosman, Nov 8, 2007
    #9
  10. 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 <at> doc.ic.ac.uk
     
    Philip Potter, Nov 8, 2007
    #10
  11. Szabolcs  Nagy

    Old Wolf Guest

    On Nov 8, 4:36 am, Eric Sosman <> wrote:
    > 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.
     
    Old Wolf, Nov 8, 2007
    #11
  12. Szabolcs  Nagy

    Old Wolf Guest

    On Nov 8, 4:50 am, jacob navia <> wrote:
    > Andrey Tarasevich wrote:
    > > Szabolcs Nagy wrote:

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


    In C99 this is a VLA ; you still can't declare a
    'normal' array with a variable specifying the length.
     
    Old Wolf, Nov 8, 2007
    #12
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    11
    Views:
    1,151
  2. Javier
    Replies:
    2
    Views:
    620
    James Kanze
    Sep 4, 2007
  3. 0m
    Replies:
    26
    Views:
    1,171
    Tim Rentsch
    Nov 10, 2008
  4. fungus
    Replies:
    13
    Views:
    944
    fungus
    Oct 31, 2008
  5. Replies:
    2
    Views:
    562
    Andrew Koenig
    Feb 9, 2009
Loading...

Share This Page