Calling static member function through object instance

Why is it allowed in C++ to call a static member function of an object
through an instance of that object? Is it just convenience?

tia,
Joost Ronkes Agerbeek

re: Calling static member function through object instance

Joost Ronkes Agerbeek wrote:[color=blue]
> Why is it allowed in C++ to call a static member function of an object
> through an instance of that object? Is it just convenience?
>[/color]

Static member functions primarily follow the invocation convention for
member functions. However as they may be invoked without constructing
any object the extra syntax (qualified id) is provided for this case.

Regards,
Janusz

re: Calling static member function through object instance

"Joost Ronkes Agerbeek" <joost@ronkes.nl> wrote in message
news:4005192f$0$314$e4fe514c@news.xs4all.nl...[color=blue]
> Why is it allowed in C++ to call a static member function of an object
> through an instance of that object? Is it just convenience?[/color]

I think the question might be answered if you asked a different question.
If I were to ask you why it should NOT be allowed, what would you say?

re: Calling static member function through object instance

> I think the question might be answered if you asked a different question.[color=blue]
> If I were to ask you why it should NOT be allowed, what would you say?[/color]
I would say that, were it not allowed, it would always be clear whether a
call was to a static member or a non-static member.

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

By the way, I sent a reply to Janusz, but accidentely sent it to him in
person instead of to the newsgroup. Here is my reply and his reply to that
reply. (I removed the offending button in my newsreader ;-).)

Thanks for your insights.

Joost

Joost Ronkes Agerbeek wrote:[color=blue]
> Isn't it the other way around? Static member functions operate on the[/color]
class,[color=blue]
> not the object, so you have to write object::static_function() but for
> convenience you can also write instance.static_function(). I know C#[/color]
doesn't[color=blue]
> allow invoking a member function on an object instance: you have to use[/color]
the[color=blue]
> class so that it is always clear you are calling a static member function.
> This triggered my original question: if there is an explicit reason the
> designers of C# don't allow static member invocation through an instance,
> then the designers of C++ must also have a reason why they do allow static
> member invocation through an instance, but what is it?[/color]

Hard to speak in the name of C++ designers, however in the C++ standard
(9.4/2) one may find the following statement:

"A static member s of class X may be referred to using the qualified-id
expression X::s; it is not necessary to use the class member access
syntax. (5.2.5)"

5.2.5 says about . -> type access

Some paragraphs before discuss class member access in general and from
that perspective one may think of static members as a special case
following the general concept as close as possible.
AFAIK static member functions were not present in C++ from the beginning
and were added somewhat later. So they were expected not to introduce
too many changes.

So I think it may be the reason of differences between C++ (and Java I
think) and C#. The first attitude focuses on keeping language concepts
consistent, fitting static member functions in the scope of member
functions and the second keeps clean programming style in mind.

Regards,
Janusz

re: Calling static member function through object instance

"Joost Ronkes Agerbeek" <joost@ronkes.nl> wrote in message
news:40064abd$0$333$e4fe514c@news.xs4all.nl...[color=blue][color=green]
> > I think the question might be answered if you asked a different[/color][/color]
question.[color=blue][color=green]
> > If I were to ask you why it should NOT be allowed, what would you say?[/color][/color]
[color=blue]
> I would say that, were it not allowed, it would always be clear whether a
> call was to a static member or a non-static member.
>
> Part of what brought up this question for me was a passage in A[/color]
Programmer's[color=blue]
> 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."[/color]

Bjarne Stroustrup wrote a book about the design choices for the C++
language - you might find a definitive answer there. I've thought for about
5 seconds and don't have an idea about a case where that confusion might
cause a problem, but there might well be one.

re: Calling static member function through object instance

Joost Ronkes Agerbeek wrote:
[color=blue]
> Why is it allowed in C++ to call a static member function of an object
> through an instance of that object? Is it just convenience?[/color]

It is *not* allowed.
[color=blue]
> Is it just convenience?[/color]

re: Calling static member function through object instance

It is allowed. For convenience is probably the best answer.

Example:
#include <iostream>

class A
{
public:
static void foo() { std::cout << "foobar" << std::endl; };
};

int
main()
{
A a;
a.foo();
}

Output: foobar

