This is interesting, but no problem in my special case, since the
large tables are inside a function and are not visible to outside callers.
So there can be no mixture of const and no-const.
The outside callers specify key information, the function looks up the
relevant information in the large tables (which is supposed to be
handled very fast),
and then the answer is returned through the function interface.
We also have "slower" and yet larger tables, which reside in files or DB
tables
(or data spaces using some third party piece of management software),
but those "fast" tables are used very often during computation;
the application is insurance math.
Kind regards
Bernd
Am 24.08.2012 14:40, schrieb Paul Gilmartin:
What the ANSI standard says.
On Fri, 24 Aug 2012 12:37:05 +0200, Bernd Oppolzer wrote:
we have some modules written in C that have large arrays with constants.
For some reasons we are forced to compile those modules using the RENT
compiler option, which moves those arrays to the WSA (writable storage
area)
at runtime, which is not a desired behaviour, because this way, the
storage is
occupied twice - once �n the WSA and second in the initialization area
in the
STATIC CSECT - and there is coding needed at startup to move the constants
into the WSA.
We are not able to move to NORENT due to site conventions.
Now my question: is it sufficient to mark those arrays with the const
attribute,
that is
static const double tab [100000] = { ... values follow ... };
or are there special #pragmas needed to prevent this table from being
moved to the WSA, given the RENT compiler option?
Years ago, I investigated such behavior with an ISV compiler, not
IBM's. In that case, yes, if an object was declared const it was not
moved to writable storage area. I looked further at the ANSI
standard which says, IIRC, that if an object is declared const in
one translation unit and declared not const in another translation
unit (of course you would _never_ do that), and the latter modifies
the object, the result is undefined. It stated no restriction if the
object is never modified. I concluded that the ISV compiler might
be stretching the standard by allowing the two translation units to
refer to different instances of the object. I didn't press the point.
But an object declared static shouldn't be accessible by name
from more than one translation unit.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
