f



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

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.
0
Poster
6/15/2010 7:06:47 PM
comp.lang.c 30657 articles. 3 followers. spinoza1111 (3246) is leader. Post Follow

23 Replies
14557 Views

Similar Articles

[PageSpeed] 1

"Poster Matt" <postermatt@no_spam_for_me.org> wrote in message 
news:bbQRn.22678$YG4.13172@newsfe10.ams2...
> 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

0
bart
6/15/2010 7:14:31 PM
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_
1
blp
6/15/2010 7:33:31 PM
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) kst-u@mib.org  <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"
0
Keith
6/15/2010 7:34:15 PM
bart.c wrote:
> 
> "Poster Matt" <postermatt@no_spam_for_me.org> wrote in message 
> news:bbQRn.22678$YG4.13172@newsfe10.ams2...
>> 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.
0
Poster
6/15/2010 7:37:49 PM
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.
0
Poster
6/15/2010 7:42:50 PM
Poster Matt wrote:
> bart.c wrote:
>>
>> "Poster Matt" <postermatt@no_spam_for_me.org> wrote in message 
>> news:bbQRn.22678$YG4.13172@newsfe10.ams2...
>>> 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.
0
Poster
6/15/2010 7:49:25 PM
"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$YG4.13172@newsfe10.ams2...

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

0
bart
6/15/2010 7:51:57 PM
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.
0
Poster
6/15/2010 7:53:18 PM
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 / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
Seebs
6/15/2010 7:56:11 PM
Poster Matt wrote:
> Keith Thompson wrote:
<snip>
>>
>> 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?

Good question. Whilst #define is perhaps not perfect, its "problems" are 
frequently exaggerated.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
0
Richard
6/15/2010 8:42:23 PM
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) kst-u@mib.org  <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"
0
Keith
6/15/2010 9:12:10 PM
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.
0
Poster
6/15/2010 10:10:17 PM
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.
0
Ben
6/15/2010 10:37:01 PM
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
0
Tim
6/15/2010 10:46:42 PM
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.)

[...]

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

Me too.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"
0
Keith
6/15/2010 11:18:04 PM
Keith Thompson <ks...@mib.org> 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
0
Peter
6/16/2010 4:05:51 AM
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.
0
Poster
6/16/2010 12:07:53 PM
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
0
Poster
6/16/2010 12:10:38 PM
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.
0
Poster
6/16/2010 12:19:37 PM
Peter Nilsson wrote:
> Keith Thompson <ks...@mib.org> 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.
0
Poster
6/16/2010 12:22:14 PM
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.
0
Ben
6/16/2010 1:41:37 PM
Poster Matt <postermatt@no_spam_for_me.org> writes:
> Peter Nilsson wrote:
>> Keith Thompson <ks...@mib.org> wrote:
[...]
>>> 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. :)

Something else that you might run across is that C's use of the words
"const" to mean read-only and "constant" to mean compile-time evaluable
are not universal.

For example, Ada uses the word "constant" to mean about the same
thing that C's "const" means:

    R: constant Integer := Random(42);

It uses the word "static" to mean that something can be evaluated at
compile time (whereas C uses "static" to mean -- well, all sorts of
things).

The point is that, if you're going to be working in more than one
language, you need to keep track of the concepts and be prepared to be
flexible about the terminology.  (But I recommend being *inflexible*
about the terminology within a given language.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"
0
Keith
6/16/2010 3:50:09 PM
Keith Thompson wrote:
> Poster Matt <postermatt@no_spam_for_me.org> writes:
>> Peter Nilsson wrote:
>>> Keith Thompson <ks...@mib.org> wrote:
> [...]
>>>> 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. :)
> 
> Something else that you might run across is that C's use of the words
> "const" to mean read-only and "constant" to mean compile-time evaluable
> are not universal.
> 
> For example, Ada uses the word "constant" to mean about the same
> thing that C's "const" means:
> 
>     R: constant Integer := Random(42);
> 
> It uses the word "static" to mean that something can be evaluated at
> compile time (whereas C uses "static" to mean -- well, all sorts of
> things).
> 
> The point is that, if you're going to be working in more than one
> language, you need to keep track of the concepts and be prepared to be
> flexible about the terminology.  (But I recommend being *inflexible*
> about the terminology within a given language.)