E. Robert Tisdale wrote:[color=blue]
> Joost Ronkes Agerbeek wrote:
>[color=green]
>> Why is it allowed in C++ to call a static member function of an object
>> through an instance of that object? Is it just convenience?[/color]
>
>
> It is *not* allowed.
>[color=green]
>> Is it just convenience?[/color]
>
>[/color]

re: Calling static member function through object instance

Even the following code works!

#include <cstdio>
class A {
public:
static void foo() { printf("Hello world.\n"); };
};
int main() {
A* a[10];
int i;
for(i=0; i<10; i++)
a[i] = 0;
a[5]->foo();
a[50]->foo();
}

re: Calling static member function through object instance

Dario wrote:[color=blue]
>
> Even the following code works![/color]

But *this* code is illegal.
[color=blue]
>
> #include <cstdio>
> class A {
> public:
> static void foo() { printf("Hello world.\n"); };
> };
> int main() {
> A* a[10];
> int i;
> for(i=0; i<10; i++)
> a[i] = 0;
> a[5]->foo();
> a[50]->foo();[/color]

you are dereferencing a 0-pointer.
And this is always a no-no, even if
your specific system does *not* crash.

--
Karl Heinz Buchegger
kbuchegg@gascad.at

re: Calling static member function through object instance

Karl Heinz Buchegger wrote:[color=blue]
> Dario wrote:
>[color=green]
>> Even the following code works![/color]
>
>
> But *this* code is illegal.
>
>[color=green]
>> #include <cstdio>
>> class A {
>> public:
>> static void foo() { printf("Hello world.\n"); };
>> };
>> int main() {
>> A* a[10];
>> int i;
>> for(i=0; i<10; i++)
>> a[i] = 0;
>> a[5]->foo();
>> a[50]->foo();[/color]
>
>
> you are dereferencing a 0-pointer.
> And this is always a no-no, even if
> your specific system does *not* crash.[/color]

No !

When I evaluate
a[5]->foo()
a[5] is 0 but this does not matter
because foo is a static member;
a[50]->foo()
a[50] is whatever but this does not matter
because foo is a static member.

So my program is legal and works for every C++ compiler.

- Dario

re: Calling static member function through object instance

Dario wrote:[color=blue]
>[/color]
[color=blue][color=green]
> > you are dereferencing a 0-pointer.
> > And this is always a no-no, even if
> > your specific system does *not* crash.[/color]
>
> No ![/color]

Yes.
Read your code.
[color=blue]
>
> When I evaluate
> a[5]->foo()
> a[5] is 0 but this does not matter
> because foo is a static member;
> a[50]->foo()
> a[50] is whatever but this does not matter
> because foo is a static member.
>
> So my program is legal and works for every C++ compiler.[/color]

It is not legal, read the standard.
It doesn't matter if your compiler doesn't need
to dereference the pointer to call this function
under the hood. Your source code contains the
dereference and hence it is an illegal program.

--
Karl Heinz Buchegger
kbuchegg@gascad.at

re: Calling static member function through object instance

In article <bu8950$oid$1@grillo.cs.interbusiness.it>,
dario@despammed.com says...

[ ... ]
[color=blue][color=green]
> > you are dereferencing a 0-pointer.
> > And this is always a no-no, even if
> > your specific system does *not* crash.[/color]
>
> No !
>
> When I evaluate
> a[5]->foo()
> a[5] is 0 but this does not matter
> because foo is a static member;[/color]

This is utterly irrelevant -- 5.2.5/1 says "the expression before the
dot or arrow is evaluated". Footnote 58 explicitly states that "This
evaluation happens even if the result is unnecessary to determine the
value of the entire postfix expression, for example if the id-expression
denotes a static member."

As such, you're assured that this dereferences a null pointer, which
gives undefined behavior.
[color=blue]
> So my program is legal and works for every C++ compiler.[/color]

Your program contains undefined behavior. If your definition of
"works" includes the possibility of crashing the computer, reformatting
the hard drive or making demons fly out of your nose, then you're right:
it works for every C++ compiler. Anybody who has a stricter definition
of work will want to avoid this construct.

--
Later,
Jerry.

The universe is a figment of its own imagination.

re: Calling static member function through object instance

On Thu, 15 Jan 2004 11:11:46 -0500, "jeffc" <nobody@nowhere.com>
wrote:[color=blue]
>"Joost Ronkes Agerbeek" <joost@ronkes.nl> wrote in message
>news:40064abd$0$333$e4fe514c@news.xs4all.nl...[color=green][color=darkred]
>> > I think the question might be answered if you asked a different[/color][/color]
>question.[color=green][color=darkred]
>> > If I were to ask you why it should NOT be allowed, what would you say?[/color][/color]
>[color=green]
>> I would say that, were it not allowed, it would always be clear whether a
>> call was to a static member or a non-static member.
>>
>> Part of what brought up this question for me was a passage in A[/color]
>Programmer's[color=green]
>> 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."[/color]
>
>Bjarne Stroustrup wrote a book about the design choices for the C++
>language - you might find a definitive answer there. I've thought for about
>5 seconds and don't have an idea about a case where that confusion might
>cause a problem, but there might well be one.[/color]

It caught me out (shockingly recently), somehow I managed to miss the
whole call via instance mechanism for the 8+ years I've used c++, I
always used the :: form and I never saw anyone else do otherwise....

class BlahBlah
{
public:
BlahBlah& Instance(); // some sort of singleton i/f

private:
static void Eot( Client* client, int flags, void* uopt )
{
// Mistaken assumption: overload resolution calls
// the non-static member ( due to implicit 'this' )
// Actual behaviour: Recursive call & hang!
Instance().Eot( client, flags, uopt );
}
void Eot( Client* client, int flags, void* uopt );
};

In case you're wondering this was just code to interface
to a 3rd party C lib that used callbacks (yuk). Usually I would have
had different names for the two Eot() functions, but not this
time for some reason.

I would have thought the compiler might have determined
the Eot call to be amibiguous, but it didn't ( Compiler was a gcc
2.95.x derivitive.). Does a static member function rate higher
than an ordinary member function in overload resolution?

re: Calling static member function through object instance

Andy Buchanan <news@globbits.co.uk> wrote in message news:<qusm00drgqgjip58kehcpp24mvufdig6od@4ax.com>. ..[color=blue]
> On Thu, 15 Jan 2004 11:11:46 -0500, "jeffc" <nobody@nowhere.com>
> wrote:[color=green]
> >"Joost Ronkes Agerbeek" <joost@ronkes.nl> wrote in message
> >news:40064abd$0$333$e4fe514c@news.xs4all.nl...[color=darkred]
> >> > I think the question might be answered if you asked a different[/color][/color]
> question.[color=green][color=darkred]
> >> > If I were to ask you why it should NOT be allowed, what would you say?[/color][/color]
>[color=green][color=darkred]
> >> I would say that, were it not allowed, it would always be clear whether a
> >> call was to a static member or a non-static member.
> >>
> >> Part of what brought up this question for me was a passage in A[/color][/color]
> Programmer's[color=green][color=darkred]
> >> 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."[/color]
> >
> >Bjarne Stroustrup wrote a book about the design choices for the C++
> >language - you might find a definitive answer there. I've thought for about
> >5 seconds and don't have an idea about a case where that confusion might
> >cause a problem, but there might well be one.[/color][/color]

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?

[color=blue]
> It caught me out (shockingly recently), somehow I managed to miss the
> whole call via instance mechanism for the 8+ years I've used c++, I
> always used the :: form and I never saw anyone else do otherwise....
>
> class BlahBlah
> {
> public:
> BlahBlah& Instance(); // some sort of singleton i/f
>
> private:
> static void Eot( Client* client, int flags, void* uopt )
> {
> // Mistaken assumption: overload resolution calls
> // the non-static member ( due to implicit 'this' )
> // Actual behaviour: Recursive call & hang!
> Instance().Eot( client, flags, uopt );
> }
> void Eot( Client* client, int flags, void* uopt );
> };
>
> In case you're wondering this was just code to interface
> to a 3rd party C lib that used callbacks (yuk). Usually I would have
> had different names for the two Eot() functions, but not this
> time for some reason.
>
> I would have thought the compiler might have determined
> the Eot call to be amibiguous, but it didn't ( Compiler was a gcc
> 2.95.x derivitive.). Does a static member function rate higher
> than an ordinary member function in overload resolution?[/color]

