Thanks to all for your responses. They helped to clarify this for me.
> Long answer: how could this possibly work? In order to exclude such a
> string resource, the system would need to prove that the resource is
> unreferenced by any code. But due to the loose coupling between code and
> resources, it's trivial to give an example that shows that no such proof
is
> practical.
I see... The compiler is really out of the loop.
OK: Resources are a nice thing. But, now we want "smart resources"! :-)
-----Steve Jackson
P.S. Here's one idea:
NEW COMPILER OPTION: "SMART RESOURCE HEADERS"
---------------------------------------------
A new compiler option controls how resource headers are handled:
- "Normal" setting: All resource header file symbolic names are included in
the compile. This is the status quo.
- "Smart" setting: Only specified resource header file symbolic names are
included in the compile. The symbolics to be included are specified
one-at-a-time in a #pragma in each .c source file in which they are used (or
in a .h file).
- To distinguish "resource header files" from the others, they would have a
different file name extension like .rsch (e.g. MyResourceHeader.rsch). The
compile would perform this "header pre-processing" on only these files when
the "smart" compiler option is specified. With the "normal" settings, they
would be processed like any other .h file.
PRAGMA: "INCLUDE RESOURCE SYMBOLIC NAME"
----------------------------------------
A new pragma would specify that a specific resource symbolic name is to made
available for use in the compile. Without the pragma, the symbolic name is
not available and a compile error occurs. This new pragma only has an effect
if the "smart" compiler option is used.
#pragma include_resource <resource_symbolic>
Example:
#pragma include_resource MyString
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
