RE: Compiling GCC With a C++ Compiler (g++)

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: gcc-owner On Behalf Of Dave Korn
> Sent: 13 October 2004 14:45

>   If you pass a pointer to a struct as an argument to a 
> function, and there
> is a field in the struct that is declared const, the compiler 
> is liable to
> assume that the value of that field cannot be modified by the called
> function and cache it in registers or stack slots across the 
> function call,
> or perhaps make assumptions about known values in the field, 
> that would
> become invalid if the callee casts away the constness and modifies the
> field.  
> 
>   This is a real bug and I've had it happen to me in 
> real-world code[*].

... which I eventually worked around in an even more horrible way.

  The problem was in refactoring a huge amount of legacy code that used a
vast number of global variables.  To try and modularise and data-hide it
somewhat I wanted them all to become local to a single module, with accessor
functions visible to the rest of the application.  So I declared them all
"extern CONST" in a header file.  When a client module wanted to include the
header file, it got CONST defined as "const", but when the same header was
included by the module that instantiated the variables, CONST was defined to
nothing.  This allowed me to simulate protected class member variables, but
had the aforementioned consequence on the optimiser.

  The workaround was to declare them volatile as well as const to the client
modules.  Evil, I know, but it did the job; and in some sense, it's valid to
represent those variables to the rest of the application as
read-only-but-unpredictably-changing, a bit like a hardware register.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....