Calling static member function through object instance

[Bjarne Stroustrup]

Thanks for the answer!

The C# design team thinks the user cares because it makes their code more
readable. I'm not partial to either view, I was merely curious.

Joost Ronkes Agerbeek

Maybe. it's always hard to guess what a team thinks; usually we only
see what they do. In this case, I suspect that they simply didn't
think of the more general use of p-> (and obj. )

I don't think that (in general or in this case) prohibiting a safe
operations increases readability. If calling p->f() where the value of
p isn't use is bad, then how about calling p->f() and not using p (by
accessing only static members from within f())? Should that be
outlawed also? I think not. In that direction lies serious "nannyism".

- Bjarne Stroustrup; http://www.research.att.com/~bs

 

[Hendrik Schober]

[...]

For the same reason the users should care
about whether a member function is 'const'
or not: One will not change the object it
is called for while the other one might.
The only way to find out about this now
is from looking at the signature -- which
is not really all that bad. However, _if_
only the special syntax for static member
functions was allowed, it would be easier
to avoid that Murphy guy.

Would you also like the language prohibit calls of const member
functions for non-const objects? The general idea is to allow safe
operations, such as invoking const member functions on non-const
objects and static member functions for an object, while disallowing
potentially damaging ones, such as invoking a non-const member
function for a const object or a non-static member function without an
object.

You are right, the distinction is mostly
important in one way only, and this way
is already blocked.
I guess I didn't think enough about this.

I don't think Murphy enters into this.

Oh, he always finds a way.

[...]

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Gianni Mariani]

[...]
The reason for allowing p->static_member_function(); is exactly not to
require a user to remember if a function is static or not. Why should
the user care, except in the case where he/she wants to call without
an object?

For the same reason the users should care
about whether a member function is 'const'
or not: One will not change the object it
is called for while the other one might.
The only way to find out about this now
is from looking at the signature -- which
is not really all that bad. However, _if_
only the special syntax for static member
functions was allowed, it would be easier
to avoid that Murphy guy.

Would you also like the language prohibit calls of const member
functions for non-const objects? The general idea is to allow safe
operations, such as invoking const member functions on non-const
objects and static member functions for an object, while disallowing
potentially damaging ones, such as invoking a non-const member
function for a const object or a non-static member function without an
object.

I don't think Murphy enters into this.

Forgive my off-topic indulgence....

Perhaps this is a generalization of this rule :

"Avoid imposing arbitrary limitations to the utility of a system"

Far too often I see programmers/system designers that create very
specific designs that limit the usefullness of their labour for short
sighted reasons. Sometimes it is due to limitation of knowledge (which
we are all guilty of - mosly myself). However the most annoying reason
is the lack of logical thinking about a problem (which I am also guilty
as charged).

This is one area where I think the computer science profession still
needs some critical skill building.

Back-on-topic .... With all it's warts, C++ does seem to follow this
rule (on the most part) and it is refreshing to see.

p.s. the (on the most part) is because I still run into issues with the
STL - especially iterators - but that's another long story fo another day.

 

[Joost Ronkes Agerbeek]

Maybe. it's always hard to guess what a team thinks; usually we only
see what they do. In this case, I suspect that they simply didn't
think of the more general use of p-> (and obj. )

I'm not guessing. As I said earlier part of what brought up this question
for
me was a passage in A Programmer's Introduction to C# by Eric Gunnerson
regarding calls to static methods (p.66):
"This is unlike the C++ behavior where a static member can be
accessed either through the class name or the instance name. In C++, this
leads to some readability problems, as it's sometimes not clear from the
code whether an access is static or through an instance."
Since Eric Gunnersion is currently on the C# language design team, I
think it's safe to assume that what he writes was the actual consideration
when making the decision not to allow access to static members through
instances.

I don't think that (in general or in this case) prohibiting a safe
operations increases readability. If calling p->f() where the value of
p isn't use is bad, then how about calling p->f() and not using p (by
accessing only static members from within f())? Should that be
outlawed also? I think not. In that direction lies serious "nannyism".

I can see where you're coming from and I think it's a valid rule of
thumb. Again, I'm not partial to either view. I'm a language user, not
a language designer so I tend to take a language as it is.

Of course I do find these kinds of discussions interesting and useful,
otherwise I wouldn't have brought it up.

Joost Ronkes Agerbeek

 

[Bjarne Stroustrup]

Bjarne Stroustrup wrote:


Forgive my off-topic indulgence....

Perhaps this is a generalization of this rule :

"Avoid imposing arbitrary limitations to the utility of a system"

More like a special case of that rule.

