Any comments? thanks.

Jim

arkmancn@gmail.com wrote:
> Any comments? thanks.
> 
Please put your question in the body of your post and don't SHOUT.

C isn't C++.

-- 
Ian Collins.

On Mon, 22 Oct 2007 18:14:08 -0700, arkmancn@gmail.com wrote in
comp.lang.c:

> Any comments? thanks.

Because there is no such thing as STRUCT or UNION in C.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

In article <1193102048.578463.112550@k35g2000prh.googlegroups.com>,
 <arkmancn@gmail.com> wrote:
>Any comments? thanks.

What would you expect it to mean? That, in the case of a struct,
that the rest of the struct would lose its values when the struct
went out of scope, but the static member would not? That, in
the case of a union, that... that what? That if you had last written
to it via the static member that the value would be remembered
but that it wouldn't be remembered if you had written to the
union via one of the non-static members ???
-- 
   "History is a pile of debris"                     -- Laurie Anderson

 arkmancn@gmail.com wrote:

> Any comments? thanks.
> 
> Jim

In Standard C,  it can't. 
because C doesn't support it. C isn't a language that supports
OO programming favor.

You can use C++, and post in comp.lang.c++ .


> 
-Road.
-- 
C FAQ: http://c-faq.com/

 arkmancn@gmail.com wrote:

> Any comments? thanks.

Note that C is case sensitive. STRUCT and UNION are not defined by the C
Standard, you probably meant struct and union.

As for your question, a struct or union is an aggregate type. That means
all it's member objects have the same scope. Though the static
qualifier can apply to the whole structure, it's application to one of
it's members makes very little sense; and I see little point in it too.

arkmancn@gmail.com wrote:
> Any comments? thanks.

The keyword 'static' has many meanings in C, none of which make sense 
inside a struct. C++ gave that keyword an additional meaning, which 
applies only in that context, but this newsgroup is for discussing C, 
not C++.

"James Kuyper Jr." <jameskuyper@verizon.net> writes:

> arkmancn@gmail.com wrote:
>> Any comments? thanks.
>
> The keyword 'static' has many meanings in C, none of which make sense
> inside a struct. C++ gave that keyword an additional meaning, which
> applies only in that context, but this newsgroup is for discussing C,
> not C++.

It would make perfect sense to see static in a struct as far as I can
see. What is so nonsensical about it? Or is your point not that it
wouldn't make sense, but that it's simply not available?

Richard wrote:
> "James Kuyper Jr." <jameskuyper@verizon.net> writes:
> 
>> arkmancn@gmail.com wrote:
>>> Any comments? thanks.
>> The keyword 'static' has many meanings in C, none of which make sense
>> inside a struct. C++ gave that keyword an additional meaning, which
>> applies only in that context, but this newsgroup is for discussing C,
>> not C++.
> 
> It would make perfect sense to see static in a struct as far as I can
> see. What is so nonsensical about it? Or is your point not that it
> wouldn't make sense, but that it's simply not available?

The standard defines (at least) three different meanings for the keyword 
static, depending upon whether it's at file scope,  block scope, or 
function prototype scope. A single struct type, once defined, could be 
used to declare an object in any of those scopes, so the possible 
meaning of the 'static' keyword when applied to a member would have to 
change with the scope.

File scope: what would it mean for a structure object to have external 
linkage, but a member of that object to have internal linkage (or vice 
versa)?

Block scope: What would it mean for a structure object to be 
automatically or dynamically allocated, and to have a member that was 
statically allocated (or vice versa)?

Function prototype scope: the only meaning currently provided for static 
in this scope is that it requires that the leading dimension of an array 
passed as a specific argument to the function to be at least as long as 
the length specified for the corresponding parameter. I don't see how 
that could be applied to struct members.

I'm not saying that answers couldn't be invented for these questions; 
I'm merely saying that any answer would be a new invention, not a simple 
extension to the currently defined meanings of 'static'.

"James Kuyper Jr." <jameskuyper@verizon.net> writes:

