In article <KANZE.93Jul28181700@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>
>As I pointed out in a posting in comp.lang.c++, static in a class
>definition has a completely different meaning than static outside of a
>class definition.  In particular, declaring a variable static at file
>scope means that it has internal linkage; there is thus no problem
>if it appears in many different translation units.  On the other hand,
>class members normally have external linkage, whether they are static
>or not.

Careful James.  I believe that the NAMES of non-static class data members,
as well as typedef members and enumerator members and enumeration type
members will eventually be defined to have NO LINKAGE.  (But that hasn't
been written done anywhere yet.)

P.S.  There was some discussion awhile back in comp.std.c about whether
"linkage" is a property associated with NAMES or with declared ENTITIES.
I don't think any satisfactory resolution of this question was ever found
in the ANSI/ISO C standard.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

I have two things I wonder why they are not allowed:

1. I'd like a definition like this

  class X {
    static const int a = 1;
  };

It seems to me that this is not different from

  const int b = 1;    // This can be in header (ARM 7.1.6)

except that it is

  const int X::a = 1;

ARM (section 9.4) says that "the problem is that class declarations
typically appear in header files, so a declaration like the one above
will be seen by a compiler many times while compiling a multifile
program."

Am I missing the difference here?


2. virtual static constants and virtual static functions.

A virtual static constant could be stored in virtual tables. This way
there would be no need for virtual accessor function and especially
wasting the time to call it. Great for class identifiers (well, the
method of identifying by vptr would be better) and I would have had
use for it before.

I understand that it has to be constant or the virtual tables could
not be stored in write protected memory.

A static member function is function that does get the this pointer.
I'd sometimes want to call them via a base class pointer too...

Is there some problems with these or haven't they just noticed that so
could be done?
--
---
Marko Kohtala - INTERNET: Marko.Kohtala@hut.fi, Marko.Kohtala@compart.fi
Student at (not representative of) the Helsinki University of Technology
(This is an information virus: if you know of it, you are infected.)

In <mkohtala.743438149@snakemail.hut.fi> mkohtala@lk-hp-19.hut.fi (Marko Kohtala) writes:

>A static member function is function that does get the this pointer.

Woops! Apparently I forgot to write the "not".

--
---
Marko Kohtala - INTERNET: Marko.Kohtala@hut.fi, Marko.Kohtala@compart.fi
Student at (not representative of) the Helsinki University of Technology
(This is an information virus: if you know of it, you are infected.)

In article <mkohtala.743438149@snakemail.hut.fi>
mkohtala@lk-hp-19.hut.fi (Marko Kohtala) writes:

|> I have two things I wonder why they are not allowed:

|> 1. I'd like a definition like this

|>   class X {
|>     static const int a = 1;
|>   };

|> It seems to me that this is not different from

|>   const int b = 1;    // This can be in header (ARM 7.1.6)

|> except that it is

|>   const int X::a = 1;

|> ARM (section 9.4) says that "the problem is that class declarations
|> typically appear in header files, so a declaration like the one above
|> will be seen by a compiler many times while compiling a multifile
|> program."

|> Am I missing the difference here?

As I pointed out in a posting in comp.lang.c++, static in a class
definition has a completely different meaning than static outside of a
class definition.  In particular, declaring a variable static at file
scope means that it has internal linkage; there is thus no problem
if it appears in many different translation units.  On the other hand,
class members normally have external linkage, whether they are static
or not.


|> 2. virtual static constants and virtual static functions.

|> A virtual static constant could be stored in virtual tables. This way
|> there would be no need for virtual accessor function and especially
|> wasting the time to call it. Great for class identifiers (well, the
|> method of identifying by vptr would be better) and I would have had
|> use for it before.

|> I understand that it has to be constant or the virtual tables could
|> not be stored in write protected memory.

|> A static member function is function that does get the this pointer.
|> I'd sometimes want to call them via a base class pointer too...

|> Is there some problems with these or haven't they just noticed that so
|> could be done?

I don't think it was felt that there was a need.  If all you want to
do is run time type identification, there is a language extension
which was adapted in Portland which takes care of this.

On the other hand, I've often wanted virtual static functions in
container classes.  My container classes always derive from a base
class which does not know the type of the contained object, but
factors out the common behavior.  For the specific cases where it is
necessary to know the type (say to delete an element that has been
removed from the container), I use a pure virtual function, which the
type specific derived class overrides.  Typically, these functions
never touch the container itself, only the object passed as parameter,
so they really should be static as well.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung