Why connot declare a static member of STRUCT or UNION?

[jameskuyper]

I already did. It's above.

a) I don't see any currently defined meaning for static that is
identified as the starting point for your extension.
b) I don't see any description of how your new meaning is
interpretable as an extension of that current meaning.
c) I don't see any argument explaining why this particular extension
is uniquely obvious.

All I see is a new meaning being proposed for the keyword static,
which already has too many distinct meanings.

I also pointed out that I am not talking about any "existing
documentation of static", just that it does not take a degree in CS to
come to a relatively easy deduction of what a static field in a struct
*might* mean in some alternative universe.

Sure, it's easy to come up with a wide variety of possible meanings.
It's the obvious uniqueness of that particular way of extending the
meaning that I'm disputing.

Possibly you have a much more detailed view of what static might mean -

I know several meanings of static in C, none of which has a non-
problematic application if extended to cover structure members
separately from the structures they are members of. I know of a
different unrelated meaning of the word static in C++, which does
apply in that context, but it cannot be usefully transferred to C
unless we either add a gratuitous incompatibility with C++, or add
other C++ features to C in addition to static membership. It's those
other C++ features (scope resolution operator and member functions)
that make static membership useful in C++. I would not favor making
such changes to C.

 

[Richard]

a) I don't see any currently defined meaning for static that is
identified as the starting point for your extension.

I dont play word games. It is clear enough what I meant reading back. As
I said this is nothing to do with C++ or what the specs say now.

A static member of a struct has a blindingly obvious "simple"
meaning. Once you have understood that then you can explain why my
"simple" meaning can not ever work and why I am being a dumb arse to
suggest it is that simple.

I see you snipped my basic description of what I considered it *could*
mean.

I am more than a tad confused as to your apparent difficulty with what
is a merely hypothetical discussion.

 

[Richard]

As someone who doesn't use C++, my first thought is that this would be
more like a strict "const" than "static". Or do you mean that it
would be modifiable and all instances see the current value, effectively
a new kind of global variable?

-- Richard

Are we off on a tangent now? it's easy to do. I am referring to a static
structure member. e.g a field in a struct where the field is a
static. Note for those tempted to drop in late here : read rest before
hopping in saying "that is not what the spec says" please :-;

 

[Ben Bacarisse]

Specifically we might consider the cases of static as applicable for
file scope and block scope objects.

To me only the case of block scope makes much sense.

file.h:

struct foo {
int x;
static int y;
};

file.c:

#include "file.h"

/* within some function/block */
struct foo bar;

In this case bar.y should retain it's value as any other block scope
static object.

What is the point? Your idea is essentially the same as:

struct foo {
int x;
};

static int struct_foo_y;

but one can access the variable foo_y with an unhelpful name (i.e. via
an object to which it does not really belong).

 

[Kenny McCormack]

(someone else)

We would have to beg to differ. It appears fairly clear to me what would
be meant by a static structure field if such existed in C.

It's another one of those "feigned ignorance" things that are so
popular here. If you want to maintain that everything that is known is
covered by your book, then you must maintain ignorance of things outside
the book.

I.e., you are not allowed to discriminate between the various flavors of
non-existence that a thing might have.

 

[Peter Pichler]

Richard Tobin wrote:

[regarding 'static' members of structs and unions, illegal in C]

As someone who doesn't use C++, my first thought is that this would be
more like a strict "const" than "static". Or do you mean that it
would be modifiable and all instances see the current value, effectively
a new kind of global variable?

<OT>
That's how it works in C++. It is often used for instance counters.
</OT>

 

[Richard Heathfield]

Peter Pichler said:

Richard Tobin wrote:

[regarding 'static' members of structs and unions, illegal in C]

As someone who doesn't use C++, my first thought is that this would be
more like a strict "const" than "static". Or do you mean that it
would be modifiable and all instances see the current value, effectively
a new kind of global variable?

<OT>
That's how it works in C++. It is often used for instance counters.
</OT>

Many years ago, I was helping a friend (we'll call him "Carl", since that
wasn't his name) to design a C++ program. He was a university student at
the time. As it happens, he was in the process of designing a "student"
class, and I was acting in the capacity of sounding-board. We had recently
discussed data hiding, and the importance of ensuring that a class "knows"
only information that is relevant to it.

Carl observed that it would be useful to have a static member in the
"student" class that kept track of the number of students. I suggested
that this might not be a good idea, but he remained unconvinced.

"Carl", said I, "what do you do for a living?"

"Well, I don't, yet. I'm a student; you know that already", says Carl.

"Where are you a student, Carl?"

Carl instantly spotted the maieutic approach (he was used to it by now),
and sighed. "<foo> University", he replied.

"How many students are there at <foo> University, Carl? What is the exact
number?"

"Dashed if I know", he bowdlerised.

"I rest my case", said I.

Students don't know how many students there are. Dogs don't know how many
dogs there are. Cars don't know how many cars there are. Static class
instance trackers are a design flaw.

 

[Charlie Gordon]

...

I'm not sure I follow you. The "meaning" seems clear enough to me. All
structures share a common field value across all instances of that
structure.

And where and when is that common field allocated?
And consider:
struct s {static int member;};
struct s ar[10];
what is "sizeof ar"?

So what ?

consider:

struct s { char buf[0]; };
struct s ar[10];

what is ``sizeof ar'' ?

 

[Ian Collins]

And where and when is that common field allocated?

In the case of C++, somewhere other than in the struct.

And consider:
struct s {static int member;};
struct s ar[10];
what is "sizeof ar"?

The same as

struct s {};
struct s ar[10];

 

[Peter Pichler]

Students don't know how many students there are. Dogs don't know how many
dogs there are. Cars don't know how many cars there are. Static class
instance trackers are a design flaw.

Excellent point!

I never said it was a good design. Only that it is often used that way.

No, I personally have never used it in my programs. Never found the
need. Thanks to RH for an explanation why.

 

[Richard Tobin]

Students don't know how many students there are. Dogs don't know how many
dogs there are. Cars don't know how many cars there are. Static class
instance trackers are a design flaw.

If you regard the "static" value as a property of a student, then you
are right. But if you consider a property of the class of students,
it makes reasonable sense. The class of students may know how many
instances it contains. It's then just a syntactic infelicity that you
write it as if it were a property of the instance.

-- Richard

 

[Richard Heathfield]

Richard Tobin said:

If you regard the "static" value as a property of a student, then you
are right. But if you consider a property of the class of students,
it makes reasonable sense. The class of students may know how many
instances it contains.

Ask any professor whether his class of students knows *anything*, and
you'll get a very bitter reply.

Seriously, the acceptance of classes as entities that can possess
information leads to a paradigm clash, at least in my opinion. Objects are
entities, but classes are merely types of entities.

It's then just a syntactic infelicity that you
write it as if it were a property of the instance.

I would see it not merely as infelicity but, perhaps, *infidelity* to the
object paradigm.

It is certainly true that *someone* (or, in computer programming terms,
some thing) knows how many students there are, but he or she is normally
called a dean or bursar or something like that - i.e. some kind of manager
object.

 

[Richard Tobin]

Seriously, the acceptance of classes as entities that can possess
information leads to a paradigm clash, at least in my opinion. Objects are
entities, but classes are merely types of entities.

There is a long tradition of classes being objects themselves. Rather
than a paradigm clash, it's a unification: *everything*'s an object.
(Search for "meta-object protocol" for lots on this.)

It is certainly true that *someone* (or, in computer programming terms,
some thing) knows how many students there are, but he or she is normally
called a dean or bursar or something like that - i.e. some kind of manager
object.

I agree that most often you would probably want to know something like
how many students there were in a university or a department, in which
case the number of instances of the student class would probably not
be appropriate.

-- Richard

 

[Chris Dollin]

Richard Tobin said:


Seriously, the acceptance of classes as entities that can possess
information leads to a paradigm clash, at least in my opinion.

Why? Programming is about incarnating abstract ideas -- often, but no
inevitably, models of the so-called "real world" -- as manipulable
thingies [1] ...

Objects are entities, but classes are merely types of entities.

.... which in turn can be incarnated in programs. Being able to work
at the meta-level is both important and convenient.

I would see it not merely as infelicity but, perhaps, *infidelity* to the
object paradigm.

It is certainly true that *someone* (or, in computer programming terms,
some thing) knows how many students there are, but he or she is normally
called a dean or bursar or something like that - i.e. some kind of manager
object.

That "manager object" doesn't need to know how many students there
/are/, just how many they /manage/.

If "count of all existing students" is interesting to the application,
then the class `Student` is, on the face of it, the /only/ right place
for it to go. (Assuming we're in a class-oriented programming language,
that is [3].)

[1] I'd say "objects" but that term has been overloaded [2].

[2] That one, too.

[3] I say "class-oriented" because IMAO that's a better description of
what languages like Java and C++ are; they're about the construction
of classes. The /objects/ don't do much more than languages like
C allow. Contrast Javascript and Ruby, where you can dink around
with what the individual objects do, without having to dance around
a class system. At this time, I make no claims about which strategy
[would] get better results [4]; I'm just picking at the terminology.

[4] Anyone who cares can probably find out.

 

[James Kuyper]

I dont play word games. It is clear enough what I meant reading back. As

I agree: this is clear:

> All structures share a common field value across all instances of that
> structure.

What isn't clear is why you consider this a "blindingly obvious" meaning
for a static member declaration.

I said this is nothing to do with C++ or what the specs say now.

A static member of a struct has a blindingly obvious "simple"
meaning.

I can't see those two statements as consistent. If the new meaning has
nothing to do with any previously defined meaning for 'static', why in
the world do you consider it a "blindingly obvious" meaning?

Once you have understood that then you can explain why my
"simple" meaning can not ever work and why I am being a dumb arse to
suggest it is that simple.

I never said it couldn't work.

I said that it violates the C object model and unnecessarily adds a new
meaning to a keyword that is already overworked. I also pointed out that
it must either create a gratuitous incompatibility with C++, or require
borrowing some fairly complicated features of C++, or be completely
useless. I've also pointed out that the "gratuitous incompatibility"
option (accessing the static member through the member selection
operator '.') would create a feature of only marginal usefulness, since
it adds little or no value compared to the currently available option of
declaring a static variable outside of the structure.

It certainly could work.

 

[John Bode]

As someone who doesn't use C++, my first thought is that this would be
more like a strict "const" than "static". Or do you mean that it
would be modifiable and all instances see the current value, effectively
a new kind of global variable?

That's the C++ usage (modifiable, all instances see the current
value), and that's how Richard's using the term.

