Subj : Re: Win98 error
To   : borland.public.cpp.borlandcpp
From : maeder@glue.ch (Thomas Maeder [TeamB])
Date : Sat Mar 13 2004 06:07 pm

Bob Gonder <notbg@notmindspring.invalid> writes:

> Thing is, it isn't an int, it's a scalar.

The type of 100 is int.


> And if you say it's an int, doesn't the compiler treat it as an int,
> with all the demotion/promotion/signedness problems of ints?

I don't see a difference in how the macro and the const version of nmax are
treated.


> I kinda like the macro's capability to be any type/size
> 	long	L;
> 	int	i;
> 	short	s;
> 	DWORD	d;
> 	if( anyoftheabove < macrovalue )
> doesn't complain about comparing signed and unsigned values.

A decent compiler "inlines" const ints. Consequently, it shouldn't complain
in such cases.


> Also doesn't need to promote, say s to an int.

s will be promoted for comparison to both the macro and the const version of
nmax.


> At least, thats what I
> would assume that "const int c" would mean compare int c to short s

As I said above, 100 is of type int. Where do you see a difference?


> Yeah, I searched for several weeks or maybe months for a "private"
> keyword so my local routines wouldn't clash with same-named locals in
> other modules.... Static... who'da thunk it?  (I also tried to find
> the "public" equivalent as ASM is Private unless declaired Public, so
> logicaly, C should be too.)

This is the most "violent" case. Consequently, the ISO C++ Standard committee
invented unnamed namespace for this. Instead of

// file.cpp

static int i(10);


, one would nowadays do

namespace
{
  int i(10);
}


, which makes much more sense. The name of the variable i now has a name
which is "unutterable" in different translation units (.cpp files). Even if
another translation unit contains the same variable definition, the two
variables don't clash.

.