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

[James Kuyper]

On 04/09/2014 09:32 AM, David Brown wrote:
....

You can't get file scope with internal linkage without using "static".

File scope isn't minimal; it's the largest scope available. And "no
linkage" is more minimal than "internal linkage".

 

[James Kuyper]

On 04/09/2014 09:38 AM, David Brown wrote:
....

I don't think BartC is a troll, and I think he raises some interesting
points. Sometimes he misunderstands parts of C, and is quick to suggest
improvements or extensions when the issue is actually already covered in
C, or when they would conflict with key features of C. When that
happens, my aim is to help him - just as others here have helped me when
I have had questions or got things wrong.

I've found BartC's messages annoying, sufficiently so that I've
considered adding him to my message filters - but I don't think "troll"
is a correct description for the reason I'm annoyed by those messages.

He has his own ideas about what a good programming language is like,
which embody a very different philosophy that that used to design C. He
is working to implement those ideas in C. None of that would be a
problem, except that:

* He doesn't know C well enough to do a good job of implementing his own
language. That makes it a very odd choice, unless it's the language he
understands best, it which case it's odd that he feels competent to
design his own language.

* Many of his criticisms of C reflect his ignorance of the language.

* He tends to think of his own language design preferences as being
superior to the conflicting preferences behind the design of C, rather
than being simply alternative preferences. There's room in the IT world
for many different languages with many widely different styles; his
criticisms are seldom worded in a way that reflects awareness of that fact.

* Most annoying, he'll frequently say things that are actually about his
language, in contexts where any reasonable person, knowing this is
"comp.lang.c", would expect his comments to be referring to C. Often,
the only clue that he's not talking about C is that his comments don't
correctly describe C - but that's unfortunately not a reliable way of
distinguishing them from his comments that are actually intended to be
about C.

 

[glen herrmannsfeldt]

On 09/04/14 01:39, James Kuyper wrote:
(snip)
changing the standard now to cleanly separate the two concepts

I thought it was four or five, but I haven't been counting.
But most of them don't have the meaning that "static" should
have.

(big snip)

I like to think of "static" as meaning "static allocation", i.e., a
fixed address and lifetime throughout the program, and minimal scope and
linkage. Although that combines two different concepts in one keyword,
it applies to both file scope and block scope "static" - and I think
that reduces the confusion a little.

I usually use static for look-up tables, that is, initialized
arrays. Partly that is from the K&R days where auto arrays couldn't
have initializers.

It probably is true on many current processors that access to
stack (auto) data is faster than static, but then the auto
array has to be reinitialized (copied from somewhere) on each
entry to the function.

(snip)

I would have preferred "static" to mean only the static allocation part,
that internal linkage was the default in C, and that an extra keyword
(such as "export" or "public") would be needed to give an object or
function external linkage. Defaulting to global external linkage was a
fundamental error in the C language design, IMHO. But it is too late to
change now.

Well, in other languages it is something like "external" that
gives external linkage. I was never quite sure where the funny C
rules on "extern" came from, as other languages don't have that rule,
and still manage to work. Well, partly it is a side effect of
static variables always being initialized.

-- glen

 

[Stephen Sprunk]

I usually use static for look-up tables, that is, initialized arrays.
Partly that is from the K&R days where auto arrays couldn't have
initializers.

It probably is true on many current processors that access to stack
(auto) data is faster than static,

The top of the stack is almost certainly in cache whereas the static
data won't be unless you've used it recently, but OOO mechanisms on most
"current processors" should be able to hide that difference.

If both are in (or both out) of cache, though, access speed should be
identical unless your lookup tables are stored in ROM or Flash, which is
a whole 'nother matter entirely.

S

 

[Kaz Kylheku]

I don't think BartC is a troll, and I think he raises some interesting
points.

BartC seems to be here to discuss the features of some other language than C,
which he is working on, with the evident side goal of avoiding learning C as
much as possible while proposing improvements to it.

No concrete, complete spec of the other language is ever given, so it is
impossible to discuss properly; this aspect keeps the discussions
quasi-topical, allowing the focus to stay on BartC's years-long learning
disability with regard to C.

BartC is somewhat like a higher-level Bill Cunningham.

(And note how the initials of both characters are B.C.!)

There are strong parallels in the trolling theme: a person who is toying with
some projects that don't seem to advance from year to year (as far as we can
glean their status from the fleeting descriptions), and who exhibits
anterograde amnesia with regard to absorbing new material from other posters.

 

[Ben Bacarisse]

"const" is not a hint to the compiler about variables - it is a
specific direction that this object will be constant, and will never
be changed. (It is /possible/ to do so using casts, but the result is
clearly undefined behaviour, and cannot be achieved by accident due to
the explicit casts needed, and all the compiler error messages and/or
diagnostic warnings.)

That's largely true, but there are a few "holes" in the type system.
You *can* modify a const object without any casts, for example like
this:

const int c = 0;
int *ip = memchr(&c, 0, 1);
*ip = 42;

