AT>    And here we have at least two keywords that have different usage
AT> restrictions in different contexts. I haven't seen any C++ compilers
AT> accept 'static' to limit method visibility in the same way C uses it
AT> functions and variables. Maybe there is one, i gave up searching. So
I can't believe this. C++ compilers have  to  behave  exactly  like  C
compilers in this case.
AT> access to the non-static data, or whatever', but when you define som
AT> (that is just an ordinary function with hidden this pointer paramete
AT> restrictions on who can use it) then you can't use 'static' just bec
AT> would require too much changes to the compiler code? Don't think so,
As  I  said before, I don't understand you. For ordinary functions and
variables, 'static' has to have the same effect in C++ as in C.
AT> same class share the same pointer value. But for some reason there i
AT> like 'virtual member', that would be static member of the class that
AT> accessed using pointer that is too stored in the VMT. How many times
Stroustrup discussed this in "The Design and  Evolution  of  C++"  (p.
266/7).  As  a rule of thumb, he has always been very reluctant adding
new features to C++  if  their  effect  could  be  reached  using  the
existing features (a virtual accessor method in this case).
AT> declare something like 'virtual int class::typeid(void) { return
AT> some_constant_value; }' for that purpose? And why is there an artifi
AT> limitation so you can't do things the way they could be done in the
AT> way? Maybe RTTI can provide some of this functionality, never tried
AT> ugly)...
Yes,  RTTI  provides  this  functionality.  Using  RTTI  can  be  very
convenient sometimes, but it's good to always think twice before using
it because it tempts you to design badly.
Thomas
PS:  I  agree  with  the  general message of your message: overloading
keywords (static, virtual) doesn't seem to be very fortunate.
---
 þ MM 1.0 #0113 þ Colleges don't make fools; they only develop them
---------------