No. That declaration is illegal. From the standard:

"[class.static.mfct] 9.4.1 Static member functions

There shall not be a static and a nonstatic member function with the
same name
and the same parameter types (13.1)."

This has always been the rule. Without that rule, people could get
into all kinds of nasty problems.

It is always most anoying when a compiler fails to implement a clear
and simple language rule.

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

re: Calling static member function through object instance

> > When I evaluate[color=blue][color=green]
> > a[5]->foo()
> > a[5] is 0 but this does not matter
> > because foo is a static member;[/color]
>
> This is utterly irrelevant -- 5.2.5/1 says "the expression before the
> dot or arrow is evaluated". Footnote 58 explicitly states that "This
> evaluation happens even if the result is unnecessary to determine the
> value of the entire postfix expression, for example if the id-expression
> denotes a static member."
>
> As such, you're assured that this dereferences a null pointer, which
> gives undefined behavior.[/color]

Your quote is irrelevant. "the expression before the dot or arrow"
is "a[5]". This is easy to evaluate: 0
You will have to look elsewhere in the Standard to find a definitive
answer.
Next question: what is the difference, if any, between:
a[5]->foo()
(*a[5]).foo()

re: Calling static member function through object instance

On 19 Jan 2004 07:01:14 -0800, bs@research.att.com (Bjarne Stroustrup)
wrote:[color=blue]
>Andy Buchanan <news@globbits.co.uk> wrote in message news:<qusm00drgqgjip58kehcpp24mvufdig6od@4ax.com>. ..[/color]
<!--Snipped for brevity-->[color=blue][color=green]
>> It caught me out (shockingly recently), somehow I managed to miss the
>> whole call via instance mechanism for the 8+ years I've used c++, I
>> always used the :: form and I never saw anyone else do otherwise....
>>
>> class BlahBlah
>> {
>> public:
>> BlahBlah& Instance(); // some sort of singleton i/f
>>
>> private:
>> static void Eot( Client* client, int flags, void* uopt )
>> {
>> // Mistaken assumption: overload resolution calls
>> // the non-static member ( due to implicit 'this' )
>> // Actual behaviour: Recursive call & hang!
>> Instance().Eot( client, flags, uopt );
>> }
>> void Eot( Client* client, int flags, void* uopt );
>> };
>>
>> In case you're wondering this was just code to interface
>> to a 3rd party C lib that used callbacks (yuk). Usually I would have
>> had different names for the two Eot() functions, but not this
>> time for some reason.
>>
>> I would have thought the compiler might have determined
>> the Eot call to be amibiguous, but it didn't ( Compiler was a gcc
>> 2.95.x derivitive.). Does a static member function rate higher
>> than an ordinary member function in overload resolution?[/color]
>
>No. That declaration is illegal. From the standard:
>
>"[class.static.mfct] 9.4.1 Static member functions
>
> There shall not be a static and a nonstatic member function with the
>same name
>and the same parameter types (13.1)."
>
>This has always been the rule. Without that rule, people could get
>into all kinds of nasty problems.[/color]

