Bruce Mellows wrote:
> If one were to supply and 'override' keyword, then the compiler can know
> that the method was intended to override a virtual but does not, and can
> take some suitable action.
>

A few comments, in reply to this, as well as all the comments so far:

1. I would really like a solution for this - I run into this problem
sometimes, and more importantly (to me) I would like to be able to
encode my intent more clearly (in code, not in comments).  Maybe
everywhere I've worked for the last 20 years has bad coding pratices
(probably true actually), but - or maybe 'therefore' would be a better
word - I would appreciate this.

2. Microsoft has a solution already, and it does NOT require a new
keyword:

class Base { virtual void vfunc(); }
class Derived
{
   // qualify using Base:: to say that you are overiding
   // if Base doesn't have a matching vfunc, it is an error
   void Base::vfunc();
};

3. This could be extended to handle the multiple-colliding-bases
problem, which I run into enough to bother me:

class Base1 { virtual void vfunc(); }
class Base2 { virtual void vfunc(); }
class Derived
{
   void Base1::vfunc()
   {
       /* do stuff when someone calls us as a Base1 */
   }
   void Base2::vfunc()
   {
       /* do stuff when someone calls us as a Base2 */

       // p.s. if you need to call Base's version:
       Base2::vfunc(); // calls Base2's version
       Derived::Base2::vfunc(); // calls Derived's version of Base2's
vfunc()

       // or something like that.
   }
};

4. I'm not sure about the syntax for the 'NOT-a-virtual-override' case,
but I'm also not sure I've every run into that problem (of the Base
getting a virtual function added that happens to match the signature of
a function in the derived class).
   I think the answer for that problem is just a diagnostic warning
(that you can turn ON - probably off by default) that warns whenever
you override WITHOUT the new Base:: syntax.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bruce Mellows wrote:
> The method of overriding a virtual method that exists, namely, declaring
> a method with the same signature leads to problems when some change to
> the signature of the method that 'introduces' the virtual occurs.
>
> Specifically, the 'overrides' are no longer overrides, and there is no
> indication of any problem, either for the compiler or the user.
>
> If one were to supply and 'override' keyword, then the compiler can know
> that the method was intended to override a virtual but does not, and can
> take some suitable action.

I agree that the problem exists, but I don't like your proposed
solution. I make extensive use of class templates that take their base
classes as arguments in order to provide a form of adaptation or
default implementation for pure virtual base member functions. In my
template classes I don't even declare member functions as virtual,
because it's not always known a priori that each member function
overrides a base member function. Being forced to mark overrides
explicitly would make my adapters less general.

Cheers,
Nicola Musatti

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Nicola Musatti wrote:
> Bruce Mellows wrote:

> > If one were to supply and 'override' keyword, then the compiler can know
> > that the method was intended to override a virtual but does not, and can
> > take some suitable action.
>
> I agree that the problem exists, but I don't like your proposed
> solution. ... Being forced to mark overrides
> explicitly would make my adapters less general.

I would agree with Nicola that being forced to use 'override' would be
bad.

Proposals I've seen would keep the use optional.  This would be along
the lines of 'private.'  Removing 'private' from some location in an
existing, valid program will result in a program which still compiles,
and will almost always have the same behavior.  In that sense,
'private' is an optional keyword (except in the rare cases where it
changes a programs behavior).  I use private to document my intent, and
to get compiler errors when the code does not match the documented
intent.  An override keyword would have the same behavior.  Removing
the keyword from a program would not change the program's behavior.
Adding the keyword documents intent, and generates diagnostics when the
code does not match the documented intent.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<wade@stoner.com> skrev i meddelandet
news:1124471452.870418.176290@g44g2000cwa.googlegroups.com...
>
> Nicola Musatti wrote:
>> Bruce Mellows wrote:
>
>> > If one were to supply and 'override' keyword, then the compiler
>> > can know
>> > that the method was intended to override a virtual but does not,
>> > and can
>> > take some suitable action.
>>
>> I agree that the problem exists, but I don't like your proposed
>> solution. ... Being forced to mark overrides
>> explicitly would make my adapters less general.
>
> I would agree with Nicola that being forced to use 'override' would
> be
> bad.
>
> Proposals I've seen would keep the use optional.  This would be
> along
> the lines of 'private.'  Removing 'private' from some location in an
> existing, valid program will result in a program which still
> compiles,
> and will almost always have the same behavior.  In that sense,
> 'private' is an optional keyword (except in the rare cases where it
> changes a programs behavior).  I use private to document my intent,
> and
> to get compiler errors when the code does not match the documented
> intent.  An override keyword would have the same behavior.  Removing
> the keyword from a program would not change the program's behavior.
> Adding the keyword documents intent, and generates diagnostics when
> the
> code does not match the documented intent.
>