The result is still undefined, of course, but you do sometimes see bugs
caused by the inadvertent loss of const this way.

By the way, I agree with what you are saying overall and const vs. a new
constant declaration. The whole trend on modern programming language
design is towards clever compilers and expressive languages.

<snip>

 

[Ian Collins]

That's largely true, but there are a few "holes" in the type system.
You *can* modify a const object without any casts, for example like
this:

const int c = 0;
int *ip = memchr(&c, 0, 1);
*ip = 42;

C++ had to go through a few hoops to fix this particular library bug!

 

[Kaz Kylheku]

C++ had to go through a few hoops to fix this particular library bug!

I believe C added holes to void * when it was borrowed from C++.

The fix is simple: don't allow conversions out of void * without a cast.

No big hoop.

 

[Ben Bacarisse]

I believe C added holes to void * when it was borrowed from C++.

The fix is simple: don't allow conversions out of void * without a
cast.

The makes the hole smaller, but the problem is that various library
function strip the const qualifier from the returned pointer. Simply
removing void * from the language would not be enough if functions like
strchr still return at char * rather than a const char *. You'd only be
able to modify a char object without a cast, but the hole would still
not be closed.

 

[David Brown]

On 09/04/14 13:27, James Kuyper wrote: [...]

It was a mistake to use the same keyword for making both kinds of
distinctions - it causes frequent confusion - and I think that trying to
create a merged concept that justifies that mistake is a further mistake.

I agree that the two concepts should not have been mixed (as noted in
the part of my post that you snipped here). So I am not trying to
justify it - I am just trying to give a meaning to the "static" keyword
which covers its practical effects. I have found it helpful in the past
when answering the common question "what does "static" mean in C?", so I
repeated it here in case other people found it helpful.

An object defined within a function definition has block scope,
automatic storage duration, and no linkage by default. The "static"
keyword changes the storage duration from automatic to static,
without affecting the scope or linkage.

An object defined outside any function definition has file
scope, static storage duration, and external linkage by default.
The "static" keyword changes the linkage from external to internal,
without affecting the scope or storage duration.

I don't think there's any reasonable way to view those as a single
meaning.

I am aware of the technical standards-language details here, and I agree
that the two cases can't be combined at that level. But most C
programmers don't understand about linkage - they just know that some
data can be accessed from other C files, and some cannot. It can be
helpful to give such inexperienced programmers an idea that links the
two uses of "static" - it helps familiarise them with the keyword and
its uses. I am not suggesting it as an accurate definition.

So if you don't like the explanation of "static" that I gave, that's
fine. If someone relatively new to C finds it helpful in getting to
grips with some of C's concepts and keywords, then that's fine too.

 

[Malcolm McLean]

Without the application of "const" in any shape or form it has a very
well defined meaning. The clue is in what "variable" means and in
addition to that real humans are capable of understanding what someone
means when they say "a constant int" for example.

But programmers also say "that variable is a constant".
It's referenced by a symbol rather than a raw value, but the value doesn't change during the lifetime of
the program. However it might change if the program is compiled with different settings.

 

[James Kuyper]

On 04/10/2014 05:03 AM, David Brown wrote:
....

I am aware of the technical standards-language details here, and I agree
that the two cases can't be combined at that level. But most C
programmers don't understand about linkage - they just know that some
data can be accessed from other C files, and some cannot. It can be
helpful to give such inexperienced programmers an idea that links the
two uses of "static" - it helps familiarise them with the keyword and
its uses. ...

That's the key point of disagreement - I don't think it can be helpful.
I think it would be far more helpful to teach them how to clearly
distinguish the two meanings. That means you'll have to teach them not
only about linkage and storage duration, but also about scope, since
that's what determines which of the two meanings applies. That is a lot
to learn for a beginner - but those three topics are also very important
things that a beginner should learn about fairly early.

 

[David Brown]

The top of the stack is almost certainly in cache whereas the static
data won't be unless you've used it recently, but OOO mechanisms on most
"current processors" should be able to hide that difference.

That's true - but if you are initialising the stack table, you need to
copy all the data from a source into the stack. The source is unlikely
to be in cache in advance, so this copying will take some time.

 

[David Brown]

On 04/10/2014 05:03 AM, David Brown wrote:
...

That's the key point of disagreement - I don't think it can be helpful.
I think it would be far more helpful to teach them how to clearly
distinguish the two meanings. That means you'll have to teach them not
only about linkage and storage duration, but also about scope, since
that's what determines which of the two meanings applies. That is a lot
to learn for a beginner - but those three topics are also very important
things that a beginner should learn about fairly early.

Maybe you are right here. Which method is the most helpful at any given
time will vary, but I will consider your points next time the occasion
arises. Giving people a single sort-of explanation of "static" has
helped in the past, but as they say "past performance is no guarantee of
future results"

 

[Keith Thompson]

On 09/04/14 13:27, James Kuyper wrote: [...]
It was a mistake to use the same keyword for making both kinds of
distinctions - it causes frequent confusion - and I think that trying to
create a merged concept that justifies that mistake is a further mistake.

