Board index » cppbuilder » Why does this compile?

Why does this compile?


2004-12-03 05:53:52 AM
cppbuilder60
Hi,
Given a resource file named, "languages.rc," with the contents of:
STRINGTABLE
{
LANG_AFRIKAANS, "Affrikaans"
}
I can compile this file either from the IDE or the from command line:
brcc32 languages.rc
... and it will compile just fine. This is very strange since the value
'LANG_AFRIKAANS' is not yet defined in the file and no header files are
included. So, why does this compile? (It should complain that
'LANG_AFRIKAANS' is undefined via a message like, "expecting unsigned short
integer".)
I thought maybe brcc32 was including winnt.h (where LANG_AFRIKAANS is
defined) implicitly, but then discovered that some language ID values are
recognized, and others are not. For instance, this does NOT compile:
STRINGTABLE
{
LANG_AFRIKAANS, "Affrikaans"
LANG_ARMENIAN, "Armenian"
}
Both of the values above are defined in winnt.h, so they cannot be coming
from winnt.h implicitly. Can anyone explain this behavior?
- Dennis
 
 

Re:Why does this compile?

This is just a guess but perhaps brcc32.exe gets it from its call
to GetUserDevaultLangID.
. Ed
Quote
Dennis Jones wrote in message
news:41af8ef1$ XXXX@XXXXX.COM ...

Given a resource file named, "languages.rc," with the
contents of:

STRINGTABLE
{
LANG_AFRIKAANS, "Affrikaans"
}

I can compile this file either from the IDE or the from
command line:

brcc32 languages.rc

... and it will compile just fine. This is very strange since
the value 'LANG_AFRIKAANS' is not yet defined in the file
and no header files are included. So, why does this compile?
(It should complain that 'LANG_AFRIKAANS' is undefined
via a message like, "expecting unsigned short integer".)

I thought maybe brcc32 was including winnt.h (where
LANG_AFRIKAANS is defined) implicitly, but then discovered
that some language ID values are recognized, and others are
not. For instance, this does NOT compile:

STRINGTABLE
{
LANG_AFRIKAANS, "Affrikaans"
LANG_ARMENIAN, "Armenian"
}

Both of the values above are defined in winnt.h, so they
cannot be coming from winnt.h implicitly. Can anyone explain
this behavior?
 

Re:Why does this compile?

That's pretty wild guess, Ed, especially for you!
As it simply returns a default language ID for the current user, I hardly
see how GetUserDefaultLangID() could be used in any way that could impact
the compiler's ability to recognize resource identifiers that are not
defined.
But now that I think about it, which resource identifiers are recognized
implicitly may have something to do with code pages. Some languages are
defined within the context of a code page, and some are not (and Armenian is
one of them). That could explain it why some languages are implicitly
recognized and others are not, but that still does not explain from where
the compiler gets its set of "known" resource identifiers.
- Dennis
"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
This is just a guess but perhaps brcc32.exe gets it from its call
to GetUserDevaultLangID.

. Ed

>Dennis Jones wrote in message
>news:41af8ef1$ XXXX@XXXXX.COM ...
>
>Given a resource file named, "languages.rc," with the
>contents of:
>
>STRINGTABLE
>{
>LANG_AFRIKAANS, "Affrikaans"
>}
>
>I can compile this file either from the IDE or the from
>command line:
>
>brcc32 languages.rc
>
>... and it will compile just fine. This is very strange since
>the value 'LANG_AFRIKAANS' is not yet defined in the file
>and no header files are included. So, why does this compile?
>(It should complain that 'LANG_AFRIKAANS' is undefined
>via a message like, "expecting unsigned short integer".)
>
>I thought maybe brcc32 was including winnt.h (where
>LANG_AFRIKAANS is defined) implicitly, but then discovered
>that some language ID values are recognized, and others are
>not. For instance, this does NOT compile:
>
>STRINGTABLE
>{
>LANG_AFRIKAANS, "Affrikaans"
>LANG_ARMENIAN, "Armenian"
>}
>
>Both of the values above are defined in winnt.h, so they
>cannot be coming from winnt.h implicitly. Can anyone explain
>this behavior?



 

{smallsort}

Re:Why does this compile?

Quote
That's pretty wild guess, Ed, especially for you!
It's not a guess.
Quote
... That could explain it why some languages are implicitly
recognized and others are not, but that still does not explain
from where the compiler gets its set of "known" resource
identifiers.
It gets its list from its design. It's a tool. If you want to use
the tool, use it. If you want to go into the design of the tool,
decompile it.
. Ed
Quote
Dennis Jones wrote in message
news: XXXX@XXXXX.COM ...
 

Re:Why does this compile?

"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
>That's pretty wild guess, Ed, especially for you!

It's not a guess.

>... That could explain it why some languages are implicitly
>recognized and others are not, but that still does not explain
>from where the compiler gets its set of "known" resource
>identifiers.

It gets its list from its design. It's a tool. If you want to use
the tool, use it. If you want to go into the design of the tool,
decompile it.
Ed,
I think you're missing my point.
You are exactly right...the compiler is a tool -- and it is not supposed to
"know" anything about the code it compiles. It cannot and should not make
assumptions about the values of identifiers being compiled. For instance,
if I have:
STRINGTABLE
{
LANG_ENGLISH, "English"
}
then the value 'LANG_ENGLISH' must be defined in order for the compiler to
correctly interpret and compile this code, right? And if 'LANG_ENGLISH' is
not defined, then the compiler should complain that it does not recognize
the identifier, right? If it does anything else, it is making an assumption
about the value of 'LANG_ENGLISH'. So, what value will 'LANG_ENGLISH' have,
if I have not defined it?
Now, suppose I do this:
#define LANG_ENGLISH 0x1235
#define LANG_ENGLISH 0x1234
STRINGTABLE
{
LANG_ENGLISH, "English"
}
This yields an error; an error that the value 'LANG_ENGLISH' is already
defined and that the re-definition is not the same as the previous
definition. It is an obvious error, and it makes perfect sense. But what
about this:
#define LANG_ENGLISH 0x1234
STRINGTABLE
{
LANG_ENGLISH, "English"
}
If the compiler is making assumptions about the value of 'LANG_ENGLISH',
then this should also result in a re-defintion error, and yet it doesn't.
But why not? If the compiler is NOT making assumptions about the value of
'LANG_ENGLISH', the not defining 'LANG_ENGLISH' should result in some sort
of an "undefined identifier" error, and yet it doesn't.
If this makes sense to you, please explain it to me, because it is clearly
not doing what any reasonable person would expect it to.
- Dennis
 

Re:Why does this compile?

"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
>That's pretty wild guess, Ed, especially for you!

It's not a guess.
You said:
"This is just a guess but ..."
- Dennis
 

Re:Why does this compile?

"Dennis Jones" < XXXX@XXXXX.COM >wrote:
Quote
Given a resource file named, "languages.rc," with the contents of:

STRINGTABLE
{
LANG_AFRIKAANS, "Affrikaans"
}

I can compile this file either from the IDE or the from command line:

brcc32 languages.rc

... and it will compile just fine. This is very strange since the value
'LANG_AFRIKAANS' is not yet defined in the file and no header files are
included. So, why does this compile? (It should complain that
'LANG_AFRIKAANS' is undefined via a message like, "expecting unsigned short
integer".)
Firstly, it should be complaining about STRINGTABLE, no?
Quote
I thought maybe brcc32 was including winnt.h (where LANG_AFRIKAANS is
defined) implicitly, but then discovered that some language ID values are
recognized, and others are not. For instance, this does NOT compile:

STRINGTABLE
{
LANG_AFRIKAANS, "Affrikaans"
LANG_ARMENIAN, "Armenian"
}

Both of the values above are defined in winnt.h, so they cannot be coming
from winnt.h implicitly. Can anyone explain this behavior?
You're making interesting assumptions about the resource compiler. It is
not C, with a nice ISO standard defining what it does. (Although it
probably makes use of a C-like parser and preprocessor.) All we can do
is examine the behaviour and say, well, yes, it does what it does, so
presumably that's what it should do.
But even C allows predefined macros. My guess is that it's doing that
with common (or relatively common) values.
Alan Bellingham
--
Me <url:mailto: XXXX@XXXXX.COM ><url:www.doughnut.demon.co.uk/>
ACCU - C, C++ and Java programming <url:accu.org/>
The 2004 Discworld Convention <url:dwcon.org/>
 

Re:Why does this compile?

That was a typo. I have been composing in an editor and doing
cut and paste. What that was supposed to be was
"It's not a wild guess"
. Ed
Quote
Dennis Jones wrote in message
news:41b000b1$ XXXX@XXXXX.COM ...

>>That's pretty wild guess, Ed, especially for you!
>
>It's not a guess.

You said:

"This is just a guess but ..."
 

Re:Why does this compile?

"Alan Bellingham" < XXXX@XXXXX.COM >wrote in message
Quote
"Dennis Jones" < XXXX@XXXXX.COM >wrote:

Firstly, it should be complaining about STRINGTABLE, no?
Why should it complain about STRINGTABLE? It's a standard Windows resource
script keyword.
Quote
You're making interesting assumptions about the resource compiler.
What assumptions am I making? That it should complain about undefined
identifiers? Okay, perhaps it _is_ an assumption, but certainly not an
unreasonable one.
Quote
It is
not C, with a nice ISO standard defining what it does. (Although it
probably makes use of a C-like parser and preprocessor.) All we can do
is examine the behaviour and say, well, yes, it does what it does, so
presumably that's what it should do.

But even C allows predefined macros. My guess is that it's doing that
with common (or relatively common) values.
I could almost believe that, and that's about the only conclusion one could
come to based on the observed behavior, but it would be pretty risky, don't
you think? I mean, what happens if MS decides to change the value of any
one of those identifiers? After all, they are nothing more than #define's
in winnt.h, and if one of them changes, our C compiler would see one value
(based on winnt.h) and our resource compiler would see another (based on
it's own internal values). That's just asking for trouble.
Isn't there somewhere that defines the expected behavior for the resource
compiler? If they are going to pre-define certain values, shouldnt't that
(and the values) be documented somewhere?
- Dennis
 

Re:Why does this compile?

"Dennis Jones" < XXXX@XXXXX.COM >wrote:
Quote

"Alan Bellingham" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>"Dennis Jones" < XXXX@XXXXX.COM >wrote:
>
>Firstly, it should be complaining about STRINGTABLE, no?

Why should it complain about STRINGTABLE? It's a standard Windows resource
script keyword.
As, effectively, is LANG_AFRIKAANS. It's one of the documented values
for the language for a STRINGTABLE.
Quote
What assumptions am I making? That it should complain about undefined
identifiers? Okay, perhaps it _is_ an assumption, but certainly not an
unreasonable one.
That LANG_AFRIKAANS is an undefined identifier.
Quote
you think? I mean, what happens if MS decides to change the value of any
one of those identifiers?
Then Windows itself starts falling apart. It's about as sensible as
changing their minds over which opcodes their assembler will emit.
The point is, things like STRINGTABLE are used by programs to find a
particular resource type. And things like LANG_AFRIKAANS are used to
find particular resource _sections_.
Quote
After all, they are nothing more than #define's
in winnt.h, and if one of them changes, our C compiler would see one value
Are, I suspect those values in winnt.h exist so that your C/C++ code
knows what value to use to match resources generated by the resource
compiler. Not the other way around - you've already determined that
winnt.h isn't included by the resource compiler.
Quote
Isn't there somewhere that defines the expected behavior for the resource
compiler? If they are going to pre-define certain values, shouldnt't that
(and the values) be documented somewhere?
You can only read the documentation. Which states that LANG_AFRIKAANS is
a value known to the resource compiler.
Alan Bellingham
--
Me <url:mailto: XXXX@XXXXX.COM ><url:www.doughnut.demon.co.uk/>
ACCU - C, C++ and Java programming <url:accu.org/>
The 2004 Discworld Convention <url:dwcon.org/>
 

Re:Why does this compile?

"Alan Bellingham" < XXXX@XXXXX.COM >wrote in message
Quote
"Dennis Jones" < XXXX@XXXXX.COM >wrote:

>
>"Alan Bellingham" < XXXX@XXXXX.COM >wrote in message
>news: XXXX@XXXXX.COM ...
>>"Dennis Jones" < XXXX@XXXXX.COM >wrote:
>>
>>Firstly, it should be complaining about STRINGTABLE, no?
>
>Why should it complain about STRINGTABLE? It's a standard Windows
resource
>script keyword.

As, effectively, is LANG_AFRIKAANS. It's one of the documented values
for the language for a STRINGTABLE.
Okay, I think I see what you are saying here: That some LANG_xxxx
identifiers can be used to define the language for a particular STRINGTABLE,
as in the example below:
STRINGTABLE
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
{
...
And in this case, I think you are suggesting that some (though obviously not
all) LANG_xxxx and SUBLANG_xxxx identifiers are known by the compiler,
without the benefit of any #include's that may or may not be included that
could also define them.
This may very well be the case; although I am not certain it is a necessary
requirement for the compiler to know about those values. After all, one
could presumably do this:
STRINGTABLE
LANGUAGE LANG_ARMENIAN, SUBLANG_NEUTRAL
{
...in which case LANG_ARMENIAN would have to be #define'd anyway, to keep
the compiler from complaining (because it is not [apparently] a pre-defined
value). That being the case, it would seem to make better sense to require
all values to be #define'd, rather than (somewhat) arbitrarily pre-defining
certain values within the compiler itself.
Quote
The point is, things like STRINGTABLE are used by programs to find a
particular resource type. And things like LANG_AFRIKAANS are used to
find particular resource _sections_.
Yes, I see that now. I had not considered the fact that the language can be
defined for a particular string table.
Thanks,
- Dennis
 

Re:Why does this compile?

"Dennis Jones" < XXXX@XXXXX.COM >wrote:
Quote
Yes, I see that now. I had not considered the fact that the language can be
defined for a particular string table.
Yup.
Why LAN_AFRIKAANS is known (without winnt.h), and LANG_ARMENIAN isn't
one, I don't know.
Alan Bellingham
--
Me <url:mailto: XXXX@XXXXX.COM ><url:www.doughnut.demon.co.uk/>
ACCU - C, C++ and Java programming <url:accu.org/>
The 2004 Discworld Convention <url:dwcon.org/>
 

Re:Why does this compile?

Alan Bellingham wrote:
Quote
Why LAN_AFRIKAANS is known (without winnt.h), and LANG_ARMENIAN isn't
one, I don't know.
Armenian might be newer.
If you pull up WIN32.HLP, select the Find tab, and type LANG_
you will find Afrikaans, but not Armenian.
I would hazard a guess that all the languages listed are "known" to
the compiler.