<mseitz@meridian-data.com> wrote:
>In article <33F4DB7A.5CE9@alum.mit.edu>, gerardw@alum.mit.edu wrote:
>>Bill Aitken wrote:
>>Sounds like you want to re-invent namespaces to me.

Not quite.  There is a difference in purpose and functionality
between namespaces and static classes.

>In fact, Bjarne Stroustrup in THE DESIGN AND EVOLUTION OF C++ (section
>17.2.1) mentions static class members as one of the early workarounds to avoid
>using global names.  He also mentions some disadvantages to this approach.  He
>goes on to say that namespaces were designed as a better solution to this
>problem.

Right, namespaces are a better solution to the problem of name clashes
with global names.  But that's not the problem we're trying to solve
with static classes.

Namespaces don't quite solve the problems that would be solved by
static classes, because they don't have "private".

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <33F4DB7A.5CE9@alum.mit.edu>, gerardw@alum.mit.edu wrote:
>Bill Aitken wrote:
>Sounds like you want to re-invent namespaces to me.
>
>Bill.

In fact, Bjarne Stroustrup in THE DESIGN AND EVOLUTION OF C++ (section
17.2.1) mentions static class members as one of the early workarounds to avoid
using global names.  He also mentions some disadvantages to this approach.  He
goes on to say that namespaces were designed as a better solution to this
problem.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

If you do not have static data, then:

How do you specify a property of the class rather than a property of the
object?

mseitz@meridian-data.com wrote in article <5tcog2$raf@kane.ico.net>...
> In article <33F4DB7A.5CE9@alum.mit.edu>, gerardw@alum.mit.edu wrote:
> >Bill Aitken wrote:
> >Sounds like you want to re-invent namespaces to me.
> >
> >Bill.
>
> In fact, Bjarne Stroustrup in THE DESIGN AND EVOLUTION OF C++ (section
> 17.2.1) mentions static class members as one of the early workarounds to
avoid
> using global names.  He also mentions some disadvantages to this
approach.  He
> goes on to say that namespaces were designed as a better solution to this

> problem.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <5tg8tp$dcq@bgtnsc02.worldnet.att.net>, "Cristian Georgescu" <Cristian.Georgescu@worldnet.att.net> wrote:
>If you do not have static data, then:
>
>How do you specify a property of the class rather than a property of the
>object?

Sorry I didn't make myself clear.  You can and should still use static members
if you need to add a property of the class to a class definition.  However, if
you are not using a class to define an object type, but are instead using it
just to restrict the scope of a name, then a namespace may be a better
solution.

As a rule of thumb, if a class has ordinary members, then adding static
members is fine.  However, if a class contains only static members, and the
only reason the static members are in a class is to prevent them from
conflicting with global names, a namespace is likely to be a better solution.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <01bca362$e5ad65c0$98012dc3@default>,
Daniele Ziglioli <zigolo@iol.it> wrote:

>It's common in embedded system to have a main loop that
>run various function that manage the system.
>I'd like to to have a class,  one for each system management.
>This class usually don't need to be istanced more then once.
>So I work the encapsulation properties of the classes and my code
>will be more clean.
>But I work in an embedded enviroment so the performance must
>to be high and for this reason I define all the member to be static,
>the code of a method defined static is a lot more efficient because
>the "this" pointer is non used.
>
>If Yes, why don't exist the possibility to define a class static ?

Sounds like you want to re-invent namespaces to me.


Bill.
--
William E. Aitken        | Formal verification is the
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 8500 148th Ave NE #H1026 Redmond WA  | Always has been, always will be.
===============================================================================
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage <stephen.clamage@eng.sun.com> scritto nell'articolo
<33EB527B.5934@Eng.Sun.COM>...
> Daniele Ziglioli wrote:
> >
> > So, why not a class defined as :
> >
>
> Putting the keyword "static" in front of a class definition already
> has a meaning if you also define a variable. That is,
>  static class C { ... } c;
> delcares "c" to be a static variable. It does not affect any of the
> members of C. Changing that would break existing programs.
>
> We could invent a new syntax that would mean "all the members of C are
> static", but I don't think the benefit would be very great, There
> is already a solution without changing the language: put "static"
> on each member declaration.