> Richard wrote:
>> "James Kuyper Jr." <jameskuyper@verizon.net> writes:
>>
>>> arkmancn@gmail.com wrote:
>>>> Any comments? thanks.
>>> The keyword 'static' has many meanings in C, none of which make sense
>>> inside a struct. C++ gave that keyword an additional meaning, which
>>> applies only in that context, but this newsgroup is for discussing C,
>>> not C++.
>>
>> It would make perfect sense to see static in a struct as far as I can
>> see. What is so nonsensical about it? Or is your point not that it
>> wouldn't make sense, but that it's simply not available?
>
> The standard defines (at least) three different meanings for the
> keyword static, depending upon whether it's at file scope,  block
> scope, or function prototype scope. A single struct type, once
> defined, could be used to declare an object in any of those scopes, so
> the possible meaning of the 'static' keyword when applied to a member
> would have to change with the scope.
>
> File scope: what would it mean for a structure object to have external
> linkage, but a member of that object to have internal linkage (or vice
> versa)?

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.

>
> Block scope: What would it mean for a structure object to be
> automatically or dynamically allocated, and to have a member that was
> statically allocated (or vice versa)?

static is static. The structure references the static value.

>
> Function prototype scope: the only meaning currently provided for
> static in this scope is that it requires that the leading dimension of
> an array passed as a specific argument to the function to be at least
> as long as the length specified for the corresponding parameter. I
> don't see how that could be applied to struct members.

I'm not sure I know what you are talking about here. I fail to see how
this has anything to do with a static structure field.

>
> I'm not saying that answers couldn't be invented for these questions;
> I'm merely saying that any answer would be a new invention, not a
> simple extension to the currently defined meanings of 'static'.

I'm not sure anything you have said means that it doesn't "make sense"
for "static" to mean something reasonable inside a structure. The fact
that it isn't part of C is neither here nor there to the conversation
about a hypothetical thing anyway.

James Kuyper Jr. wrote:

> Richard wrote:

>> It would make perfect sense to see static in a struct as far as I can
>> see. What is so nonsensical about it? Or is your point not that it
>> wouldn't make sense, but that it's simply not available?
> 
> The standard defines (at least) three different meanings for the
> keyword static, depending upon whether it's at file scope,  block
> scope, or function prototype scope. A single struct type, once
> defined, could be used to declare an object in any of those scopes, so
> the possible meaning of the 'static' keyword when applied to a member
> would have to change with the scope.
> 
> File scope: what would it mean for a structure object to have external
> linkage, but a member of that object to have internal linkage (or vice
> versa)?

Presumably that the static member is invisible to other modules?

> Block scope: What would it mean for a structure object to be
> automatically or dynamically allocated, and to have a member that was
> statically allocated (or vice versa)?

Presumably that the static member retains it's previous value?

<snip>

santosh wrote:
> James Kuyper Jr. wrote:
....
> > The standard defines (at least) three different meanings for the
> > keyword static, depending upon whether it's at file scope,  block
> > scope, or function prototype scope. A single struct type, once
> > defined, could be used to declare an object in any of those scopes, so
> > the possible meaning of the 'static' keyword when applied to a member
> > would have to change with the scope.
> >
> > File scope: what would it mean for a structure object to have external
> > linkage, but a member of that object to have internal linkage (or vice
> > versa)?
>
> Presumably that the static member is invisible to other modules?

Reasonable, but how would you declare it in the other modules?
Certainly something like this could be defined, but it's not a simple
extension of the existing C language.

> > Block scope: What would it mean for a structure object to be
> > automatically or dynamically allocated, and to have a member that was
> > statically allocated (or vice versa)?
>
> Presumably that the static member retains it's previous value?

That's a concept that could certainly be developed, but unless the
structure itself is also declared static, on most implementations I'm
familiar with, that would require that the static member be stored
somewhere other than the other members of the struct, which is
inconsistent with C's object model. C++ has an object model that has
been modified to accomodate this idea. Large portions of the C
standard would need to be reviewed to make sure they still make sense
with the revised object model.

I hope you're not suggesting that both of these answers be used? I
think that would cause a lot of headaches. I was expecting an answer
that would choose one or the other meaning, and impose the same
meaning, regardless of what scope the object was defined in.

On Tue, 23 Oct 2007 22:31:45 +0530, santosh <santosh.k83@gmail.com>
wrote in comp.lang.c:

> James Kuyper Jr. wrote:
> 
> > Richard wrote:
> 
> >> It would make perfect sense to see static in a struct as far as I can
> >> see. What is so nonsensical about it? Or is your point not that it
> >> wouldn't make sense, but that it's simply not available?
> > 
> > The standard defines (at least) three different meanings for the
> > keyword static, depending upon whether it's at file scope,  block
> > scope, or function prototype scope. A single struct type, once
> > defined, could be used to declare an object in any of those scopes, so
> > the possible meaning of the 'static' keyword when applied to a member
> > would have to change with the scope.
> > 
> > File scope: what would it mean for a structure object to have external
> > linkage, but a member of that object to have internal linkage (or vice
> > versa)?
> 
> Presumably that the static member is invisible to other modules?

Horse apples.  Nothing in a structure is accessible from other
translation units (other than as an array of unsigned chars) unless
the struct definition is visible.  The identical struct definition,
with the same types in the same order having the same names.

> > Block scope: What would it mean for a structure object to be
> > automatically or dynamically allocated, and to have a member that was
> > statically allocated (or vice versa)?
> 
> Presumably that the static member retains it's previous value?

All members in a struct object are "static" throughout its lifetime.
As long as the object exists, each member retains its last stored
value until such time as it is assigned another value.

But once an automatic instance of the struct goes out of scope, or a
dynamically allocated instance is free()'d, the object ceases to exist
and there is no way it can retain a previous value.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Richard wrote:
> "James Kuyper Jr." <jameskuyper@verizon.net> writes:
....
>> The standard defines (at least) three different meanings for the
>> keyword static, depending upon whether it's at file scope,  block
>> scope, or function prototype scope. A single struct type, once
>> defined, could be used to declare an object in any of those scopes, so
>> the possible meaning of the 'static' keyword when applied to a member
>> would have to change with the scope.
....
> 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.

That's obvious only by reference to C++; it's not in any sense a 
uniquely obvious extension of any of the current meanings of 'static' in C.

....
> I'm not sure anything you have said means that it doesn't "make sense"
> for "static" to mean something reasonable inside a structure. The fact
> that it isn't part of C is neither here nor there to the conversation
> about a hypothetical thing anyway.

My point, which I should have stated more plainly, is that the OP should 
not have simply asked why the static keyword couldn't be used; if he 
wanted to be able to use it, he should have specified what meaning he 
wanted it to have. Simply saying "the same as in C++" would have been 
inadequate, but it would be much better than providing no hint as to the 
desired meaning.


Had he put the request in those terms, I would have pointed out that in 
C++, static members are accessible from outside a class only by use of 
the scope resolution operator '::', and are accessible without the scope 
resolution operator only within member functions of the class or its 
sub-classes. Since C has neither the scope resolution operator, nor 
member functions, in order for static members to be useful they could 
work "the same as in C++" only if one or both of those things is also 
added to C.

You could make static members accessible through the member access 
operator '.', but that would create a gratuitous incompatibility between 
C and C++, something that both the C and the C++ have policies against.

James Kuyper <jameskuyper@verizon.net> writes:

> Richard wrote:
>> "James Kuyper Jr." <jameskuyper@verizon.net> writes:
> ...
>>> The standard defines (at least) three different meanings for the
>>> keyword static, depending upon whether it's at file scope,  block
>>> scope, or function prototype scope. A single struct type, once
>>> defined, could be used to declare an object in any of those scopes, so
>>> the possible meaning of the 'static' keyword when applied to a member
>>> would have to change with the scope.
> ...
>> 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.
>
> That's obvious only by reference to C++; it's not in any sense a
> uniquely obvious extension of any of the current meanings of 'static'
> in C.

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.