Thanks for the advise Keith. I'll bare it in mind.

Cheers.
0
Poster
6/16/2010 5:35:09 PM
Reply:

Similar Artilces:

Urgent need """""""""""INFORMATICA DEVELOPER"""""""""""""
Hello Partners, How are you ? Please find the requirements below. Title: Database/ETL Developer Duration: 6 months Location: NY Exp: 7+ Locals preferred Database/ETL requirements (Mandatory) Candidate must have worked with financial instruments, preferably Mutual Funds but, Equities are also ok. PL/SQL - packages, Stored procs, Functions, Aggregate functions, Pipelined Functions Informatica 8.6 - especially complex mappings, complex maplets, complex workflows, transformations Oracle 10g/11g Unix/Linux shell scripting Database/ETL requirements (Optional) Data warehousing experience Threading and job concepts in 10g/11g Cost based Optimizer concepts in 10g/11g Must : Experience with XML files and partitioning concepts in Oracle, Collections, Material Views Note : No phone calls please. : send Resumes to karthik@bhaninfo.com Thanks & Regards Karthik BhanInfo karthik@bhaninfo.com ...

["a", "b", "c", "d"] to "a, b, c, d"?
I want to process each element of an array, but the last element should be handled special. Here is an example: def p_ary(ary) str = "" ary.each do |elem| str << elem << ", " end str.chomp!(", ") str end so p_ary(["a", "f", "x", "test"]) produces "a, f, x, test". The code works, but isn't there an easier and more general way for this behaviour? martinus On Tue, 06 Apr 2004 04:23:22 -0700, Martin wrote: > I want to process each element of an array, but the last ele...

Error: Configuration file "C:\Program" is unreadable."
Dear all, Somehow I have to double click a SAS file and open it. But that error message showed up. I have searched the previous posting and followed the instruction to fix the problem. At the same time, I also checked SAS web site and followed their instruction to fix the problem. But after all these efforts, I still got the nasty message. The only thing I haven't tried is to reinstall SAS because there are a lot of procedures to do that. Any idea will be greatly appreciated. Bob Bob, What kind of system are you on? From your example I presume an older version of Windows. If that is the case, you have to see how SAS is called. It sounds like a Window's problem, trying to find 'C:\program files', but not being able to read the long file names. If so, you may have to change that part of the call to 'c:\progra~1'. Art ----- On Wed, 1 Jun 2005 14:32:21 -0700, baoxian_lan@EXCITE.COM wrote: >Dear all, > >Somehow I have to double click a SAS file and open it. But that error >message showed up. I have searched the previous posting and followed >the instruction to fix the problem. At the same time, I also checked >SAS web site and followed their instruction to fix the problem. > >But after all these efforts, I still got the nasty message. > >The only thing I haven't tried is to reinstall SAS because there are a >lot of procedures to do that. > >Any idea will be greatly appreciated. > >Bob ...

Solution to the invalid "int[][]" -> "const int[][]" conversion
First, here's the code I'm talking about: /* -------------------------- */ typedef int TYPE[8][8]; extern void g(const TYPE); extern TYPE data; void f() { g(data); } /* -------------------------- */ The above code gives the following compiler warning on gcc-3.4.3: warning: passing arg 1 of `g' from incompatible pointer type I do understand that it's generally unsafe to convert "Foo **" to "const Foo **", as it's pointed out here: http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.15 (Yes, I know, that's a...

"#define" vs "const int"
I'm told that with most optimizing compilers, if you say "const int foo = 4" rather than "#define foo 4", the compiler won't actually allocate any memory for the int. True? Eric wrote: > I'm told that with most optimizing compilers, if you say "const int > foo = 4" rather than "#define foo 4", the compiler won't actually > allocate any memory for the int. True? Yes. Eric wrote: > I'm told that with most optimizing compilers, if you say "const int > foo = 4" rather than "#define foo 4", the ...

"#define" vs "const int"
I'm told that with most optimizing compilers, if you say "const int foo = 4" rather than "#define foo 4", the compiler won't actually allocate any memory for the int. True? Eric wrote: > I'm told that with most optimizing compilers, if you say "const int > foo = 4" rather than "#define foo 4", the compiler won't actually > allocate any memory for the int. True? > lcc-win will do this. If you say static const int foo = 4; it will not allocate space for it. Otherwise it has to allocate space since it could be used in s...

Re: Error: Configuration file "C:\Program" is unreadable."
Bob, What kind of system are you on? From your example I presume an older version of Windows. If that is the case, you have to see how SAS is called. It sounds like a Window's problem, trying to find 'C:\program files', but not being able to read the long file names. If so, you may have to change that part of the call to 'c:\progra~1'. Art ----- On Wed, 1 Jun 2005 14:32:21 -0700, baoxian_lan@EXCITE.COM wrote: >Dear all, > >Somehow I have to double click a SAS file and open it. But that error >message showed up. I have searched the previous posting and followed >the instruction to fix the problem. At the same time, I also checked >SAS web site and followed their instruction to fix the problem. > >But after all these efforts, I still got the nasty message. > >The only thing I haven't tried is to reinstall SAS because there are a >lot of procedures to do that. > >Any idea will be greatly appreciated. > >Bob ...

problem on startup: File error: "Cannot open load file", "xfonts"
Hi everybody I just installed the newest emacs testing as emacs package. after starting it with emacs --debug-init I get the error Debugger entered--Lisp error: (file-error "Cannot open load file" "xfonts") require(xfonts) byte-code("��!������@��!��!A��B\"� B��B\"�@��B\"A@*�A�B��!�C���\"��!�FBF��!���\"��!��!I�VH�V��!��!�K%N�!!R�#\"\"\"\"\"S\"!!�\"!!\"!\" �=��Q �=����# �=��Q��\n� � !� ! �\f!\f�\f \"��\f #� a.s.o. The require(xfonts) is in the .gnu-e...

ActiveState vs. "C:\Program Files\" and "C:\Progra~1\"
note: this post started off as a question, but turned into a blog and eventually became an answer. I just hate to have anyone else go through all this nonsense, so I figured I'd post it as an example of "when in doubt, google it out". I successfully installed ActiveState 5.8.8 (after uninstalling 5.6.something) on an XP laptop. I installed it to "C:\Program FIles \Activestate.com\Perl". After the install, I changed the "Program files" part of the ActiveState dirs in my PATH env var from long DOS format to 8.3 format: "C:\Program Files\ActiveState.com\Perl\site\bin" to "C:\Progra~1\ActiveState.com\Perl\site\bin" and "C:\Program Files\ActiveState.com\Perl\bin" to "C:\Progra~1\ActiveState.com\Perl\bin" Now, when I attempt to build a CPAN module (BitTorrent), I get: <pre> C:\blah... \BitTorrent>perl makefile.pl Have C:\Progra~1\ActiveState.com\Perl\lib\Config.pm expected C: \Program Files\ActiveState.com\Perl\lib\Config.pm Your perl and your Config.pm seem to have different ideas about the architecture they are running on. Perl thinks: [lib] Config says: [MSWin32-x86-multi-thread] This may or may not cause problems. Please check your installation of perl if you have problems building this extension. Writing Makefile for BitTorrent </pre> It *looks* like Perl is just unhappy about the directory rename. I changed the PATH back to the original install dir and the new message ...

When to use "INT" or "int"?
In windef.h there is a type definition typedef int INT; Windows itself uses both types. For example, in the declaration of SetSysColors: BOOL WINAPI SetSysColors( int cElements, // number of elements to change CONST INT *lpaElements, // address of array of elements CONST COLORREF *lpaRgbValues // address of array of RGB values ); Then I have a question: What is the consideration beneath the choice of using either "int" or "INT"? In this case, why cElements should better be declared as "int&...

"proc report" using a "by" variable as an "across" variable
I didn't know that you could use a "by" variable as an "across" variable as well in proc report. I tried it out today just to see what syntax errors it would throw at me but instead it worked without complaint. I guess it's one of the things I should know but have never come across before. It is useful for putting what would normally be in a "by line" in the columns of a table instead. It looks better that way, sometimes. On Tue, 18 Oct 2005 04:38:07 -0700, RolandRB <rolandberry@HOTMAIL.COM> wrote: >I didn't know that you could use a "...

TI & CCS
I've just recently moved from SHARC & Visual DSP to TIC6713 with Code Composer Studio. I am working through the tutorials and I have met a problem: In the second tutorial "Project Management" I follow the instructions but when I try to build the project I get: ===================================================== ------------------------- maxminlibrary.pjt - Debug ------------------------- Error, Don't know how to build file "C:\ti\tutorial\dsk6713\maxminmath \maxminlibrary.cmd" [maximumvalue.c] "c:\ti\c6000\cgtools\bin\cl6x" -g -q - fr"C:/ti/myprojects/myapplication/maxminlibrary/Debug" -d"_DEBUG" - mv6700 -@"maxminlibrary/Debug.lkf" "maximumvalue.c" [minimumvalue.c] "c:\ti\c6000\cgtools\bin\cl6x" -g -q - fr"C:/ti/myprojects/myapplication/maxminlibrary/Debug" -d"_DEBUG" - mv6700 -@"maxminlibrary/Debug.lkf" "minimumvalue.c" [Archiving...] "c:\ti\c6000\cgtools\bin\ar6x" @"Debug.lkf" ==> new archive 'C:\ti\myprojects\myapplication\maxminlibrary\Debug \maxminlibrary.lib' ==> building archive 'C:\ti\myprojects\myapplication\maxminlibrary \Debug\maxminlibrary.lib' Build Complete, 1 Errors, 0 Warnings, 0 Remarks. ===================================================== The only place I have to deviate from the instructions is the section that states: "Browse to c:\ti\c6000\cgtools\lib\, s...

Playing with 3 variables "know", "need" and "can" and creating a simple model.
I will use 3 assumptions: 1st: I know what I need. 2nd: I know what I can. 3rd: In order to be in balance it is necessary that the 1st assumption to be less or equal with the 2nd assumption. Most of the problems seem to arise because what we can is less than what we need and our "goal", "wish", "desire" "motivation", etc. is to bring these 2 variables in balance. The most important variable seems to be the "know" one If what we know is incorrect, the achievement of our goals, motivation will not bring the desired result, the balance. Looking at...

How do I exclude "CTRL+C" from "dbstop if error"?
Hello, I am using extensively the "dbstop if error" option to allow me to debug in case of unexpected error (aren't they all...?). However, I don't want to go into debug mode when I break execution using "CTRL+C". I don't want to go into debug mode in this case. Can that be done? can I exclude a specific error ("Operation terminated by user during...") from the "dbstop if error" mode? Thanks, Ran "Ran" wrote in message <ju8gqk$ncn$1@newscl01ah.mathworks.com>... > Hello, > > I am using extensively the "dbstop if error" option to allow me to debug in case of unexpected error (aren't they all...?). > However, I don't want to go into debug mode when I break execution using "CTRL+C". I don't want to go into debug mode in this case. Can that be done? can I exclude a specific error ("Operation terminated by user during...") from the "dbstop if error" mode? > > Thanks, > Ran I am curious about this as well. Maybe dbclear will do the trick? "Ran" wrote in message <ju8gqk$ncn$1@newscl01ah.mathworks.com>... > Hello, > > I am using extensively the "dbstop if error" option to allow me to debug in case of unexpected error (aren't they all...?). > However, I don't want to go into debug mode when I break execution using "CTRL+C". I don't want to go into debug mode i...

help:what is "quirk" in the file "usbaudio.c"
what is "quirk" or what does it mean ,in the file "usbaudio.c" thanks kevin wrote: > what is "quirk" or what does it mean ,in the file "usbaudio.c" It's a workaround for devices that do not follow the USB Audio specification or have other bugs. HTH Clemens ...

What does "Standard C", "K&R C" , "ANSI C" mean?
I am just wondering what the following terms usually mean: 1) "Standard C" 2) "K&R C" 3) "ANSI C" I am pretty sure "ANSI C" usually refers to the C89 standard, but what about the other two? What is the "saying" for C99 standard? Thank you On 17 Jan 2005 21:26:42 -0800, "Luke Wu" <LookSkywalker@gmail.com> wrote in comp.lang.c: > I am just wondering what the following terms usually mean: > > 1) "Standard C" The current version of the C language standard. This is now known as "ISO/IEC 9899:19...

How To Accessing C++ Class objects in C : getting error fatal error C1189: #error : "eh.h is only for C++!"
hi , i am Getting this Error fatal error C1189: #error : "eh.h is only for C++!" my Problem is i am Having C++ librabry and Appropriate .h file i want to Access Them is .c File Files..... to Be More Specific i am Creating a C++ Object in a C file... this Giving me the error!!! :( can Any Body Please Help me How to Access the C++ object in C file... Thanks In Advance :) Hi, > How to Access the C++ object in C file... Please have a look at the following page http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html Regards On Jan 7, 11:17=A0am, "sachinv1...@gmail.com" <sachinv1...@gmail.com> wrote: > hi , > i am Getting this Error > fatal error C1189: #error : "eh.h is only for C++!" > my Problem is i am Having C++ librabry and Appropriate .h file > i want to Access Them is .c File Files..... > to Be More Specific i am Creating a C++ Object in a C file... > this Giving me the error!!! :( > > can Any Body Please Help me > > How to Access the C++ object in C file... > Thanks In Advance :) In general, you can't. You can provide a procedural interface instead, and declare it in a header file like this: #ifdef __cplusplus extern "C" { #endif void some_function(int, char*, double); // or whatever #ifdef __cplusplus } #endif This can then be included from both C and C++. On Jan 7, 4:32=A0pm, tragomaskhalos <dave.du.verg...@logicacmg.com> wrote: > On Jan 7, 11:17=A0am, "...

why "::", not "."
Why does the method of modules use a dot, and the constants a double colon? e.g. Math::PI and Math.cos -- Posted via http://www.ruby-forum.com/. On Oct 26, 2010, at 01:48 , Oleg Igor wrote: > Why does the method of modules use a dot, and the constants a double > colon? > e.g. > Math::PI and Math.cos For the same reason why inner-classes/modules use double colon, because = they're constants and that's how you look up via constant namespace. Math::PI and ActiveRecord::Base are the same type of lookup... it is = just that Base is a module and PI is a float....

about "++" and "--"
why this program snippet display "8,7,7,8,-7,-8" the program is: main() { int i=8; printf("%d\n%d\n%d\n%d\n%d\n%d\n",++i,--i,i++,i--,-i++,-i--); } > why this program snippet display "8,7,7,8,-7,-8" Ask your compiler-vendor because this result is IMHO implementation-defined. Check this out: http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.15 http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.16 Regards, Irina Marudina fxc123@gmail.com wrote: > why this program snippet display "8,7,7,8,-7,-8&q...

"out" and "in out"
Hi i found the following explaination: In Ada, "in" parameters are similar to C++ const parameters. They are effectively read-only within the scope of the called subprogram. Ada "in out" parameters have a reliable initial value (that passed in from the calling subprogram) and may be modified within the scope of the called procedure. Ada "out" parameters have no reliable initial value, but are expected to be assigned a value within the called procedure. What does "have no reliable initial value" mean when considering the "out" parameter? By chance I created a small program as follows: =========== s : string := "CAT"; procedure modify ( s1 : out string ) is begin s1(2) := 'U'; end modify; ... put ( modify(s) ); =========== now I get as a result "CUT", and i dont understand why i get this result. Doesnt the "out" specify that its initial value isnt passed in via the parameter? But it seems to be passed in the above. In fact the "out" is acting like an "in out". I am a little confused. Could someone shed some light on this? Many thanks! zork "zork" <zork@nospam.com> wrote in message news:4104d5de@dnews.tpgi.com.au... > Hi i found the following explaination: > > In Ada, "in" parameters are similar to C++ const parameters. They are > effectively read-only within the scope of the called subprogram. > Ada "in out&q...

Undefined error #612
I got this message when i did a nonlinear regression. I am using SPSS 13.0 Undefined error #612 - Cannot open text file "C:\Program Files\SPSS\en\windows\spss.err": No such file or directory=AC Predicted values are missing, or case weights are missing or not positive for all cases. This command is not executed. What is wrong with the SPSS? I have no problem at all when i use version 12.0 Thank you, run - I have not seen anyone respond to this one - Here is a comment, even though it is not very useful. On 22 Mar 2005 18:56:27 -0800, "run" <run@hawaii.edu> wrote: > > I got this message when i did a nonlinear regression. I am using SPSS > 13.0 > > Undefined error #612 - Cannot open text file "C:\Program > Files\SPSS\en\windows\spss.err": No such file or directory� 1) That's a funny character at the end of 'directory', which reads as "=AC" or else as a special character. 2) That text file message seems to point to a message-file that should be there at installation; so it *seems* to signify that the installation went wrong, or disk contents have been altered since the time of installation. Combining those two things with my long experience at pondering error messages -- I wonder whether SPSS could be totally screwed up at this stage, so that the next line about "Predicted values ... weights" may have little to do with anythi...

[Urgent]: How To Accessing C++ Class objects in C : getting error fatal error C1189: #error : "eh.h is only for C++!"
hi , i am Getting this Error fatal error C1189: #error : "eh.h is only for C++!" my Problem is i am Having C++ librabry and Appropriate .h file i want to Access Them is .c File Files..... to Be More Specific i am Creating a C++ Object in a C file... this Giving me the error!!! :( can Any Body Please Help me How to Access the C++ object in C file... Thanks In Advance :) "sachinv1821@gmail.com" <sachinv1821@gmail.com> writes: > How to Access the C++ object in C file... > Thanks In Advance :) You'd be better off asking in comp.lang.c++. I know this sounds...

How is "static const int" better than "static enum"?
can not the "static const int" be replaced by "static enum" anywhere? is it necessary that define special initialization syntax for "static const int"? Ajax Chelsea wrote: > can not the "static const int" be replaced by "static enum" anywhere? enum is a type, not a variable, so it needs no 'static' storage category. 'int' has an implementation-defined size, and its type is compatible with variable ints. 'enum' is only guaranteed to have enough bits to store any value used in their definition. For a while, compi...

Need to check file field for content in <cfinput type="file" name="custCartThumb">
With the following code, I get the "message" whether or not there is content in my filefield: function check_file_field() { var file_field = document.getElementById("custCartFile"); if(file_field.value.length == 0) { alert("You are required to select an Image"); return false; } else { return true; } } <cfinput type="file" name="custCartThumb"> <cfinput type="submit" name="submit" value="Add Image" onClick="return check_file_field()"> It's like the function does not detect if the cfinput...

Web resources about - Explanation needed for const int "error: variably modified ... at file scope." - comp.lang.c

Resources last updated: 3/30/2016 8:10:51 AM