To me, the right answer to the OP is "if you want C++, use C++."

 

[Richard Heathfield]

[This article has no footnotes. Feel free to write your own.]

Chris Dollin said:

Richard Heathfield wrote:


Why?

How does "because I say so" grab you?

Programming is about incarnating abstract ideas -- often, but no
inevitably, models of the so-called "real world" -- as manipulable
thingies [1] ...

Sure, but to make them manipulable you have to write down their state
somewhere (so that you can change it). Which means you need storage. Which
means you're talking objects.

... which in turn can be incarnated in programs. Being able to work
at the meta-level is both important and convenient.

Yes, but rather than give a class knowledge about its instances, I would
far rather give a specific object (possibly and even probably an object of
a different class) the necessary knowledge.

That "manager object" doesn't need to know how many students there
/are/, just how many they /manage/.

Well, that's exactly right, and very often that's the information that's
actually needed. Consider a class for dogs that stores the number of dogs
in this "meta" way, which the programmer uses to calculate how much dog
food the kennel has to buy. Then a need arises to instantiate objects for
dogs for whose feeding the kennel is not responsible, and suddenly your
model is broken and you have to go and unpick all that stuff. Better not
to put it in in the first place.

<snip>

 

[Chris Torek]

(e-mail address removed)...

... consider:
struct s {static int member;};
struct s ar[10];
what is "sizeof ar"?

consider:
struct s { char buf[0]; };

This is not legal in C (either C89 or C99) -- array sizes must be
positive, not merely nonnegative -- so this:

struct s ar[10];
what is ``sizeof ar'' ?

does not arise. In C99, you can attempt:

struct s { char buf[]; };

which would make s have a single flexible array member, but a
flexible array member, if one is present, must be last member in
a structure, *and* (this is the key item) must come after some
other member(s), so that sizeof(struct s) is nonzero. Furthermore,
arrays may not have as their element-type a structure type that
contains a flexible array member, so once again the question "what
is sizeof ar" does not arise.

The same as

struct s {};

This, too, is not legal in C.

(C++ has a funny little special case rule for otherwise-empty
struct types. C simply forbids them entirely.)