As indeed I did. I shant be making this mistake again even if the
compiler lets me. Thanks for the pointer.
[color=blue]
>It is always most anoying when a compiler fails to implement a clear
>and simple language rule.[/color]

Alas the compiler in question has allowed a number of other
incorrect constructs. As a further alas, I'm pretty much stuck with
it for the rest of the project (and probably the next). <sigh>
[color=blue]
>
> - Bjarne Stroustrup; http://www.research.att.com/~bs[/color]

re: Calling static member function through object instance

"Bjarne Stroustrup" <bs@research.att.com> wrote in message
news:188b3370.0401190701.29eb730d@posting.google.c om...[color=blue]
> 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?[/color]

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

re: Calling static member function through object instance

Bjarne Stroustrup <bs@research.att.com> wrote:[color=blue]
> [...]
> 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?[/color]

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.
[color=blue]
> [...]
> - Bjarne Stroustrup; http://www.research.att.com/~bs[/color]


Schobi

--
SpamTrap@gmx.de is never read
I'm Schobi at suespammers dot org

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

re: Calling static member function through object instance

"Hendrik Schober" <SpamTrap@gmx.de> wrote in message news:<buj2n8$o2e$1@news1.transmedia.de>...[color=blue]
> Bjarne Stroustrup <bs@research.att.com> wrote:[color=green]
> > [...]
> > 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?[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
> > [...]
> > - Bjarne Stroustrup; http://www.research.att.com/~bs[/color]
>
>
> Schobi[/color]

re: Calling static member function through object instance

Andy Buchanan <news@globbits.co.uk> wrote > >It is always most anoying
when a compiler fails to implement a clear[color=blue][color=green]
> >and simple language rule.[/color]
>
> Alas the compiler in question has allowed a number of other
> incorrect constructs. As a further alas, I'm pretty much stuck with
> it for the rest of the project (and probably the next). <sigh>[/color]

For what it's worth, gcc 3.3.2 doesn't have that problem.
[color=blue][color=green]
> >
> > - Bjarne Stroustrup; http://www.research.att.com/~bs[/color][/color]

re: Calling static member function through object instance

"Joost Ronkes Agerbeek" <joost@ronkes.nl> wrote in message news:<400d04ee$0$333$e4fe514c@news.xs4all.nl>...[color=blue]
> "Bjarne Stroustrup" <bs@research.att.com> wrote in message
> news:188b3370.0401190701.29eb730d@posting.google.c om...[color=green]
> > 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?[/color]
>
> 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[/color]

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

re: Calling static member function through object instance

Bjarne Stroustrup <bs@research.att.com> wrote:[color=blue]
> [...][color=green][color=darkred]
> > > 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?[/color]
> >
> > 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.[/color]
>
> 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.[/color]

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.
[color=blue]
> I don't think Murphy enters into this.[/color]

Oh, he always finds a way. :)