The problem with this is that some virtual functions will be marked
with the override keyword, and some will not. Those that are not
marked, may be overrides anyway. How does that improve the readability
of the code?


Bo Persson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bo Persson wrote:
> > Removing
> > the keyword from a program would not change the program's behavior.
> > Adding the keyword documents intent, and generates diagnostics when
> > the code does not match the documented intent.
>
> The problem with this is that some virtual functions will be marked
> with the override keyword, and some will not. Those that are not
> marked, may be overrides anyway. How does that improve the readability
> of the code?

In the same way that other optional features, such as comments,
'private', and 'const' improve readability.

I expect that I can remove all occurences of comments in my code
without changing the program's behavior.

I expect that I can remove at least 98% of the 'private:' in my code
without changing the program's behavior (I believe 'private' is only
"observable" with dynamic_cast and 'catch').

I expect that I can remove every occurence of 'const', other than
   ICE (symbolic constants)
   reference to const, pointer to const
   const member functions
without changing the program's "observable" behavior (and if that isn't
true, the code is too subtle).

It is almost certain that there are places where my code would be more
readable with the addition of a comment, 'private:', or 'const'.

The point is that when I do choose to use those features, they (IMHO)
improve readability, and in some cases provide me with some cheap error
detection.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <zKudnf5CQ6IMbGXfRVn-rA@giganews.com>, Pete Becker
<petebecker@acm.org> writes
>For some typos this is true. For others it is not. In particular, if
>you're writing reasonable unit tests you'll find failures to override
>virtual functions without having to test for them explicitly. That's
>about as cheap as it gets.

Of course this is the ongoing stress between the requirements of the
professional programmer who always writes proper unit tests and the
desires of the casual programmer.

While I have a great deal of sympathy with the latter, I also know that
adding features to the language is immensely expensive so, with the
limited resource available to us we have to focus on those features that
have the widest benefit.

Note that there is plenty of room in the market for tools that detect
potential typos of this kind. Any time a programmer adds a new signature
for a function in a derived class, it would be legitimate for a support
tool to query it, particularly if the base class signatures include
virtual functions.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <zKudnf5CQ6IMbGXfRVn-rA@giganews.com>, Pete Becker
> <petebecker@acm.org> writes
> >For some typos this is true. For others it is not. In particular, if
> >you're writing reasonable unit tests you'll find failures to override
> >virtual functions without having to test for them explicitly. That's
> >about as cheap as it gets.
>
> Of course this is the ongoing stress between the requirements of the
> professional programmer who always writes proper unit tests and the
> desires of the casual programmer.

Being able to detect and fix errors is not the only issue.  I want to
reduce the cost of detecting and fixing errors.  With an overload
keyword, the typo will be caught in the compiler (or even in a smart
editor).  I find out about the error shortly after I make it, and the
diagnostics point directly at the mistake.

If the problem is not detected until unit testing, a larger period of
time will have elapsed (perhaps tens of minutes or even days), at which
point I'll know that some piece of functionality is causing the unit
test to fail.  At that point I'll know that there is bug, but I've
still got to figure out where it is (my logic, my spelling, my unit
test's logic, its spelling, some other piece not behaving as
advertised, ...).

In one case, the "cost" of the typo is a few seconds.  In the other, it
is minutes, or longer.  Two or more orders of magnitude is a big
difference, particularly to professional developers.

Additionally, an overload word saves time for readers of the code.
When I'm reviewing code, an "overload" comment may be wrong, so I've
got to check it.  An overload keyword isn't wrong (unless something
very strange is going on).  Likewise, when I'm debugging code that was
written long ago, keywords enforced by the compiler are likely to be
more trustworthy than comments.