I think the benefits to declare class member to static are mainly
concerning the efficiency of the resulting code due to no "this" pointer
using.
And, yes a new sintax I think  is mainly a "comfort" issue during the code
writing.
Because not only we must define all the member static but also
rewrite all the attribute,  in almost the same way, to istance them.
I think is a really "overload". If later  you decide  that need
more than an istance you must correct lot of code, and than you never
rewrite
a class with all member static without lot of anxiety, a ensure you this.

Of course, better is something like

////////////////////////////////////////////////////
class Myclass {
 ....
};

singleton Myclass uniqueObject;
//    ^   new keyword

/////////////////////////////////////////////////////

where singleton (not the pattern) tell to the compiler that there is
an unique istance of that class and so this pointer is unnecesary.

This let me define a class normaly and use it in the  standard way
or like a class with all member defined static.



Regards, Daniele Ziglioli
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Daniele Ziglioli wrote:
>
> I think the benefits to declare class member to static are mainly
> concerning the efficiency of the resulting code due to no "this" pointer
> using.

That isn't the purpose of static class members.

Some properties of a class belong to an instance, and some to
the class itself. Ordinary members apply to a specific instance,
and static members apply to the class.

The "this" pointer does not affect efficiency. If a function needs
to refer to a specific object, you must somehow tell it which
object. Either you use an explicit parameter, or the implicit
"this" parameter. The generated object code should be identical
in either case.

If a function does not need to refer to a specific object, then
it should probably not be an ordinary member function. It should
probably be either a static member function, or an ordinary
non-member function. It is a question of class design, and has
nothing to do with efficiency.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Daniele Ziglioli <zigolo@iol.it> wrote:
>> So, why not a class defined as:
>>   static class MyClass { // meaning all the members are static
>>     int attrib1=0;
>>   public:
>>     void run(void);
>>   };
>>
>> instead of :
>>   class MyClass {
>>     static int attrib1;
>>   public:
>>     static void run(void);
>>   };

Steve Clamage <stephen.clamage@eng.sun.com> responded:
> Putting the keyword "static" in front of a class definition already
> has a meaning if you also define a variable. That is,
>         static class C { ... } c;
> declares "c" to be a static variable. It does not affect any of the
> members of C. Changing that would break existing programs.
>
> We could invent a new syntax that would mean "all the members of C are
> static", but I don't think the benefit would be very great, There
> is already a solution without changing the language: put "static"
> on each member declaration.

This illustrates one of the problems with such an overloaded keyword like
'static'.  On the one hand, it means 'not extern', as in:
    static int x;       // Visible only in file scope

On the other hand, it means 'statically allocated', as in:
    int foo()
    {
        static int y;   // Statically allocated, not auto/dynamic
    }

On the third hand, it means 'shared by all class funcs', as in:
    class Foo
    {
        static int z;   // Shared by all Foo member funcs
    };

Using 'static' can be problematic, since it has so many meanings.  For
example, if I define Foo::z, I can't code the following definition, even
though it looks a lot like what I coded above, because 'static' has a
different meaning outside the braces of the class declaration:
    static int Foo::z = 1;  // Illegal

A different keyword would be clearer, such as:
    class Foo
    {
        shared int z;       // 'shared' = shared by all class funcs
    };

    shared int Foo::z = 1;  // Orthogonal, definition matches declaration

The same goes for 'virtual' - I should be able to both declare and define
a func as 'virtual', but I can't (even though 'virtual' has only one meaning).
So what I get are declarations and definitions that look different but really
have the same meaning; C++ syntax is not orthogonal in this area.

Applying the hypothetical 'shared' keyword to Daniele's suggestion gives:
    shared class MyClass { ... };

But I'm not sure what this would achieve.  I prefer 'shared' ('static') to
be explicit in class member declarations.  (I would also prefer explicit
'public', 'protected', and 'private', ala Java, but C++ syntax makes these
too ugly.)

--------------------.      BEA Systems, Inc. ,-.  +1-972-738-6125 Office
David R. Tribble     \   ,------------------'   \ +1-972-738-6111 Fax
http://www.beasys.com `-'  Dallas, TX 75248      `-----------------------
david.tribble@noSPAM.beasys.com            http://www.flash.net/~dtribble
-------------------------------------------------------------------------
Send junk to: postmaster@agis.net mrchig@easynet.co.uk emailer@qlink2info.com
 simrem@answerme.com office@canma.dyn.ml.org markdan3@earthlink.net
 markdan@wans.net markdan@gte.net r_denterprise@hotmail.com