Richard wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> Richard wrote:
>>> "James Kuyper Jr." <jameskuyper@verizon.net> writes:
>> ...
>>>> The standard defines (at least) three different meanings for the
>>>> keyword static, depending upon whether it's at file scope,  block
>>>> scope, or function prototype scope. A single struct type, once
>>>> defined, could be used to declare an object in any of those scopes, so
>>>> the possible meaning of the 'static' keyword when applied to a member
>>>> would have to change with the scope.
>> ...
>>> 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.
>> That's obvious only by reference to C++; it's not in any sense a
>> uniquely obvious extension of any of the current meanings of 'static'
>> in C.
> 
> 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.

Can you point to one of the existing meanings for 'static' in C, and 
explain how this is a unique natural extension of that meaning? It seems 
quite different from any of the three that I listed.

James Kuyper <jameskuyper@verizon.net> writes:

> Richard wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>
>>> Richard wrote:
>>>> "James Kuyper Jr." <jameskuyper@verizon.net> writes:
>>> ...
>>>>> The standard defines (at least) three different meanings for the
>>>>> keyword static, depending upon whether it's at file scope,  block
>>>>> scope, or function prototype scope. A single struct type, once
>>>>> defined, could be used to declare an object in any of those scopes, so
>>>>> the possible meaning of the 'static' keyword when applied to a member
>>>>> would have to change with the scope.
>>> ...
>>>> 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.
>>> That's obvious only by reference to C++; it's not in any sense a
>>> uniquely obvious extension of any of the current meanings of 'static'
>>> in C.
>>
>> 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.
>
> Can you point to one of the existing meanings for 'static' in C, and
> explain how this is a unique natural extension of that meaning? It
> seems quite different from any of the three that I listed.

I already did. It's above.

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.

Possibly you have a much more detailed view of what static might mean -
but in my mind its fairly straightforward and clear in the, possibly,
simplistic ways in which I have used it and/or understood it.

Richard wrote:

> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> Richard wrote:
>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>
>>>> Richard wrote:
>>>>> "James Kuyper Jr." <jameskuyper@verizon.net> writes:
>>>> ...
>>>>>> The standard defines (at least) three different meanings for the
>>>>>> keyword static, depending upon whether it's at file scope,  block
>>>>>> scope, or function prototype scope. A single struct type, once
>>>>>> defined, could be used to declare an object in any of those
>>>>>> scopes, so the possible meaning of the 'static' keyword when
>>>>>> applied to a member would have to change with the scope.
>>>> ...
>>>>> 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.
>>>> That's obvious only by reference to C++; it's not in any sense a
>>>> uniquely obvious extension of any of the current meanings of
>>>> 'static' in C.
>>>
>>> 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.
>>
>> Can you point to one of the existing meanings for 'static' in C, and
>> explain how this is a unique natural extension of that meaning? It
>> seems quite different from any of the three that I listed.
> 
> I already did. It's above.
> 
> 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.
> 
> Possibly you have a much more detailed view of what static might mean
> - but in my mind its fairly straightforward and clear in the,
> possibly, simplistic ways in which I have used it and/or understood
> it.

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.

I'm sure the experts can point to numerous loopholes and untenable
assumptions. :)

In article <5if1v4-rf6.ln1@news.individual.net>,
Richard  <rgrdev@gmail.com> wrote:

>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.

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
-- 
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Richard wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
....
> > Can you point to one of the existing meanings for 'static' in C, and
> > explain how this is a unique natural extension of that meaning? It
> > seems quite different from any of the three that I listed.
>
> 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.

jameskuyper@verizon.net writes:

> Richard wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
> ...
>> > Can you point to one of the existing meanings for 'static' in C, and
>> > explain how this is a unique natural extension of that meaning? It
>> > seems quite different from any of the three that I listed.
>>
>> 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.

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@cogsci.ed.ac.uk (Richard Tobin) writes:

> In article <5if1v4-rf6.ln1@news.individual.net>,
> Richard  <rgrdev@gmail.com> wrote:
>
>>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.
>
> 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 :-;

santosh <santosh.k83@gmail.com> writes:

> Richard wrote:
>
>> James Kuyper <jameskuyper@verizon.net> writes:
>> 
>>> Richard wrote:
>>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>>
>>>>> Richard wrote:
>>>>>> "James Kuyper Jr." <jameskuyper@verizon.net> writes:
>>>>> ...
>>>>>>> The standard defines (at least) three different meanings for the
>>>>>>> keyword static, depending upon whether it's at file scope,  block
>>>>>>> scope, or function prototype scope. A single struct type, once
>>>>>>> defined, could be used to declare an object in any of those
>>>>>>> scopes, so the possible meaning of the 'static' keyword when
>>>>>>> applied to a member would have to change with the scope.
>>>>> ...
>>>>>> 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.
>>>>> That's obvious only by reference to C++; it's not in any sense a
>>>>> uniquely obvious extension of any of the current meanings of
>>>>> 'static' in C.
>>>>
>>>> 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.
>>>
>>> Can you point to one of the existing meanings for 'static' in C, and
>>> explain how this is a unique natural extension of that meaning? It
>>> seems quite different from any of the three that I listed.
>> 
>> I already did. It's above.
>> 
>> 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.
>> 
>> Possibly you have a much more detailed view of what static might mean
>> - but in my mind its fairly straightforward and clear in the,
>> possibly, simplistic ways in which I have used it and/or understood
>> it.
>
> 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).

-- 
Ben.

In article <lrh6v4-v9i.ln1@news.individual.net>,
Richard  <rgrdev@gmail.com> wrote:
....
(someone else)
>> That's obvious only by reference to C++; it's not in any sense a
>> uniquely obvious extension of any of the current meanings of 'static'
>> in C.
>
>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.

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>

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.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:

> 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.

In article <gP2dneudSOX8v7zanZ2dnUVZ8tSdnZ2d@bt.com>,
Richard Heathfield  <rjh@see.sig.invalid> wrote:

>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

-- 
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Richard Tobin said:

> In article <gP2dneudSOX8v7zanZ2dnUVZ8tSdnZ2d@bt.com>,
> Richard Heathfield  <rjh@see.sig.invalid> wrote:
> 
>>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.

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 Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

In article <5sKdnR7io6vdX7zanZ2dneKdnZydnZ2d@bt.com>,
Richard Heathfield  <rjh@see.sig.invalid> wrote:

>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
-- 
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Richard Heathfield wrote:

> Richard Tobin said:
> 
>> In article <gP2dneudSOX8v7zanZ2dnUVZ8tSdnZ2d@bt.com>,
>> Richard Heathfield  <rjh@see.sig.invalid> wrote:
>> 
>>>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.
> 
> 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.

>> 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.

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[s] better results [4]; I'm just picking at the terminology. 

[4] Anyone who cares can probably find out.

-- 
Chris "spice" Dollin

Hewlett-Packard Limited                                          registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN          690597 England

Richard wrote:
> jameskuyper@verizon.net writes:
> 
>> Richard wrote:
>>> James Kuyper <jameskuyper@verizon.net> writes:
>> ...
>>>> Can you point to one of the existing meanings for 'static' in C, and
>>>> explain how this is a unique natural extension of that meaning? It
>>>> seems quite different from any of the three that I listed.
>>> 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.
> 
> 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.

On Oct 25, 11:03 am, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
> In article <5if1v4-rf6....@news.individual.net>,
>
> Richard  <rgr...@gmail.com> wrote:
> >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.
>
> 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++."

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

Chris Dollin said:

> Richard Heathfield wrote:
> 
<snip>
 
>> Seriously, the acceptance of classes as entities that can possess
>> information leads to a paradigm clash, at least in my opinion.
> 
> 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.
 
>> 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.

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.

<snip>

>> 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/.

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>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999