I agree that the two concepts should not have been mixed (as noted in
the part of my post that you snipped here). So I am not trying to
justify it - I am just trying to give a meaning to the "static" keyword
which covers its practical effects. I have found it helpful in the past
when answering the common question "what does "static" mean in C?", so I
repeated it here in case other people found it helpful.

An object defined within a function definition has block scope,
automatic storage duration, and no linkage by default. The "static"
keyword changes the storage duration from automatic to static,
without affecting the scope or linkage.

An object defined outside any function definition has file
scope, static storage duration, and external linkage by default.
The "static" keyword changes the linkage from external to internal,
without affecting the scope or storage duration.

I don't think there's any reasonable way to view those as a single
meaning.

I am aware of the technical standards-language details here, and I agree
that the two cases can't be combined at that level. But most C
programmers don't understand about linkage - they just know that some
data can be accessed from other C files, and some cannot. It can be
helpful to give such inexperienced programmers an idea that links the
two uses of "static" - it helps familiarise them with the keyword and
its uses. I am not suggesting it as an accurate definition.

If most C programmers don't understand linkage, then they need to learn.

So if you don't like the explanation of "static" that I gave, that's
fine. If someone relatively new to C finds it helpful in getting to
grips with some of C's concepts and keywords, then that's fine too.

I honestly fail to see how any explanation of the two meanings of
"static" that doesn't (a) acknowledge that the two meanings are entirely
different, and (b) explain what those two meanings are could be useful.

Hypothetically, if C used two different keywords for the two uses, would
you even consider trying to explain them as if they were a single
concept?

 

[glen herrmannsfeldt]

(snip)

I honestly fail to see how any explanation of the two meanings of
"static" that doesn't (a) acknowledge that the two meanings are
entirely different, and (b) explain what those two meanings
are could be useful.

Hypothetically, if C used two different keywords for the two uses,
would you even consider trying to explain them as if they were
a single concept?

Why use words instead of random combinations of meaningless letters?
(Well, I don't know about non-english speakers, who might consider
them meaningless.) The words are supposed to remind us of the
meaning and use for that keyword. If a keyword has a meaning
unrelated to its normal meaning (or even CS meaning) that is
confusing to users.

-- glen

 

[James Kuyper]

On 04/10/2014 12:36 PM, glen herrmannsfeldt wrote:
....

meaning and use for that keyword. If a keyword has a meaning
unrelated to its normal meaning (or even CS meaning) that is
confusing to users.

That's precisely why using "static" to give an identifier "internal
linkage" was a bad idea - but the deed has been done, the need to
maintain backwards compatibility prevents fixing it, so now we have to
deal with it.

 

[Seungbeom Kim]

It's not entirely clear what the word "variable" should mean in C. The
standard doesn't use the term;

It's interesting to find out that C never defines the term.
I thought that C defined it in an analogous way to how C++ defines it:

"A /variable/ is introduced by the declaration ((of a reference
other than a non-static data member or)) of an object.
The variable’s name denotes the ((reference or)) object."

excluding the irrelevant parts about references (marked with (( )) by me),
of course. So a key feature of a variable would be a named, declared thing.

instead it uses "object".

With the definition discussed above, they are not the same;
e.g. malloc(1) would create a char-sized object but not a variable.

[...] mine is that I avoid
using the word "variable" when there's any chance of confusion.

I agree that using the term "object" is sufficient in many cases.

 

[James Kuyper]

It's interesting to find out that C never defines the term.
I thought that C defined it in an analogous way to how C++ defines it:

"A /variable/ is introduced by the declaration ((of a reference
other than a non-static data member or)) of an object.
The variable’s name denotes the ((reference or)) object."

excluding the irrelevant parts about references (marked with (( )) by me),
of course. So a key feature of a variable would be a named, declared thing.

More precisely, it is a named, declared object.

Most occurrences of "variable" in the C standard are as an adjective,
but every use of the term "variable" as a noun in the C standard is
consistent with the C++ definition. However, most of the time the C
standard uses "variable" in ways that would also apply to unnamed
objects, so perhaps in C, "variable" is simply a synonym for "object"?

I've informally adopted the C++ definition even in C contexts. I admit,
it's a bit counterintuitive to describe something as "variable" even if
it happens to be a constant.

 

[Kaz Kylheku]

It's interesting to find out that C never defines the term.
I thought that C defined it in an analogous way to how C++ defines it:

"A /variable/ is introduced by the declaration ((of a reference
other than a non-static data member or)) of an object.
The variable’s name denotes the ((reference or)) object."

ANSI Common Lisp uses "variable", and nonchalantly introduces the
oxymoron "constant variable" as a normative term in its glossary:

constant variable n. a variable, the value of which can never change; that is,
a keyword or a named constant. ``The symbols t, nil, :direction, and
most-positive-fixnum are constant variables.''

Cringe-inducing abuse of English. As adjectives, "constant" and "variable" are
diametric opposites. To be constant is not to vary.