teamwork@1stfamily.com
 lvck1@hotmail.com peterson@dragonindustries.com bubbac@webconnect.com
 clover@earthfriends.com abuse@cyberpromo.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David R Tribble <david.tribble@central.beasys.com> writes:

> This illustrates one of the problems with such an overloaded keyword like
> 'static'.

Actually, it's not as overloaded as all that.  It has one meaning
inherited from C, and another meaning when applied to a class member
in C++.


>  On the one hand, it means 'not extern', as in:
>     static int x;       // Visible only in file scope
>
> On the other hand, it means 'statically allocated', as in:
>     int foo()
>     {
>         static int y;   // Statically allocated, not auto/dynamic
>     }

These are not actually different.  In C, static means globally
allocated, but without external linkage, i.e. limited to file scope.
In the second case, the scope is limited by the braces which surround
the function, but the meaning of "static" has not changed:  scope can
always be freely reduced (e.g. by braces).

Admittedly, this is my own interpretation -- I haven't asked K or R
about this.  But ask yourself, how likely is it that they deliberately
added a second meaning to this keyword and *only* this keyword?  How
likely is it when another reasonable interpretation exists?

I think that the existence of the (useless) keyword "auto" tends to
support my theory as well.  My guess is that "auto" was originally
*not* implicit, and that local variables were global by default, but
after noticing that a global variable in a local scope might as well
be declared static, K&R decided to make non-static locals be auto by
default.  (I'm less sure of this latter theory, though.)

Note that functions are always globally allocated, which is why
"static" can be applied to functions as well as to data items.  Again,
in C at least, the meaning of "static" seems to be consistent for all
its uses.

> On the third hand, it means 'shared by all class funcs', as in:
>     class Foo
>     {
>         static int z;   // Shared by all Foo member funcs
>     };

Here we have a second language designer coming along, and (I presume)
not being very clear about the (certainly rather obscure) meaning of
"static".  At least it *appears* that he (Stroustrup) was confused
about the meaning of "static" in C.  It's possible that he simply
decided to add this (rather confusing IMO) overloading to avoid adding
a new keyword.  But I suspect he was confused -- in D&E he freely
admits that he didn't actually know C very well when he decided to use
it as the basis for C-with-classes.

Note that the scope is *widened* over what the C rules would allow.
That's why this *is* a different meaning, where the second example
above was not.

> A different keyword would be clearer, such as:
>     class Foo
>     {
>         shared int z;       // 'shared' = shared by all class funcs
>     };
>
>     shared int Foo::z = 1;  // Orthogonal, definition matches declaration

Yes.  It might also have helped if K and/or R had come up with a
better name for "static" in the first place.  Not that I can think of
one. . . .

Anyway, with namespaces, name-mangling, bigger drives and faster
computers, the need to actually *suppress* the external declaration of
something in the object files has all-but-disappeared.  So, in C++ at
least, there's very little reason to use "static" in the older, C,
sense.  Within a few years, I suspect that only a few programmers will
know or care that "static" means *anything* except property-of-the-
class-not-the-instance.  I believe that the draft standard already
deprecates other uses.
--
Chris Waters             |
cwaters@systems.DHL.COM  |   pneumonoultra-      -osis is too long
xtifr@dsp.net (personal) | microscopicsilico-   to fit into a single
www.dsp.net/xtifr/ (web) |    volcaniconi-        standalone haiku.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Chris Waters wrote:
>
> David R Tribble <david.tribble@central.beasys.com> writes:
>
> > This illustrates one of the problems with such an overloaded keyword like
> > 'static'.
>
> Actually, it's not as overloaded as all that.  It has one meaning
> inherited from C, and another meaning when applied to a class member
> in C++.
>
> >  On the one hand, it means 'not extern', as in:
> >     static int x;       // Visible only in file scope
> >
> > On the other hand, it means 'statically allocated', as in:
> >     int foo()
> >     {
> >         static int y;   // Statically allocated, not auto/dynamic
> >     }
>
> These are not actually different.  In C, static means globally
> allocated, but without external linkage, i.e. limited to file scope.

The term "globally allocated" is not defined or used in C or C++,
and I don't know what you might mean by it. Let's stick with the
terminology of C and C++ which is defined in the languages.

Here are the two different meanings of "static":
1. The storage duration of the object is the same as the
duration of the program.
2. The linkage of the identifier is internal. That is, the same
name declared in a different translation unit does not refer to
the same entity.

Variable x has static storage duration with or without the "static"
keyword, and "static" here means "internal linkage".

Variable y has no linkage (the same name declared in another scope
does not refer to the same entity) with or without the "static"
keyword, and "static" here means "static storage duration".

It is indeed unfortunate that the same word is used to refer
to unrelated concepts, and that the same keyword is used to
specify unrelated properties of a program element.

> > On the third hand, it means 'shared by all class funcs', as in:
> >     class Foo
> >     {
> >         static int z;   // Shared by all Foo member funcs
> >     };
>
> Here we have a second language designer coming along, and (I presume)
> not being very clear about the (certainly rather obscure) meaning of
> "static".  At least it *appears* that he (Stroustrup) was confused
> about the meaning of "static" in C.  It's possible that he simply
> decided to add this (rather confusing IMO) overloading to avoid adding
> a new keyword.  But I suspect he was confused -- in D&E he freely
> admits that he didn't actually know C very well when he decided to use
> it as the basis for C-with-classes.

Stroustrup himself has answered this canard in another thread. He
understood C very well, particularly the issues of linkage and
storage duration.  But when your office is down the hall from
Dennis Ritchie and Brian Kernighan, you tend to be a bit
diffident about claiming expertise in C.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Chris Waters wrote:
> Actually, it's not as overloaded as all that.  It has one meaning
> inherited from C, and another meaning when applied to a class member
> in C++.

 No, in C it has two different meanings. Consider:
 int x;
 static int X;

 void func( )
 {
  int y;
  static int Y;

In the first case, x already had global lifetime, the static keyword
changes its visibility.

In the second case, y already had visibility restricted to the function,
the static keyword changes its lifetime.


> Anyway, with namespaces, name-mangling, bigger drives and faster
> computers, the need to actually *suppress* the external declaration of
> something in the object files has all-but-disappeared.  So, in C++ at
> least, there's very little reason to use "static" in the older, C,
> sense.  Within a few years, I suspect that only a few programmers will
> know or care that "static" means *anything* except property-of-the-
> class-not-the-instance.  I believe that the draft standard already
> deprecates other uses.

There's still a use to change the lifetime of a file variable. Consider
the Scott Meyers Singleton implementation:

 struct Printer {
  static Printer & thePrinter( );
 };

 Printer &Printer::thePrinter( )
 {
  static thePrinter;
  return the Printer
 }
The two statics still do different things, and I don't know of any
alternate syntax for either of them.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Bill Aitken wrote:
Sounds like you want to re-invent namespaces to me.

Bill.
--

I agree. Let me embelish the answer.
One could declare in header file:

namespace MySubsystem {
 void run( );
 ... //and remaining "public" functions
}

and then define in a source file:

namespace { //unnamed namespace replaces the deprecated file static
 int attrib1;
 ... //and remaining "private" data and functions
}

namespace MySubsystem {

 void run( )
 {
  ++attrib1; //has visibility to file scope variables
  ...
 }
}

I think has much of the effect of a "static class" while using different
mechanisms. (i.e. we restrict visibility of "private" class members
instead of using access control).  It does require all pseudo-class
functions to be implemented in a single source file ("translation
unit").  Other files could add additional functons to the MySubsystem
namespace, but they wouldn't have access to the data, so it seems
pointless.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Daniele Ziglioli wrote:
>
> So, why not a class defined as :
>
> static class MyClass { // meaning all the members are static
>   int attrib1=0;
> public:
>   void run(void);
> };
>
> instead of :
>
> class MyClass {
>   static int attrib1;
> public:
>   static void run(void);
> }

Putting the keyword "static" in front of a class definition already
has a meaning if you also define a variable. That is,
 static class C { ... } c;
delcares "c" to be a static variable. It does not affect any of the
members of C. Changing that would break existing programs.

We could invent a new syntax that would mean "all the members of C are
static", but I don't think the benefit would be very great, There
is already a solution without changing the language: put "static"
on each member declaration.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]