In article <cesji2$14p4$1@digitaldaemon.com>, Derek Parnell says...

>The docs say "virtual" functions only

I thought that /all/ member functions were virtual, unless explicitly marked as non-virtual by means of the keyword "final".

>and you are not using it with virtual functions

I see no "final" - so I conclude that this is not so.


>so call me silly.

No. I don't do that.
Jill

On Thu, 5 Aug 2004 07:21:00 +0000 (UTC), Arcane Jill wrote:

> In article <cesji2$14p4$1@digitaldaemon.com>, Derek Parnell says...
> 
>>The docs say "virtual" functions only
> 
> I thought that /all/ member functions were virtual, unless explicitly marked as non-virtual by means of the keyword "final".
> 
>>and you are not using it with virtual functions
> 
> I see no "final" - so I conclude that this is not so.
> 
> 
>>so call me silly.
> 
> No. I don't do that.
> Jill

Oh! As I'm not used to the traditionally used OO jargon, I could probably do with a good OO Jargon Buster manual.

I thought that a virtual function was one that didn't have a body, just a signature.

  abstract void Foo(); // virtual
  void Bar(){}  // not virtual.

I'll shut up now and go do some research on these terms ;-)

-- 
Derek
Melbourne, Australia

Derek Parnell wrote:

<snip>
> I still think that there is no bug and it's your attempted usage that is
> the issue. The docs say "virtual" functions only and you are not using it
> with virtual functions - so call me silly.

That means that it's illegal to apply the override keyword to a non-virtual function.  Not that doing so has no effect.  So of course it's a bug.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Arcane Jill wrote:

> In article <cesji2$14p4$1@digitaldaemon.com>, Derek Parnell says...
> 
>> The docs say "virtual" functions only
> 
> I thought that /all/ member functions were virtual, unless explicitly marked as
> non-virtual by means of the keyword "final".
<snip>

From the docs:

"All non-static non-private member functions are virtual."

This is a private member being talked about, so there's a chance that it isn't virtual.

Final doesn't declare a function to be non-virtual.  In fact, a final method would need to be virtual if it is itself an override.  From a semantic point of view, it's still virtual even if it isn't an override, but the compiler would no doubt optimise it to be non-virtual.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

In article <cetadn$1k9b$1@digitaldaemon.com>, Stewart Gordon says...
>
> From the docs:
>
>"All non-static non-private member functions are virtual."
>
>This is a private member being talked about, so there's a chance that it isn't virtual.

For the record, if you change the member to protected then it becomes virtual and prints "B."  In fact it even prints "B" if override is removed.  So I would consider this intended behavior.


Sean

In article <cetadn$1k9b$1@digitaldaemon.com>, Stewart Gordon says...
>
> From the docs:
>
>"All non-static non-private member functions are virtual."
>
>This is a private member being talked about, so there's a chance that it isn't virtual.

If it isn't virtual then the 'override' should not be allowed. However, it must be virtual, since it overrides a virtual function. That's how it works in C++ at least. And overriding a virtual member with a non-virtual one doesn't make much sense to me.

>Final doesn't declare a function to be non-virtual.  In fact, a final method would need to be virtual if it is itself an override.  From a semantic point of view, it's still virtual even if it isn't an override, but the compiler would no doubt optimise it to be non-virtual.

I agree with this.

Nick

Sean Kelly wrote:

> In article <cetadn$1k9b$1@digitaldaemon.com>, Stewart Gordon says...
> 
>>From the docs:
>>
>>"All non-static non-private member functions are virtual."
>>
>>This is a private member being talked about, so there's a chance that it isn't virtual.
> 
> For the record, if you change the member to protected then it becomes virtual

Of course.  Since A.test is private, it doesn't exist in the scope of B.   And so B.test is a distinct method, with no relation to A.test.

OTOH, if A.test is protected, then B inherits it.  Consequently, a new B.test with the same parameters will override it.

> and prints "B."  In fact it even prints "B" if override is removed.  So I would
> consider this intended behavior.

I can't for the life of me see why the OP's code would ever print "B.".  Intended behaviour AIUI is that override never has any effect on the code generated, only on compiler errors.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

In article <cevpin$75a$1@digitaldaemon.com>, Stewart Gordon says...
>
>Of course.  Since A.test is private, it doesn't exist in the scope of B.
>   And so B.test is a distinct method, with no relation to A.test.

No, A.test /isn't/ private. Check back to the original bug report:

class A
{
  protected void create()
  {
    printf ("A");
  }

  void test()
  {
        create();
  }
}

class B : A
{
   private override void create()
   {
    printf ("B");
   }
}

void main()
{
  B b = new B;
  b.test();
}

As you will observe, A.create() is protected, and not final. Therefore, it is /reasonable/ to expect that a derived class may override it. In this case, a derived class B has overridden it, and, further, has made it private /at this point/ in order that it not be overridden further. I would therefore expect A.test() to call B.create().

No?

Arcane Jill wrote:

> In article <cevpin$75a$1@digitaldaemon.com>, Stewart Gordon says...
> 
>>Of course.  Since A.test is private, it doesn't exist in the scope of B. 
>>  And so B.test is a distinct method, with no relation to A.test.
> 
> 
> No, A.test /isn't/ private. Check back to the original bug report:

Oops.

<snip>
> As you will observe, A.create() is protected, and not final.   Therefore, it is
> /reasonable/ to expect that a derived class may override it.

Yes, but obviously not with a private method.

> In this case, a derived class B has overridden it, and, further, has made it private /at this
> point/ in order that it not be overridden further.

I wouldn't have thought that you could tighten the access when overriding a method.  You use final to stop it being overridden further, don't you?

> I would therefore expect A.test() to call B.create().

Is the actual effect of this (once the word override has been taken out) defined?  It's certainly a cause of confusion, and I'm inclined to suggest it shouldn't be allowed.

But that's one thing.  The bug whereby non-overrides can be declared as override is another.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

In article <cf0h6b$ob2$1@digitaldaemon.com>, Stewart Gordon says...
>
>> As you will observe, A.create() is protected, and not final.   Therefore, it is /reasonable/ to expect that a derived class may override it.
>
>Yes, but obviously not with a private method.

Just to make things really interesting, I added another class. Note now that A's method is protected; B's method is private; and C's method is public:

# class A
# {
#   protected void create()
#   {
#     printf ("A");
#   }
#
#   void test()
#   {
#         create();
#   }
# }
#
# class B : A
# {
#    private override void create()
#    {
#     printf ("B");
#    }
# }
#
# class C : B
# {
#    override void create()
#    {
#     printf ("C");
#    }
# }
#
# void main()
# {
#   B b = new B;
#   C c = new C;
#   b.test();
#   c.test();
# }

Compiles without complaint.
Prints AC.

Okay, so my understanding of "private" may not be correct, but this is not intuitive.


>I wouldn't have thought that you could tighten the access when overriding a method.

A fair point. In which case, it should be a compile error to declare a private function with the same name and signature as a protected function in a base class - either with or without the keyword "override".


>You use final to stop it being overridden further, don't you?

Yes of course. Silly me.

Arcane Jill