A nice feature of C++ is that in most cases if I remember the "wrong"
spelling for an existing id (overflow instead of over_flow), I'll find
out no later than compile time.  There are a few exceptions, such as
when both id's already exist (_1, _2), a forward declaration is wrong,
a namespace is wrong (and I'm counting on Koenig lookup to make a
difference), or an overload is wrong.  The forward declaration case is
caught at link time.  I'd expect the Koening lookup problem to be
exceedingly rare, and I expect programmers to be extra careful when
using identifiers like _2 (or i).

OTOH, I know I've made the overload mistake in C++ (and in languages
that support "overload").  This is far from being C++'s biggest
blemish, but it is visible, and IMO, is worth fixing.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1123702017.062162.206150@g44g2000cwa.googlegroups.com>,
wade@stoner.com writes
>OTOH, I know I've made the overload mistake in C++ (and in languages
>that support "overload").  This is far from being C++'s biggest
>blemish, but it is visible, and IMO, is worth fixing.

Have you spoken with the implementors of the compilers you use? There is
nothing to stop them adding an _Overload extra keyword as an extension.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

wade@stoner.com wrote:

>
> In one case, the "cost" of the typo is a few seconds.  In the other, it
> is minutes, or longer.  Two or more orders of magnitude is a big
> difference, particularly to professional developers.
>

That's only one a part of the first half of the requisite cost/benefit
analysis. The rest of that half is looking at the cost of specifying and
implementing this new keyword, and the cost of using it in code -- more
verbose code being harder to read and understand, additional text and
added compiler complexity slowing down compilation. The other half is
showing that this sort of problem is common enough that a language-level
solution is necessary.

Personally, my fingers often misspell "function" as "funciton". I'd love
it if the compiler detected this and reported an error or corrected it
for me. But I don't think that solution ought to be imposed on all C++
programmers.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

(continued) I will have to retract; I see teher is no easy way to do
the assertion so that it works detectind POD parameter type change.

BUT: I have seen thet the problem of signature change is correctly
detected by some compilers (ie Borland C++ 5.6.4) and issues a warning
about the function in the derived class hiding the same funcitn name in
base class. For anyone who feels no compilation should be OK if there
is a warning, this is enough.
Alas, other compilers don't do it, (ie GCC).

Maybe, instead of creating a new keyword, the solution should be to
enforce the issue of a warning whenever a name in a derived class hides
a name in a base class. Should mena a minor change or no change at all
to nowadays compilers, and the language itself would suffer no real
change.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

IMHO, type corrections should be done by editors (there are some that
already do it).

Returning to the original problem, I think that everything could be
solved with some template programming and/or some macros for asserting
the condition.

I am trying to write an example, will send it as soon as I have it
complete

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Now, I am almost sure: a warning message seems one of the best
solutions to detect the overriding failure.
Anycase, there is a portable soltion, see code below. It works even
when you change the base class signature from int to float (as noted
previously by Victor Bazarov). The main problem is that it should be
implemented for any number of parameters, and it would be desirable to
cnvert most of it from macro to template. ANd of course, it is not
optimized, it is just a first tentative.

/* override assertion */

#define
assert_fuction_overrides(BASE_CLASS,FUNCTION_NAME,RETURN_TYPE,PARAMETER_TYPE)\
{\
  while(0)\
  {\
    RETURN_TYPE
(BASE_CLASS::*ptr_func)(PARAMETER_TYPE)=&BASE_CLASS::FUNCTION_NAME;\
  };\
}


class Base_1
{
  public:
    virtual int whatever(int);
};

class Derived_1:public Base_1
{
  public:
    /* override */ virtual int whatever(int thing)
    {
      assert_fuction_overrides(Base_1,whatever,int,int);
      return thing;
    }
};

class Base_2
{
  public:
    virtual int whatever(double);
};

class Derived_2:public Base_2
{
  public:
    /* override */ virtual int whatever(int thing)
    {
      assert_fuction_overrides(Base_2,whatever,int,int);
      return thing;
    }
};

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bruce Mellows wrote:
>
> The method of overriding a virtual method that exists, namely,
> declaring a method with the same signature leads to problems when
> some change to the signature of the method that 'introduces' the
> virtual occurs.
>
> Specifically, the 'overrides' are no longer overrides, and there
> is no indication of any problem, either for the compiler or the
> user.
>
> If one were to supply and 'override' keyword, then the compiler
> can know that the method was intended to override a virtual but
> does not, and can take some suitable action.

I think that it would be far better to make this keyword compiler specific.
Something like:

  #ifndef GCC
  #define override
  #endif

and then use "override" as if every compiler supports it.  Such a keyword is
only meaningful on the system where main development is done anyway.

In any case, an "override" keyword would be very useful, even if 95% of the
cases where my code was buggy has been caught by the compiler I'm using.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Zara schrieb:
> detected by some compilers (ie Borland C++ 5.6.4) and issues a warning
> about the function in the derived class hiding the same funcitn name in
> base class. For anyone who feels no compilation should be OK if there
> is a warning, this is enough.
> Alas, other compilers don't do it, (ie GCC).

-Woverloaded-virtual

regards,
Helmut
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:

> Daniel Kr=FCgler wrote:
>=20
>>
>> I assume, the main raison for resistance
>> against your and many other similar proposals is, that by introducing
>> a new C++ keyword, you can probably guarantee, that this will
>> break at least one single written code, because someone could have use=
d
>> "override" as usual name.
>>
>=20
> That is a significant factor, but certainly not the main reason for=20
> objecting to language hacks that add clutter in order to work around=20
> defective development processes.

Whether it is a language "hack" or not can only be judged
based on other measures.  It clearly marks intent, and as
code is intended to communicate intent to both compilers
and human readers, that can be advantageous.  As for
working around defective development processes, well thought
out processes make extensive use of tools and techniques
that avoid the recurrence of recognized forms of errors;
explicitly writing "override" may (or may not) be found
to reduce errors in an economical way compared to other
ways of avoiding those errors.

As for the cost of introducing new keywords, in spite of
all that's been said it still appears to me less costly
than a complete avoidance of new keywords.  While we should
not throw new keywords (or any new complexities) into C++
without due care, judicious use of them could make C++ a
more robust language for many developers who use it.  Not
all of them will master it as professional writers of widely
distributed libraries must, and we should seek to provide
help for programmers who may be merely good.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Dennett wrote:

>
> Whether it is a language "hack" or not can only be judged
> based on other measures.  It clearly marks intent,

So do comments.

> and as
> code is intended to communicate intent to both compilers
> and human readers, that can be advantageous.  As for
> working around defective development processes, well thought
> out processes make extensive use of tools and techniques
> that avoid the recurrence of recognized forms of errors;
> explicitly writing "override" may (or may not) be found
> to reduce errors in an economical way compared to other
> ways of avoiding those errors.

One of the most valuable development tools is writing and running test
cases, which, as far as I can tell, also eliminates this "problem." The
real issue is whether the cost of doing it that way is significant
enough to warrant making language changes, with all their ripples
through development tools and development processes. So far there has
been no discussion of how serious this "problem" is, and without that
information it's not possible to make a sound engineering decision.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:

> James Dennett wrote:
>
>>
>> Whether it is a language "hack" or not can only be judged
>> based on other measures.  It clearly marks intent,
>
>
> So do comments.

[see below]

>> and as
>> code is intended to communicate intent to both compilers
>> and human readers, that can be advantageous.

But comments express intent *only* to human readers (unless
we include things like lint comments, which are arguably a
hack to work around language weaknesses).

Adding syntax to the language to express an idea allows the
compiler to check that the intention matches the reality.  It's
a very similar thing to adding "const" -- we could write code
fine without it, but adding const expresses intent nicely, and
prevents common errors.

>> As for
>> working around defective development processes, well thought
>> out processes make extensive use of tools and techniques
>> that avoid the recurrence of recognized forms of errors;
>> explicitly writing "override" may (or may not) be found
>> to reduce errors in an economical way compared to other
>> ways of avoiding those errors.
>
>
> One of the most valuable development tools is writing and running test
> cases, which, as far as I can tell, also eliminates this "problem."

I promote aggressive testing, but I don't think that testing is
the best way to address this issue.  On the other hand, I've not
found it to be a big problem in practice.

> The
> real issue is whether the cost of doing it that way is significant
> enough to warrant making language changes, with all their ripples
> through development tools and development processes. So far there has
> been no discussion of how serious this "problem" is, and without that
> information it's not possible to make a sound engineering decision.

I quite agree.  If there is to be a serious move to add a new
language feature in the name of safety, we ought to make some
attempt to quantify the added safety it would bring.  While it's
not always practical to get extensive data, it's desirable to
have something more than isolated anecdotes or intuition that
this would solve a real probem.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Dennett wrote:
>
> Adding syntax to the language to express an idea allows the
> compiler to check that the intention matches the reality.  It's
> a very similar thing to adding "const" -- we could write code
> fine without it, but adding const expresses intent nicely, and
> prevents common errors.
>

Yes, of course. Once again: there has been no mention of how common the
problems that would be solved by 'override' are; indeed, there can't be,
because they haven't been precisely described. So any comparison with
const or anything else is meaningless.

>
> I promote aggressive testing, but I don't think that testing is
> the best way to address this issue.  On the other hand, I've not
> found it to be a big problem in practice.

Shrug.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:
> Bruce Mellows wrote:
>
> >
> > Otherwise finding all the places where a change to a virtual affects
> > the derived classes can be a problem.
>
> Changing a base class function from virtual to non-virtual affects all
> derived classes. If the writer of a library that I used did that I'd
> replace the library immediately, since the developer is obviously
> irresponsible.

The more likely change is a subtle change in signature.  I'm looking at
some code, written nine years ago, and unchanged since then (the
compilation environment has changed though):

  class foo: public streambuf
  {
    // override streambuf ...
    int overflow(int);
    ...
  };

That code still works (AFAICT) on every implementation it has been used
on, even though it is wrong according to the current standard.  If it
ever goes to a platform where streambuf::int_type is not 'int' it will
fail, quite possibly without any compiler warnings.  I suppose the LWG
was "obviously irresponsible" to make the change (or perhaps the
vendors were irresponsible to follow the LWG ...).

The developer could have attempted to protect against the change with
something similar to

  int (streambuf::*compile_time_override_check)(int) =
    &streambuf::overflow;

but, in the real world, it didn't happen.  This test also would not
have caught a change from virtual to non-virtual, at a time when the
state of streambuf was very much in flux.  IMO it would be better to
replace the override comment and override test with an override
keyword.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

The parallel with const is a strong one, in fact, const could be said
to be more intrusive to the compiler than 'override' (or >0, or
whatever), in that the compiler is required to track const, whereas the
compiler need only report of a discrepancy in this case.

As for providing some metric as to how common the problem is, how
should it be done? Should the C++ user community put up a virtual
polling booth? What form should this poll take to satisfy you? Or would
it be just another internet mob-rampage?

Actually, I personally do have a solution for my own code, but I was
hoping to get a less intrusive solution for my use of others code.

That said, it appears that it is more important to not change the
language and focus on the library for those who have the responsibility
to actually do somethong about it. Fair enough.

One last thing, I don't have the luxury of dismissing 'obviously
irresponsible' developers or suppliers, nor can I mandate 'test cases',
nor can I just pick up and leave. I am just an employee.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

wade@stoner.com wrote:

> Pete Becker wrote:
>
>>Bruce Mellows wrote:
>>
>>
>>>Otherwise finding all the places where a change to a virtual affects
>>>the derived classes can be a problem.
>>
>>Changing a base class function from virtual to non-virtual affects all
>>derived classes. If the writer of a library that I used did that I'd
>>replace the library immediately, since the developer is obviously
>>irresponsible.
>
>
> The more likely change is a subtle change in signature.

Okay. Making a subtle change in the signature of a base class virtual
function affects all derived classes. If the writer of a library that I
used did that I'd replace the library immediately, since the developer
is obviously irresponsible.

> I'm looking at
> some code, written nine years ago, and unchanged since then (the
> compilation environment has changed though):
>
>   class foo: public streambuf
>   {
>     // override streambuf ...
>     int overflow(int);
>     ...
>   };
>
> That code still works (AFAICT) on every implementation it has been used
> on, even though it is wrong according to the current standard.  If it
> ever goes to a platform where streambuf::int_type is not 'int' it will
> fail, quite possibly without any compiler warnings.  I suppose the LWG
> was "obviously irresponsible" to make the change (or perhaps the
> vendors were irresponsible to follow the LWG ...).

Nope. The C++ Standard Library never had overflow(int).

>
> The developer could have attempted to protect against the change with
> something similar to
>
>   int (streambuf::*compile_time_override_check)(int) =
>     &streambuf::overflow;
>
> but, in the real world, it didn't happen.  This test also would not
> have caught a change from virtual to non-virtual, at a time when the
> state of streambuf was very much in flux.  IMO it would be better to
> replace the override comment and override test with an override
> keyword.
>

Indeed: a magic keyword would be more effective than this test. But that
doesn't mean it's the best approach. The way to test that your override
gets called is to call it. If it's too hard to isolate a call like that
in your application, write a separate class for a separate test case.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marc Schoolderman wrote:
> Daniel Kr=FCgler wrote:
>=20
>> - Checking (or implying, but that is just a minor point) whether the
>>   currently declared function is virtual.
>> - Checking that there exists an override-matching function in at least
>> one of its base classes.
>=20
>=20
> It's goal is as well to ensure that a function declaration is what the=20
> designer of that class meant it to be. I.e., that a new version of a=20
> 'base class' that adds more virtual signatures doesn't accidentally=20
> break or alter the meaning of 'downstream' classes.
>=20
> To achieve this safety, any function declaration without 'override'=20
> should merely hide 'upstream' signatures. This is exactly how it is in=20
> Delphi and C#. This would break nearly all C++ programs in existence, s=
o=20
> I don't think this has any realistic chance of being adopted.

This is one possible further step, but I did not propose that. My
comparison with Delphi was not done with the aim for an exact imitation
of its complete keyword combinations concerning virtual functions.

To my opinion a single contextual keyword like 'override' with the above
described behaviour could protect for one of the most prominent errors:
Changeing the signature of a virtual function in the middle of the
development of the class hierarchy.

Greetings from Bremen,

Daniel Kr=FCgler

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:

> That is a significant factor, but certainly not the main reason for
> objecting to language hacks that add clutter in order to work around
> defective development processes.

Essentially all development processes are defective.  Humans make
mistakes.  A very common mistake for some of us is a typo.  Those of us
who make typos use "language hacks" like Fortran IMPLICIT NONE, C
prototypes, and symbolic constants so that we can catch the mistakes
earlier (in the editor or in the compiler), rather than later.

It became much less expensive for me to catch a typo in the compiler,
rather than at a later stage, about the same time that I started
running the compiler from a teletype, rather than from a deck of cards.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

wade@stoner.com wrote:
> Pete Becker wrote:
>
>
>>That is a significant factor, but certainly not the main reason for
>>objecting to language hacks that add clutter in order to work around
>>defective development processes.
>
>
> Essentially all development processes are defective.  Humans make
> mistakes.  A very common mistake for some of us is a typo.  Those of us
> who make typos use "language hacks" like Fortran IMPLICIT NONE, C
> prototypes, and symbolic constants so that we can catch the mistakes
> earlier (in the editor or in the compiler), rather than later.

I see. All errors caused by typos are equally important, and there are
no reaonable techniques for detecting any of them without explicit
language support.

Seriously, this is engineering. Before making significant language
changes whose sole purpose is to make it easier to detect a particular
type of error you need to:

 1. clearly describe the error
 2. analyze how common it is
 3. analyze how it can be detected without a language change, and
 4. demonstrate that none of the available solutions is adequate

>
> It became much less expensive for me to catch a typo in the compiler,
> rather than at a later stage, about the same time that I started
> running the compiler from a teletype, rather than from a deck of cards.
>