Far too often I see programmers/system designers that create very
specific designs that limit the usefullness of their labour for short
sighted reasons. Sometimes it is due to limitation of knowledge (which
we are all guilty of - mosly myself). However the most annoying reason
is the lack of logical thinking about a problem (which I am also guilty
as charged).

This is one area where I think the computer science profession still
needs some critical skill building.

I agree

Back-on-topic .... With all it's warts, C++ does seem to follow this
rule (on the most part) and it is refreshing to see.

At least "C++" conciously tries to. For example, see my design rules
of thumb in "The Design and Evolution of C++"

p.s. the (on the most part) is because I still run into issues with the
STL - especially iterators - but that's another long story fo another day.

If you could express it briefly, it might be an interesting/useful
story.

- Bjarne Stroustrup; http://www.research.att.com/~bs

 

[Bjarne Stroustrup]

I'm not guessing. As I said earlier part of what brought up this question
for
me was a passage in A Programmer's Introduction to C# by Eric Gunnerson
regarding calls to static methods (p.66):
"This is unlike the C++ behavior where a static member can be
accessed either through the class name or the instance name. In C++, this
leads to some readability problems, as it's sometimes not clear from the
code whether an access is static or through an instance."
Since Eric Gunnersion is currently on the C# language design team, I
think it's safe to assume that what he writes was the actual consideration
when making the decision not to allow access to static members through
instances.

Thanks. That's plausible, but not "a safe assumption". Much (most?) of
C# was designed before the the current design team was formed.

I still have no real clue what the "readability problems" were
supposed to be, and I hesitate to guess.

- Bjarne Stroustrup; http://www.research.att.com/~bs

 

[Gianni Mariani]

....


If you could express it briefly, it might be an interesting/useful
story.

OK.

issue 1.

When using pointers, 0 is an intersting value because it can indicate
"not pointing to anything". For many types of function templates,
iterators and pointers are nearly (mostly) interchangeable types
(granted - some iterators lack all the features). However, one very
interesting feature is the "nil" or "not pointing to anything" iterator.


issue 2.

Container complexity - I come across the need for multi-faceted
containers (an object being organized in a map and a list - list for
fifo and map for searching). To use the STL you need to create
placeholder objects while if I was to write this by hand, I could make a
more efficient system whereby you could in essance create composite
containers. Admitdedly, this requires more complex interfaces but I
think it's possible to have the current interface and a lower level
interface.

 

[Kevin Goodsell]

issue 1.

When using pointers, 0 is an intersting value because it can indicate
"not pointing to anything". For many types of function templates,
iterators and pointers are nearly (mostly) interchangeable types
(granted - some iterators lack all the features). However, one very
interesting feature is the "nil" or "not pointing to anything" iterator.

I don't get that. Are you saying that there should be a nil iterator?
Iterators are usually used to delimit a sequence, or to indicate a
single element, and a nil iterator wouldn't be useful for either. And of
course no standard algorithms or other functions expect such a thing. If
you need an iterator to indicate "no element" you should use
container.end(). Am I misunderstanding something?

-Kevin

 

[Gianni Mariani]

I don't get that. Are you saying that there should be a nil iterator?
Iterators are usually used to delimit a sequence, or to indicate a
single element, and a nil iterator wouldn't be useful for either. And of
course no standard algorithms or other functions expect such a thing. If
you need an iterator to indicate "no element" you should use
container.end(). Am I misunderstanding something?

But ... sometimes you don't have access to a container.

 

[Kevin Goodsell]

But ... sometimes you don't have access to a container.

Then what would your iterator refer to? OK, dumb question - you are
talking about an iterator that doesn't refer to anything. But I'm not
sure when such a thing would be useful.

-Kevin

 

[Gianni Mariani]

....
Then what would your iterator refer to? OK, dumb question - you are
talking about an iterator that doesn't refer to anything. But I'm not
sure when such a thing would be useful.

-Kevin

Here is an example of a smart "pointer ?" template - one using an
iterator and another using real pointers. It's a "fabricated" example
but similar to a RealWorld(TM) problem I had to solve in a galaxy far
far away.


template <typename w_iter>
struct iter_manager
{
w_iter m_managed_iter;

iter_manager( const w_iter & i_managed_iter )
: m_managed_iter( i_managed_iter )
{
}

iter_manager()
{
}

~iter_manager()
{
// OOPS - no way of knowing if iter is any good.
m_managed_iter->DoneFor();
}

};



template <typename w_pointer>
struct pointer_manager
{
w_pointer m_managed_pointer;

pointer_manager( const w_pointer i_managed_pointer = 0 )
: m_managed_pointer( i_managed_pointer )
{
}

~pointer_manager()
{
if ( i_managed_pointer )
{
m_managed_pointer->DoneFor();
}
}

};