Function Hijacking article

[Stewart Gordon]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:ff8qto$1k6r$2 at digitalmars.com...
> Stewart Gordon wrote:
>> "Walter Bright" <newshound1 at digitalmars.com> wrote in message 
>> news:ff8fi1$fs7$1 at digitalmars.com...
>>> Stewart Gordon wrote:
>> <snip>
>>>> And I noticed that the requirement to specify the override attribute is 
>>>> neither implemented nor documented under attribute.html - what gives?
>>>
>>> It is documented in the function.html and attribute.html.
>>
>> I still can't find it anywhere.
>
> In attribute.html, click on "override" under "Attribute" in the grammar 
> section.

I already did.  I get this:

"The override attribute applies to virtual functions. It means that the 
function must override a function with the same name and parameters in a 
base class. The override attribute is useful for catching errors when a base 
class's member function gets its parameters changed, and all derived classes 
need to have their overriding functions updated."

followed by a code example that demonstrates this.  So it states that the 
override attribute _may_ be used if it overrides, and _must not_ be used if 
it doesn't override.  I can't see anything there that relates to a 
circumstance in which the override attribute _must_ be used to make the code 
compile.  What am I missing?

> In function.html, search for "override".

I already did.  The only hits either don't address the question of required 
or not, or blatantly violate the requirement.

<snip>
>> I'm not with you.  How exactly does this render my example susceptible to 
>> the hijacking problem?
>
> If Qwert defines a function def:
>
> void def()
> {
> yuiop(1);
> }

You state that this particular form of hijacking problem occurs because a 
call originally to yuiop(long) becomes a call to yuiop(int) when such a 
method is added to the base class.  But since yuiop(1) can never have 
possibly been a call to any yuiop(string), why is it a problem?

It's true that the creator of class Qwert could have changed the call in 
Qwert.def, e.g. from yuiop("1") to yuiop(1).  But it's equally possible that 
the new method with an int parameter could have been given a completely 
different name, and def changed to call that.  Indeed, if two function 
signatures can never be matched by identical-looking argument lists, UIMS it 
makes no difference whether the functions have the same name or not.

Stewart.

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