[...]

Schobi

--
SpamTrap@gmx.de is never read
I'm Schobi at suespammers dot org

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

re: Calling static member function through object instance

Bjarne Stroustrup wrote:[color=blue]
> "Hendrik Schober" <SpamTrap@gmx.de> wrote in message news:<buj2n8$o2e$1@news1.transmedia.de>...
>[color=green]
>>Bjarne Stroustrup <bs@research.att.com> wrote:
>>[color=darkred]
>>>[...]
>>>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?[/color]
>>
>> 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.[/color]
>
>
> 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.
>[/color]

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.

re: Calling static member function through object instance

"Bjarne Stroustrup" <bs@research.att.com> wrote in message
news:188b3370.0401200952.544ee8bc@posting.google.c om...[color=blue]
> 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. )[/color]
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.
[color=blue]
> 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".[/color]
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

re: Calling static member function through object instance

Gianni Mariani <gi2nospam@mariani.ws> wrote
[color=blue]
> Bjarne Stroustrup wrote:[/color]

[color=blue][color=green]
> > 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.[/color]
>
> Forgive my off-topic indulgence....
>
> Perhaps this is a generalization of this rule :
>
> "Avoid imposing arbitrary limitations to the utility of a system"[/color]

More like a special case of that rule.
[color=blue]
> 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.[/color]

I agree
[color=blue]
> 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.[/color]

At least "C++" conciously tries to. For example, see my design rules
of thumb in "The Design and Evolution of C++"
[color=blue]
> 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.[/color]

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

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

re: Calling static member function through object instance

"Joost Ronkes Agerbeek" <joost@ronkes.nl> wrote[color=blue]
> "Bjarne Stroustrup" <bs@research.att.com> wrote[color=green]
> > 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. )[/color]
> 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.[/color]

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

re: Calling static member function through object instance

Bjarne Stroustrup wrote:[color=blue]
> Gianni Mariani <gi2nospam@mariani.ws> wrote
>[/color]
....[color=blue]
>[color=green]
>>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.[/color]
>
>
> If you could express it briefly, it might be an interesting/useful
> story.[/color]

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.

re: Calling static member function through object instance

Gianni Mariani wrote:[color=blue]
>
> 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.[/color]

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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

re: Calling static member function through object instance

Kevin Goodsell wrote:[color=blue]
> Gianni Mariani wrote:
>[color=green]
>>
>> 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.[/color]
>
>
> 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?[/color]

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

re: Calling static member function through object instance

Gianni Mariani wrote:[color=blue]
> Kevin Goodsell wrote:
>[color=green]
>> Gianni Mariani wrote:
>>[color=darkred]
>>>
>>> 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.[/color]
>>
>>
>>
>> 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?[/color]
>
>
> But ... sometimes you don't have access to a container.
>[/color]

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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

re: Calling static member function through object instance

Kevin Goodsell wrote:[color=blue]
> Gianni Mariani wrote:
>[color=green]
>> Kevin Goodsell wrote:
>>[color=darkred]
>>> Gianni Mariani wrote:
>>>[/color][/color][/color]
....[color=blue]
> 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[/color]


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();
}
}

};