For some typos this is true. For others it is not. In particular, if
you're writing reasonable unit tests you'll find failures to override
virtual functions without having to test for them explicitly. That's
about as cheap as it gets.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Victor Bazarov wrote:
> Zara wrote:
> > I don't think it is needed.
> > A simple assertion may be used to locate the problem at compile-time:
> >
> > class Derived: public Base {
> > /*override*/ int whatever(int thing)
> > {
> > while (0) {Base::whatever(thing);} // fails if Base class whatever
> > signature changes
>
> If 'int' changes to, say, 'double', it doesn't fail.
> This should take care of that:
>
>     int (Base::*p)(int) = &Base::whatever;
>

However neither catch the case where the base class method is (no
longer)virtual - admittedly a less common problem but can occur when
refactoring simple virtual functions to use the public
non-virtual/private virtual pattern.

Regards,
Roger Orr
--
MVP in C++ at www.brianbench.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

My whole point is that we can use the language to help us, when the
cost of the help is minimal - the compiler already knows whether the
method is an override or not. I am just trying to tell the compiler
what I intended, so that it can tell me when I am wrong.

I am not advocating requiring the keyword - that would be a dreadful
burden on existing code, I am asking to be able to supply it where I
want to, and allow others to completely ignore it.

Otherwise finding all the places where a change to a virtual affects
the derived classes can be a problem. For example, I work on a project
that has been actively developed for over a decade, such that the tag
list for GetID returns 111 matches (and I just opened my editor and
looked around in the file that I was editing and picked something
hideous looking).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello Bruce Mellows,

Bruce Mellows wrote:
> My whole point is that we can use the language to help us, when the
> cost of the help is minimal - the compiler already knows whether the
> method is an override or not. I am just trying to tell the compiler
> what I intended, so that it can tell me when I am wrong.
>=20
> I am not advocating requiring the keyword - that would be a dreadful
> burden on existing code, I am asking to be able to supply it where I
> want to, and allow others to completely ignore it.
>=20
> Otherwise finding all the places where a change to a virtual affects
> the derived classes can be a problem. For example, I work on a project
> that has been actively developed for over a decade, such that the tag
> list for GetID returns 111 matches (and I just opened my editor and
> looked around in the file that I was editing and picked something
> hideous looking).

I understand your claims and I strongly support your proposal.
A keyword support for "override", which is well known from other=20
languages like Object Pascal, is one further security barrier, because=20
it fulfills two jobs:

- Checking (or implying, but that is just a minor point) whether the
   currently declared function is virtual.
- Checking that there exists an override-matching function in at least
one of its base classes.

Introducing this keyword would be harmless, iff C++ would have the=20
concept of contextual keywords. I assume, the main raison for resistance
against your and many other similar proposals is, that by introducing
a new C++ keyword, you can probably guarantee, that this will
break at least one single written code, because someone could have used
"override" as usual name.

My strongest and first plea would be the extensibility of C++ with
contextual keywords. Is anyone aware of steps in these directions in C++
(not CLI but standard C++)?

Greetings from Bremen,

Daniel Kr=FCgler

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

There has been a proposal for this, that avoids introducing a new
keyword:

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1494.pdf>

/Henrik

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Kr   gler wrote:

> - Checking (or implying, but that is just a minor point) whether the
>   currently declared function is virtual.
> - Checking that there exists an override-matching function in at least
> one of its base classes.

It's goal is as well to ensure that a function declaration is what the
designer of that class meant it to be. I.e., that a new version of a
'base class' that adds more virtual signatures doesn't accidentally
break or alter the meaning of 'downstream' classes.

To achieve this safety, any function declaration without 'override'
should merely hide 'upstream' signatures. This is exactly how it is in
Delphi and C#. This would break nearly all C++ programs in existence, so
I don't think this has any realistic chance of being adopted.

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bruce Mellows wrote:

>
> Otherwise finding all the places where a change to a virtual affects
> the derived classes can be a problem.

Changing a base class function from virtual to non-virtual affects all
derived classes. If the writer of a library that I used did that I'd
replace the library immediately, since the developer is obviously
irresponsible.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Kr   gler wrote:
>
> I assume, the main raison for resistance
> against your and many other similar proposals is, that by introducing
> a new C++ keyword, you can probably guarantee, that this will
> break at least one single written code, because someone could have used
> "override" as usual name.
>

That is a significant factor, but certainly not the main reason for
objecting to language hacks that add clutter in order to work around
defective development processes.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

* Henrik Grimm:
> There has been a proposal for this, that avoids introducing a new
> keyword:
>
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1494.pdf>

That's an ingenious proposal.

Summary below, but first, while I think the proposal is great the reason
given, namely the fragile base class problem, is not convincing to me -- and
this thread has shown that it isn't very convincing to others, either.

What I see as the main reason for an 'override' or 'implementation' keyword
equivalent is that one can tell the compiler that this is indeed meant to be
an override of a declaration in a base class, so that the compiler can do
the checking:

1 If this isn't an override as intended (e.g., slightly wrong signature, or
no such declaration in a base class at all) we're guaranteed a compile time
error instead of a round of run-time testing, debugging and bug-hunting.

2 If this is an unintended override the compiler can warn us (without the
history of C++, in a language designed from scratch, it could give an error
message).  E.g., there could be virtual function with the same signature in
some class inherited privately by a base class.  But of course, to gain this
benefit one would need some disipline, writing warning-free code, which at
least one participant of this thread has argued repeatedly against.  I think
because it means more up-front work and because code can never, in practice,
be guaranteed warning-free for some other compiler or new compiler version.
More about that below.

3 When reading someone's warning-free code it's easy to see whether a member
function is an override or not.

Summarizing the n1494 proposal:

  virtual ... = 0;   // pure declaration
  virtual ... > 0;   // pure implementation, 'override'/'implementation'
  virtual ... >= 0;  // as "=" but requires a declaration in base class

I'm not sure whether the proposed ">=" semantics could be useful, but ">"
certainly would be.

I think with regard to (2) a #pragma that turns the (possible) warnings into
(mandated) errors could be a good solution.  That way one wouldn't have to
write warning-free code to gain the benefits.  And one could turn this
feature on for new code, while leaving the old behavior for old code.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bruce Mellows wrote:

[...]

> If one were to supply and 'override' keyword, then the compiler can know
> that the method was intended to override a virtual but does not, and can
> take some suitable action.

IMHO, this is just one of the problems that can occur when using virtual
functions.  Another subtle bug is not overriding all overloads.

#include <cassert>

class A
{
public:
   virtual void foo ()       = 0;
   virtual void foo () const = 0;
};

class B : public A
{
public:
public:
   virtual void foo ()       { assert (false); }
   virtual void foo () const { /* ... */ }
};

class C : public B
{
public:
   virtual void foo () const
   {
   }
};


A test case is the only way to ensure that non-const foo is not
overridden in the most derived class, and testing for that situation
will also catch the issue of virtual functions not overridding a
function in the base class.

Another post mentioned how a check on converting from &C::foo to 'void
(A::*)()' would not catch virtual functions in a derived class hiding a
non virtual function in the base, again a test will catch this.

I suppose I'm trying to say that the compiler cannot catch all the cases
I see as being problematic with virtual functions, and so I'll have to
write the test cases to catch these examples anyway, with or without a
new keyword/construct.


Regards,

Richard



>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>


--
Richard Corden

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

The method of overriding a virtual method that exists, namely, declaring
a method with the same signature leads to problems when some change to
the signature of the method that 'introduces' the virtual occurs.

Specifically, the 'overrides' are no longer overrides, and there is no
indication of any problem, either for the compiler or the user.

If one were to supply and 'override' keyword, then the compiler can know
that the method was intended to override a virtual but does not, and can
take some suitable action.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I don't think it is needed.
A simple assertion may be used to locate the problem at compile-time:

class Derived: public Base {
/*override*/ int whatever(int thing)
{
while (0) {Base::whatever(thing);} // fails if Base class whatever
signature changes

// .. the rest
}

Of course, thiss is not perfect and needs some polishing, but it
demonstrates that C++ is already able to do the job.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bruce Mellows wrote:
> The method of overriding a virtual method that exists, namely, declaring
> a method with the same signature leads to problems when some change to
> the signature of the method that 'introduces' the virtual occurs.
>
> Specifically, the 'overrides' are no longer overrides, and there is no
> indication of any problem, either for the compiler or the user.

Actually, there is no required indication (since such code is not
ill-formed), but many compilers I know issue a warning.

> If one were to supply and 'override' keyword, then the compiler can know
> that the method was intended to override a virtual but does not, and can
> take some suitable action.

There are probably numerous other situations in which changing the
interface of a class may [silently] change the behaviour of the program,
why should overriding virtual functions be different?

V

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Zara wrote:
> I don't think it is needed.
> A simple assertion may be used to locate the problem at compile-time:
>
> class Derived: public Base {
> /*override*/ int whatever(int thing)
> {
> while (0) {Base::whatever(thing);} // fails if Base class whatever
> signature changes

If 'int' changes to, say, 'double', it doesn't fail.
This should take care of that:

    int (Base::*p)(int) = &Base::whatever;

It wastes sizeof(p) on the automatic storage, though.

> // .. the rest
> }
>
> Of course, thiss is not perfect and needs some polishing, but it
> demonstrates that C++ is already able to do the job.

I don't think it's the point.  The programmer should do the job, not
the language, that's the point.

V

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]