Is enum a suitable way to implement a "local define?"

.

I can understand that, given that it's part of the worst part of
Windows. That means it's not representative.

All important libraries written in C are available in other languages,
so I don't see a desperate need for some new sort of API. There are
enough people who are able and willing to read C code.

/Jorgen

 

The C++ standard defines the term "variable" so that there is a
single word that applies to both references and non-references.
It's there purely for convenience, and has no bearing on the
terminology issue here.

Personally I don't see anything wrong with using the term
"variable". I agree it is used in several different ways, and it
does have more than one meaning depending on context. But these
ambiguities can be sorted out easily just by adding some
qualifying phrases, eg, "possibly non-modifiable variable".

Furthermore, when what we're talking about is compile time
properties, there isn't really a good alternative. The Standard
does define the term "object", but "object" is clearly wrong
here, because objects don't exist at compile time, only at
run time. This result is not some accident of wording but
spelled out quite explicitly in 6.2.4, "Storage durations of
objects". We might talk about "a declared identifier which
at runtime will designate an object" (perhaps of some particular
storage duration), but that seems rather cumbersone, does it
not? Even when people disagree on exactly what properties
a "variable" should have, I don't anyone really misunderstands
the term. If/when it's important to disambiguate the different
usages I think it's easy enough to do that.

 

Not exactly right. An address constant is a form of constant
expression, but it can't be evaluated at compile time. It is
evaluated before program execution begins but AFAIK it is not
required to be fixed even after linking is done. That is,
different runs of the same executable might produce different
values for an "address constant". I'm pretty sure the Standard
means for an address constant to have any particular value only
within a single execution of a compiled and linked program, not
necessarily for all executions (of the same program image).

 

I haven't heard the term "address constant" used so much outside
of S/360 (and successor) assembler programming.

For S/360 address constants, which may or may not generalize to
other systems, they can be either absolute or relocatable.
Absolute address constants don't change on relocation, and
relocatable ones do (maybe that is too obvious).

Pointer constant sounds more C-like to me.

The assembler stores the offset into the CSECT, the linker
updates that as it relocates it within the load module, and
program fetch updates again as it is being loaded into memory.

To get back to C, some things are required to be known at compile
time, and so compile time constants.

Among others, C doesn't require subtraction between pointers to
different objects to have a defined value. Subtracting two constant
pointers to different objects, then, should not be a compile time
constant, even though the compilers for some systems could
probably compute one. I presume C can compute a constant absolute
expression with pointers to the same object.

Another interesting feature of the OS/360 assembler that I haven't
known in others is that the relocation factor, in addition to the
usual 0 or 1, can also be -1 or 2. In C terms, you can compute
the value of -pointer, 2*pointer, or pointer1+pointer2 as an
address constant. C doesn't allow for that.

-- glen

 

<nit-pick> Some address constants (namely, null pointers) can be

"An _address constant_ is a null pointer, a pointer to an lvalue
designating an object of static storage duration, or a pointer to a
function designator; ..." (6.6p9). The phrase "address constant" is
italicised, indicating that this sentence constitutes the definition of
that phrase.

....

In C, address constants are not required to be absolute, nor are they
required to be relocatable - that's an implementation detail outside the
scope of the C standard.

I think it is - but "obvious" depends upon the reader.

The C standard says otherwise.

 

Right! I should have double checked before posting.

<counter-nit-pick>In most (okay, probably all) implmentations,
null pointer constants can be evaluated at compile time, but
I believe the Standard does not /require/ them to be evaluable
at compile time.</counter-nit-pick>

 

On Thu, 10 Apr 2014 19:36:53 +0000 (UTC), glen herrmannsfeldt

If primitive type or String and initialized by a constant expression,
the compiler can AND MUST fold it. See definition of 'constant
variable' (!) in 4.12.4, and 13.1p3 and 13.4.9, in Java 7 Language
Specification; I ass-u-me 8 is the same but haven't looked yet.

In particular 13.4.9 says this should be used for "only values which
truly are unlikely ever to change" and 13.4.10 shows a kludgy way to
make the initialization of an actual constant value a non-constant
expression and thus the variable not foldable.

This is similar to C++'s making a namespace-scope const integer object
initialized by constant expression into a constant itself. C++ doesn't
require this for floating-point on the theory that runtime (target)
floating-point may differ from the compiler. Java tried to require
IEEE floating-point everywhere but had to back off.

In order to resolve overloads and check types the java compiler
already requires that all classes and interfaces referenced from and
not defined in the set of source files processed in one compilation --
what I might loosely call 'net imports' -- must be available already
compiled in CLASSPATH, usually though not necessarily in library jars.
This means the needed 'static final' values are available.