Hi, Wim Veldhuis!
On 29 Jun 97  23:40:30 you wrote to Thomas Maeder
 BM> #define WHEEL_MAX 13
 BM> #define STARTING_CASH 300
 TM> Better write
 TM> const unsigned int WHEEL_MAX = 13;
 TM> const unsigned int STARTING_CASH = 300;
 TM> The compiler will treat values defined like this exactly  as
 TM>  if  they had been #defined, but without the bad
 TM> implications #define can have.
 WV> This is not entirely correct. Compilers usually allocate memory for
 WV> something declared as const ...
What compilers do that?  I tried a plenty (MS, Borland, Sym, Watcom, SUN, HP)
and didn't notice that.  They allocate memory if you comile in C (!) mode but
not in C++.  Unless you happen to reference the address of the const that is
not very likely for an int constant as above.
The difference is that a const int is global by default in C but static in
C++. So if the compiler see it's not used it will not create it and it can
place the value on reference.   (Interestingly in BC 3.1, C mode even a
static const int will be treated as regular int, not inlined.)
 WV> This can result in warnings if you do
 WV> this inside a header file and you compile another module which uses
 WV> the headerfile but doesn't use the constant.
I have a plenty of such const int's in headers and have no warnings. Hm?
 WV> The obvious solution with
 WV> using extern, which makes sure only one actual memory spot is
 WV> allocated, and which avoids also errors from the linker in some cases.
That applies for non-consts. (Another solution may be enabling COMDEFS for
global data.)
 WV> In segmented programs there is also a gotscha's if you put initialised
 WV> data in a non default segment for some reason. At least with the
 WV> borland compiler this results in errors as it ALWAYS assumes const
 WV> variables to be in the default data segment !
Which version and path level? Probably a serious bug.
Paul
... Error 144: Bit bucket overflow.
--- OS/2 Warp
---------------