Explanation needed for const int "error: variably modified ... atfile scope."

Discussion in 'C Programming' started by Poster Matt, Jun 15, 2010.

  1. Poster Matt

    Poster Matt Guest

    Hi,

    The following code results in the following error with GCC (v.4.3.2):

    const int eodSize = 8192;
    char eodContents[eodSize];

    error: variably modified 'eodContents' at file scope


    It is, of course, easily solved by ditching the 'const int' and using a #define
    instead like this:

    #define eodSize 8192
    char eodContents[eodSize];

    I would understand the error if "const int eodSize = 8192;" was not a constant
    but since it is a constant why does the compiler not allow it?

    Thanks.
    Poster Matt, Jun 15, 2010
    #1
    1. Advertising

  2. Poster Matt

    bart.c Guest

    Re: Explanation needed for const int "error: variably modified ... at file scope."

    "Poster Matt" <postermatt@no_spam_for_me.org> wrote in message
    news:bbQRn.22678$2...
    > Hi,
    >
    > The following code results in the following error with GCC (v.4.3.2):
    >
    > const int eodSize = 8192;
    > char eodContents[eodSize];
    >
    > error: variably modified 'eodContents' at file scope
    >
    >
    > It is, of course, easily solved by ditching the 'const int' and using a
    > #define instead like this:
    >
    > #define eodSize 8192
    > char eodContents[eodSize];
    >
    > I would understand the error if "const int eodSize = 8192;" was not a
    > constant but since it is a constant why does the compiler not allow it?


    const doesn't mean what you think.

    Just use:

    enum {eodSize=8192};

    as #define has it's own problems.

    --
    Bartc
    bart.c, Jun 15, 2010
    #2
    1. Advertising

  3. Poster Matt

    Ben Pfaff Guest

    Re: Explanation needed for const int "error: variably modified ... at file scope."

    Poster Matt <postermatt@no_spam_for_me.org> writes:

    > The following code results in the following error with GCC (v.4.3.2):
    >
    > const int eodSize = 8192;
    > char eodContents[eodSize];


    This is in the FAQ:

    11.8: I don't understand why I can't use const values in initializers
    and array dimensions, as in

    const int n = 5;
    int a[n];

    A: The const qualifier really means "read-only"; 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. (C
    is unlike C++ in this regard.) When you need a true compile-
    time constant, use a preprocessor #define (or perhaps an enum).

    References: ISO Sec. 6.4; H&S Secs. 7.11.2,7.11.3 pp. 226-7.
    --
    "When in doubt, treat ``feature'' as a pejorative.
    (Think of a hundred-bladed Swiss army knife.)"
    --Kernighan and Plauger, _Software Tools_
    Ben Pfaff, Jun 15, 2010
    #3
  4. Re: Explanation needed for const int "error: variably modified ... at file scope."

    Poster Matt <postermatt@no_spam_for_me.org> writes:
    > The following code results in the following error with GCC (v.4.3.2):
    >
    > const int eodSize = 8192;
    > char eodContents[eodSize];
    >
    > error: variably modified 'eodContents' at file scope
    >
    >
    > It is, of course, easily solved by ditching the 'const int' and using
    > a #define instead like this:
    >
    > #define eodSize 8192
    > char eodContents[eodSize];
    >
    > I would understand the error if "const int eodSize = 8192;" was not a
    > constant but since it is a constant why does the compiler not allow
    > it?


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

    The language *could* have stated that a const object with an
    initializer that's a constant expression is a constant <OT>as C++
    does</OT>, but it doesn't.

    Note that this is legal (at block scope):

    const int r = rand();

    r obviously isn't constant (in the sense of being evaluable at compile
    time), but it is "const", i.e., read-only, in the sense that you're
    not allowed to modify it:

    r = 42; /* constraint violation */

    .... at least not directly:

    *(int*)&r = 42; /* undefined behavior, not a constraint violation */

    bart.c points out the enum trick, which I find preferable to using
    a macro:

    enum { eodSize = 8192 };

    One drawback is that enumeration constants can only be of type int.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 15, 2010
    #4
  5. Poster Matt

    Poster Matt Guest

    Re: Explanation needed for const int "error: variably modified ...at file scope."

    bart.c wrote:
    >
    > "Poster Matt" <postermatt@no_spam_for_me.org> wrote in message
    > news:bbQRn.22678$2...
    >> Hi,
    >>
    >> The following code results in the following error with GCC (v.4.3.2):
    >>
    >> const int eodSize = 8192;
    >> char eodContents[eodSize];
    >>
    >> error: variably modified 'eodContents' at file scope
    >>
    >>
    >> It is, of course, easily solved by ditching the 'const int' and using
    >> a #define instead like this:
    >>
    >> #define eodSize 8192
    >> char eodContents[eodSize];
    >>
    >> I would understand the error if "const int eodSize = 8192;" was not a
    >> constant but since it is a constant why does the compiler not allow it?

    >
    > const doesn't mean what you think.
    >
    > Just use:
    >
    > enum {eodSize=8192};
    >
    > as #define has it's own problems.


    const means exactly what I think. It specifies that the value of the variable
    will not be changed.

    What on earth is wrong with using #define as I have used it above? It seems to
    me to be perfectly fine. Note: "#define eodSize 8192" is not being defined
    inside a function.

    But I was looking for an explanation...

    Cheers.
    Poster Matt, Jun 15, 2010
    #5
  6. Poster Matt

    Poster Matt Guest

    Re: Explanation needed for const int "error: variably modified ...at file scope."

    Ben Pfaff wrote:
    > Poster Matt <postermatt@no_spam_for_me.org> writes:
    >
    >> The following code results in the following error with GCC (v.4.3.2):
    >>
    >> const int eodSize = 8192;
    >> char eodContents[eodSize];

    >
    > This is in the FAQ:
    >
    > 11.8: I don't understand why I can't use const values in initializers
    > and array dimensions, as in
    >
    > const int n = 5;
    > int a[n];
    >
    > A: The const qualifier really means "read-only"; 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. (C
    > is unlike C++ in this regard.) When you need a true compile-
    > time constant, use a preprocessor #define (or perhaps an enum).
    >
    > References: ISO Sec. 6.4; H&S Secs. 7.11.2,7.11.3 pp. 226-7.


    Oops, sorry. Thanks for the info.
    Poster Matt, Jun 15, 2010
    #6
  7. Poster Matt

    Poster Matt Guest

    Re: Explanation needed for const int "error: variably modified ...at file scope."

    Poster Matt wrote:
    > bart.c wrote:
    >>
    >> "Poster Matt" <postermatt@no_spam_for_me.org> wrote in message
    >> news:bbQRn.22678$2...
    >>> Hi,
    >>>
    >>> The following code results in the following error with GCC (v.4.3.2):
    >>>
    >>> const int eodSize = 8192;
    >>> char eodContents[eodSize];
    >>>
    >>> error: variably modified 'eodContents' at file scope
    >>>
    >>>
    >>> It is, of course, easily solved by ditching the 'const int' and using
    >>> a #define instead like this:
    >>>
    >>> #define eodSize 8192
    >>> char eodContents[eodSize];
    >>>
    >>> I would understand the error if "const int eodSize = 8192;" was not a
    >>> constant but since it is a constant why does the compiler not allow it?

    >>
    >> const doesn't mean what you think.
    >>
    >> Just use:
    >>
    >> enum {eodSize=8192};
    >>
    >> as #define has it's own problems.

    >
    > const means exactly what I think. It specifies that the value of the
    > variable will not be changed.


    Ok I was a bit quick with my reply - it doesn't mean exactly what I thought it
    meant. <Head held in shame smiley>

    K&R is a bit unclear about it to say the least - see my reply to Keith.

    Cheers.
    Poster Matt, Jun 15, 2010
    #7
  8. Poster Matt

    bart.c Guest

    Re: Explanation needed for const int "error: variably modified ... at file scope."

    "Poster Matt" <postermatt@no_spam_for_me.org> wrote in message
    news:hEQRn.17414$US6.2344@hurricane...
    > bart.c wrote:


    >> "Poster Matt" <postermatt@no_spam_for_me.org> wrote in message
    >> news:bbQRn.22678$2...


    >>> const int eodSize = 8192;
    >>> char eodContents[eodSize];
    >>>
    >>> error: variably modified 'eodContents' at file scope


    >>> It is, of course, easily solved by ditching the 'const int' and using a
    >>> #define instead like this:
    >>>
    >>> #define eodSize 8192
    >>> char eodContents[eodSize];
    >>>
    >>> I would understand the error if "const int eodSize = 8192;" was not a
    >>> constant but since it is a constant why does the compiler not allow it?

    >>
    >> const doesn't mean what you think.
    >>
    >> Just use:
    >>
    >> enum {eodSize=8192};
    >>
    >> as #define has it's own problems.

    >
    > const means exactly what I think. It specifies that the value of the
    > variable will not be changed.


    Most people who ask that assume that 'const' defines an actual constant (not
    a memory location containing a value). Your wording ("...but since it is a
    constant ...") suggested you thought the same.

    > What on earth is wrong with using #define as I have used it above? It
    > seems to me to be perfectly fine. Note: "#define eodSize 8192" is not
    > being defined inside a function.


    Yes, #define names have too wide a visibility for many cases; enum doesn't
    have that problem and comes closest to what some people expect 'const' to
    do, at least for int values. But you seem to know all the answers already..

    > But I was looking for an explanation...


    I expected someone else to provide that; I just gave an alternative
    workaround..

    --
    Bartc

    >
    > Cheers.
    bart.c, Jun 15, 2010
    #8
  9. Poster Matt

    Poster Matt Guest

    Re: Explanation needed for const int "error: variably modified ...at file scope."

    Keith Thompson wrote:
    > Poster Matt <postermatt@no_spam_for_me.org> writes:
    >> The following code results in the following error with GCC (v.4.3.2):
    >>
    >> const int eodSize = 8192;
    >> char eodContents[eodSize];
    >>
    >> error: variably modified 'eodContents' at file scope
    >>
    >>
    >> It is, of course, easily solved by ditching the 'const int' and using
    >> a #define instead like this:
    >>
    >> #define eodSize 8192
    >> char eodContents[eodSize];
    >>
    >> I would understand the error if "const int eodSize = 8192;" was not a
    >> constant but since it is a constant why does the compiler not allow
    >> it?

    >
    > Because "const" doesn't mean "constant"; it really means "read-only".
    >
    > The language *could* have stated that a const object with an
    > initializer that's a constant expression is a constant <OT>as C++
    > does</OT>, but it doesn't.


    K&R is somewhat misleading then when it says:

    "The qualifier const can be applied to any variable to specify that its value
    will not be changed."

    > Note that this is legal (at block scope):
    >
    > const int r = rand();
    >
    > r obviously isn't constant (in the sense of being evaluable at compile
    > time), but it is "const", i.e., read-only, in the sense that you're
    > not allowed to modify it:
    >
    > r = 42; /* constraint violation */


    Ok got it.


    > ... at least not directly:
    >
    > *(int*)&r = 42; /* undefined behavior, not a constraint violation */
    >
    > bart.c points out the enum trick, which I find preferable to using
    > a macro:
    >
    > enum { eodSize = 8192 };
    >
    > One drawback is that enumeration constants can only be of type int.


    Why is it in any way preferable to use this 'enum trick' to a #define?

    Thanks Keith.
    Poster Matt, Jun 15, 2010
    #9
  10. Poster Matt

    Seebs Guest

    Re: Explanation needed for const int "error: variably modified ... at file scope."

    On 2010-06-15, Poster Matt <postermatt@no_spam_for_me.org> wrote:
    > I would understand the error if "const int eodSize = 8192;" was not a constant
    > but since it is a constant why does the compiler not allow it?


    It is not a constant.

    An object you can't write to is not a constant. You still have to look up
    the value at runtime (since nothing prevents some other aspect of the system
    from modifying the "constant" value).

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, Jun 15, 2010
    #10
  11. Re: Explanation needed for const int "error: variably modified ... at file scope."

    Poster Matt <postermatt@no_spam_for_me.org> writes:
    > Keith Thompson wrote:
    >> Poster Matt <postermatt@no_spam_for_me.org> writes:

    [...]
    >>> I would understand the error if "const int eodSize = 8192;" was not a
    >>> constant but since it is a constant why does the compiler not allow
    >>> it?

    >>
    >> Because "const" doesn't mean "constant"; it really means "read-only".
    >>
    >> The language *could* have stated that a const object with an
    >> initializer that's a constant expression is a constant <OT>as C++
    >> does</OT>, but it doesn't.

    >
    > K&R is somewhat misleading then when it says:
    >
    > "The qualifier const can be applied to any variable to specify that
    > its value will not be changed."


    How is that unclear? As far as I can tell, it's perfectly accurate;
    const specifies that the value of the variable (I would have said
    "object") will not be changed. It doesn't specify that it's a
    "constant" (where "constant" means roughly that its value can be
    evaluated at compile time).

    For example:

    >> Note that this is legal (at block scope):
    >>
    >> const int r = rand();
    >>
    >> r obviously isn't constant (in the sense of being evaluable at compile
    >> time), but it is "const", i.e., read-only, in the sense that you're
    >> not allowed to modify it:

    [...]

    How could the statement in K&R be made clearer?

    >> bart.c points out the enum trick, which I find preferable to using
    >> a macro:
    >>
    >> enum { eodSize = 8192 };
    >>
    >> One drawback is that enumeration constants can only be of type int.

    >
    > Why is it in any way preferable to use this 'enum trick' to a #define?
    >
    > Thanks Keith.


    The preprocessor is basically a language grafted on top of
    another language, with radically different syntax and semantics.
    A macro definition is not scoped; it remains visible from the
    point of declaration to the end of the translation unit. In more
    complex cases, you have to add extra parentheses and/or use the
    "do ... while(0)" trick to avoid subtle conflicts between the macro
    expansion and the language syntax.

    For a simple case like

    #define eodSize 8192

    it's not too bad; you're probably not going to have anything
    else with that name, so the scoping issue doesn't really matter.
    (But note that the convention is for macro names to be all-caps:
    EOD_SIZE -- but identifiers starting with E and either a digit
    or another uppercase letter are reserved as error macro names
    in <errno.h>.)

    Macros, like any other language feature, are fine if you know what
    you're doing, but they're particularly easy to misuse if you're
    not careful. I personally prefer to use other language features
    when possible.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 15, 2010
    #11
  12. Poster Matt

    Poster Matt Guest

    Re: Explanation needed for const int "error: variably modified ...at file scope."

    Keith Thompson wrote:
    > Poster Matt <postermatt@no_spam_for_me.org> writes:
    >> Keith Thompson wrote:
    >>> Poster Matt <postermatt@no_spam_for_me.org> writes:

    >
    >> K&R is somewhat misleading then when it says:
    >>
    >> "The qualifier const can be applied to any variable to specify that
    >> its value will not be changed."

    >
    > How is that unclear? As far as I can tell, it's perfectly accurate;
    > const specifies that the value of the variable (I would have said
    > "object") will not be changed. It doesn't specify that it's a
    > "constant" (where "constant" means roughly that its value can be
    > evaluated at compile time).


    I'm not sure I should have said 'misleading', but it certainly does not tell the
    whole story. To my mind the quotation above implies that the value specified in
    the source code will not be changed. So I'd never have thought "const int r =
    rand();" was allowed.


    >> Why is it in any way preferable to use this 'enum trick' to a #define?
    >>

    >
    > The preprocessor is basically a language grafted on top of
    > another language, with radically different syntax and semantics.
    > A macro definition is not scoped; it remains visible from the
    > point of declaration to the end of the translation unit. In more
    > complex cases, you have to add extra parentheses and/or use the
    > "do ... while(0)" trick to avoid subtle conflicts between the macro
    > expansion and the language syntax.
    >
    > For a simple case like
    >
    > #define eodSize 8192
    >
    > it's not too bad; you're probably not going to have anything
    > else with that name, so the scoping issue doesn't really matter.
    > (But note that the convention is for macro names to be all-caps:
    > EOD_SIZE -- but identifiers starting with E and either a digit
    > or another uppercase letter are reserved as error macro names
    > in <errno.h>.)
    >
    > Macros, like any other language feature, are fine if you know what
    > you're doing, but they're particularly easy to misuse if you're
    > not careful. I personally prefer to use other language features
    > when possible.


    Ok, many thanks for the detailed explanation, it's appreciated. I still have a
    lot to learn, funny that cos I thought I was getting pretty good. :)

    Re: Macro variable name - the name in my actual code was quite long and
    descriptive, so I made up a fake name for posting here. eodSize and eodContents
    were named simply because I had a DVD rental on my desk of a Mel Gibson movie
    called Edge of Darkness, when the thought entered my mind to make a more concise
    name for posting, the DVD was in my field of view, hence 'eod'. I didn't
    capitalize the #define version out of laziness when copying'n'pasting.

    Thanks again. I've learnt another new thing about C today. I'll get there
    eventually...(I hope).

    Cheers.
    Poster Matt, Jun 15, 2010
    #12
  13. Re: Explanation needed for const int "error: variably modified ... at file scope."

    Poster Matt <postermatt@no_spam_for_me.org> writes:

    > Keith Thompson wrote:
    >> Poster Matt <postermatt@no_spam_for_me.org> writes:
    >>> Keith Thompson wrote:
    >>>> Poster Matt <postermatt@no_spam_for_me.org> writes:

    >>
    >>> K&R is somewhat misleading then when it says:
    >>>
    >>> "The qualifier const can be applied to any variable to specify that
    >>> its value will not be changed."

    >>
    >> How is that unclear? As far as I can tell, it's perfectly accurate;
    >> const specifies that the value of the variable (I would have said
    >> "object") will not be changed. It doesn't specify that it's a
    >> "constant" (where "constant" means roughly that its value can be
    >> evaluated at compile time).

    >
    > I'm not sure I should have said 'misleading', but it certainly does
    > not tell the whole story. To my mind the quotation above implies that
    > the value specified in the source code will not be changed.


    More than implies -- it says so explicitly and unambiguously!

    > So I'd
    > never have thought "const int r = rand();" was allowed.


    There's really no contradiction. To take an example:

    for (int i = 1; i <= 10; i++) {
    const int r = rand();
    printf("%d\n", r * r / i);
    }

    the value of "the" const object never changes (in fact any attempt to do
    so is either a constraint violation or will produce undefined
    behaviour).

    I put "the" in quotes because it is the use of phrases like "the const
    object r" that leads to confusion. The way to think of this is that a
    new object called r appears in every iteration and is destroyed at the
    end of the loop body (in each iteration). There are, one after the
    other, 10 const objects called r and the value in each and every one
    never changes during its lifetime.

    People naturally get sloppy and talk about "the object r", but then it
    seems as if r can change but it doesn't -- not during the lifetime of
    the object.

    <snip>
    --
    Ben.
    Ben Bacarisse, Jun 15, 2010
    #13
  14. Poster Matt

    Tim Streater Guest

    Re: Explanation needed for const int "error: variably modified ... at file scope."

    In article <dTSRn.39999$Cw6.3269@hurricane>,
    Poster Matt <postermatt@no_spam_for_me.org> wrote:

    > Re: Macro variable name - the name in my actual code was quite long and
    > descriptive, so I made up a fake name for posting here. eodSize and
    > eodContents
    > were named simply because I had a DVD rental on my desk of a Mel Gibson movie
    > called Edge of Darkness, when the thought entered my mind to make a more
    > concise
    > name for posting, the DVD was in my field of view, hence 'eod'. I didn't
    > capitalize the #define version out of laziness when copying'n'pasting.


    Ha! You are Keyser Söze and I claim my £5.

    --
    Tim

    "That excessive bail ought not to be required, nor excessive fines imposed,
    nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
    Tim Streater, Jun 15, 2010
    #14
  15. Keith Thompson <> wrote:
    > Poster Matt <postermatt@no_spam_for_me.org> writes:
    > > K&R is somewhat misleading then when it says:
    > > "The qualifier const can be applied to any variable to
    > > specify that its value will not be changed."

    >
    > How is that unclear?


    Well the preface to K&R says...

    The book is not an introductory programming manual; it
    assumes some familiarity with basic programming concepts...

    Most people's familiarity of variables whose 'values will not
    be changed,' and especially a CONST keyword, is that of true
    constants, not the weaker 'don't write' ones that C employs.

    > As far as I can tell, it's perfectly accurate; const
    > specifies that the value of the variable (I would have
    > said "object") will not be changed. It doesn't specify
    > that it's a "constant" (where "constant" means roughly
    > that its value can be evaluated at compile time).


    Yes, it clearly doesn't say that const is a constant. But
    it would have been better if it cleary added that const
    _isn't_ a constant.

    --
    Peter
    Peter Nilsson, Jun 16, 2010
    #15
  16. Poster Matt

    Poster Matt Guest

    Re: Explanation needed for const int "error: variably modified ...at file scope."

    Ben Bacarisse wrote:
    > Poster Matt <postermatt@no_spam_for_me.org> writes:
    >
    >> Keith Thompson wrote:
    >>> Poster Matt <postermatt@no_spam_for_me.org> writes:
    >>>> Keith Thompson wrote:
    >>>>> Poster Matt <postermatt@no_spam_for_me.org> writes:
    >>>> K&R is somewhat misleading then when it says:
    >>>>
    >>>> "The qualifier const can be applied to any variable to specify that
    >>>> its value will not be changed."
    >>> How is that unclear? As far as I can tell, it's perfectly accurate;
    >>> const specifies that the value of the variable (I would have said
    >>> "object") will not be changed. It doesn't specify that it's a
    >>> "constant" (where "constant" means roughly that its value can be
    >>> evaluated at compile time).

    >> I'm not sure I should have said 'misleading', but it certainly does
    >> not tell the whole story. To my mind the quotation above implies that
    >> the value specified in the source code will not be changed.

    >
    > More than implies -- it says so explicitly and unambiguously!


    Not quite, K&R says the "value will not be changed", I said the "value specified
    in the source code will not be changed", in other words I mean a fixed constant
    value EG. 3.1415, "Keyser Söze", etc., and not some kind of dynamic assignment
    like the const int r = rand() example.


    >> So I'd
    >> never have thought "const int r = rand();" was allowed.

    >
    > There's really no contradiction. To take an example:
    >
    > for (int i = 1; i <= 10; i++) {
    > const int r = rand();
    > printf("%d\n", r * r / i);
    > }
    >
    > the value of "the" const object never changes (in fact any attempt to do
    > so is either a constraint violation or will produce undefined
    > behaviour).
    >
    > I put "the" in quotes because it is the use of phrases like "the const
    > object r" that leads to confusion. The way to think of this is that a
    > new object called r appears in every iteration and is destroyed at the
    > end of the loop body (in each iteration). There are, one after the
    > other, 10 const objects called r and the value in each and every one
    > never changes during its lifetime.
    >
    > People naturally get sloppy and talk about "the object r", but then it
    > seems as if r can change but it doesn't -- not during the lifetime of
    > the object.


    Ok, got it. :)

    Cheers.
    Poster Matt, Jun 16, 2010
    #16
  17. Poster Matt

    Poster Matt Guest

    Re: Explanation needed for const int "error: variably modified ...at file scope."

    Tim Streater wrote:
    > In article <dTSRn.39999$Cw6.3269@hurricane>,
    > Poster Matt <postermatt@no_spam_for_me.org> wrote:
    >
    >> Re: Macro variable name - the name in my actual code was quite long and
    >> descriptive, so I made up a fake name for posting here. eodSize and
    >> eodContents
    >> were named simply because I had a DVD rental on my desk of a Mel Gibson movie
    >> called Edge of Darkness, when the thought entered my mind to make a more
    >> concise
    >> name for posting, the DVD was in my field of view, hence 'eod'. I didn't
    >> capitalize the #define version out of laziness when copying'n'pasting.

    >
    > Ha! You are Keyser Söze and I claim my £5.


    Actually I'm just his lawyer, Kobayashi. :)

    Regards,

    Kob
    Poster Matt, Jun 16, 2010
    #17
  18. Poster Matt

    Poster Matt Guest

    Re: Explanation needed for const int "error: variably modified ...at file scope."

    Keith Thompson wrote:
    > Poster Matt <postermatt@no_spam_for_me.org> writes:
    >> Keith Thompson wrote:
    >>> Poster Matt <postermatt@no_spam_for_me.org> writes:
    >>>> Keith Thompson wrote:
    >>>>> Poster Matt <postermatt@no_spam_for_me.org> writes:
    >>>> K&R is somewhat misleading then when it says:
    >>>>
    >>>> "The qualifier const can be applied to any variable to specify that
    >>>> its value will not be changed."
    >>> How is that unclear? As far as I can tell, it's perfectly accurate;
    >>> const specifies that the value of the variable (I would have said
    >>> "object") will not be changed. It doesn't specify that it's a
    >>> "constant" (where "constant" means roughly that its value can be
    >>> evaluated at compile time).

    >> I'm not sure I should have said 'misleading', but it certainly does
    >> not tell the whole story. To my mind the quotation above implies that
    >> the value specified in the source code will not be changed. So I'd
    >> never have thought "const int r = rand();" was allowed.

    >
    > Ok, I see what you mean.
    >
    > What it really means is that the value will not be changed *once
    > the object has been initialized*. Once you understand that, it's a
    > bit difficult to interpret in any other way. (That's why I asked;
    > the better I understand how beginners can misunderstand things that
    > seem obvious to me, the better I can explain them.)


    That's how I could have answered your earlier question of "How could the
    statement in K&R be made clearer?".

    K&R amendment (given my lowly level this seems rather arrogant to even attempt,
    let alone publicly):

    Original: "The qualifier const can be applied to any variable to specify that
    its value will not be changed."

    Amended: "The qualifier const can be applied to any variable to specify that its
    value will not be changed after it has been initialized."


    >> Thanks again. I've learnt another new thing about C today. I'll get
    >> there eventually...(I hope).

    >
    > Me too.


    Trust me Keith - you're there. :)

    Cheers.
    Poster Matt, Jun 16, 2010
    #18
  19. Poster Matt

    Poster Matt Guest

    Re: Explanation needed for const int "error: variably modified ...at file scope."

    Peter Nilsson wrote:
    > Keith Thompson <> wrote:
    >> Poster Matt <postermatt@no_spam_for_me.org> writes:
    >>> K&R is somewhat misleading then when it says:
    >>> "The qualifier const can be applied to any variable to
    >>> specify that its value will not be changed."

    >> How is that unclear?

    >
    > Well the preface to K&R says...
    >
    > The book is not an introductory programming manual; it
    > assumes some familiarity with basic programming concepts...
    >
    > Most people's familiarity of variables whose 'values will not
    > be changed,' and especially a CONST keyword, is that of true
    > constants, not the weaker 'don't write' ones that C employs.
    >
    >> As far as I can tell, it's perfectly accurate; const
    >> specifies that the value of the variable (I would have
    >> said "object") will not be changed. It doesn't specify
    >> that it's a "constant" (where "constant" means roughly
    >> that its value can be evaluated at compile time).

    >
    > Yes, it clearly doesn't say that const is a constant. But
    > it would have been better if it cleary added that const
    > _isn't_ a constant.


    Peter I couldn't have put it clearer myself. In fact I didn't put it clearer.

    Thanks for making my point better than I made it. :)

    Cheers.
    Poster Matt, Jun 16, 2010
    #19
  20. Re: Explanation needed for const int "error: variably modified ... at file scope."

    Poster Matt <postermatt@no_spam_for_me.org> writes:
    <snip>
    > That's how I could have answered your earlier question of "How could
    > the statement in K&R be made clearer?".
    >
    > K&R amendment (given my lowly level this seems rather arrogant to even
    > attempt, let alone publicly):
    >
    > Original: "The qualifier const can be applied to any variable to
    > specify that its value will not be changed."
    >
    > Amended: "The qualifier const can be applied to any variable to
    > specify that its value will not be changed after it has been
    > initialized."


    This is one of those cases where you risk confusing others who have a
    different picture. Some people have the (incorrect) view that a
    variable is initialised when it first gets assigned a value. I.e. they
    would take your wording as permitting

    const int x;
    x = 42;

    Of course that is not what you intended to suggest, but then K&R did not
    intend their words to suggest what you originally took from them!

    Finally, your version is unclear in one very technical way. What does
    it say about a const variable that is not initialised at all? Automatic
    const variables that are defined without an initialiser are not even
    implicitly initialised, so presumably their values *can* be changed or
    maybe the phrase says nothing at all about such variables?

    Simplifying things for the purposes of getting the main ideas across is
    an important technique, but I get the feeling that K&R prefer to be as
    minimal and as technically accurate as possible. I like that style (I
    am always searching for the "K&R of XYZ" when leaning a new language)
    but they do run the risk of people reading more into what is written
    than is supported by the text or, for that matter, of finding it too
    dense.

    --
    Ben.
    Ben Bacarisse, Jun 16, 2010
    #20
    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. Timo Freiberger
    Replies:
    3
    Views:
    944
    Bob Hairgrove
    Oct 30, 2004
  2. ThazKool
    Replies:
    1
    Views:
    447
  3. Replies:
    11
    Views:
    1,102
  4. Javier
    Replies:
    2
    Views:
    561
    James Kanze
    Sep 4, 2007
  5. 0m
    Replies:
    26
    Views:
    1,116
    Tim Rentsch
    Nov 10, 2008
Loading...

Share This Page