Peter Dimov wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message news:<3C11055C.899A4886@acm.org>...
> > Peter Dimov wrote:
> > >
> > > What are the alternatives - in this particular case? Ignore the
> > > problem and see what tests break?
> >
> > Yes. That's what tests are for.
>
> But, as I said in the previous post, I _know_ what tests will break
> (or at least I know what tests ought to break. Tests sometimes have
> bugs as well.) There is no need to wait and see. What I need is not
> information on what will break, but information on which source lines
> have to be fixed. Preferably in double-clickable form.
>
> "Test and see what breaks" is not that different from "Compile and see
> what breaks" except that the latter reports errors earlier and
> pinpoints their location with greater accuracy. At least in this
> particular case.
>

The difference is in attitude. Compiler-produced errors are generally
regarded as part of the development process, with no negative
implications about the author (unless you accept Tom DeMarco's
suggestion that developers shouldn't be allowed to use compilers, and if
their "finished" code doesn't compile it gets logged as a bug), while
test failures are tracked as bugs.

Making it easy to detect some portion of a class of errors at
compile-time encourages sloppiness: hack the code until it compiles,
then declare it finished. What's needed is the discipline to trace the
implications of the change through all of the code, not just to the
places where the compiler detects a problem.

--
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.research.att.com/~austern/csc/faq.html                ]

Peter Dimov wrote:
>
> > Probably not. It doesn't add anything significant.
>
> I don't believe you. ;-) You're a professional. There is no reason to
> deliberately avoid a (useful) tool that is part of the language.
>

I will take no further part in this discussion.

--
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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
...
> Making it easy to detect some portion of a class of errors at
> compile-time encourages sloppiness: hack the code until it compiles,
> then declare it finished. What's needed is the discipline to trace the

Of course that's the wrong procedure. The proper procedure is "Hack the
code until it compiles, then start really testing it." Making it easy to
detect some portion of a class of errors at compile time serves to make
the first part of that process more effective. It doesn't eliminate the
need for the second part. It doesn't have to eliminate that need, in
order to be worthwhile.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Sat,  8 Dec 2001 21:20:25 GMT, Pete Becker <petebecker@acm.org> pisze:

> Making it easy to detect some portion of a class of errors at
> compile-time encourages sloppiness: hack the code until it compiles,
> then declare it finished. What's needed is the discipline to trace the
> implications of the change through all of the code, not just to the
> places where the compiler detects a problem.

This reasoning can be applied to any mandated diagnostic and that's
why I don't believe it. What you are saying implies that it would be
better to require any text to be accepted as a valid program, with
possible erroneous behavior which would be catched by tests instead
of the compiler.

I strongly disagree. If it's possible to detect the most probable
place of a given error at compile time, it should be detected.
Programmers won't automatically become better if they have fewer
tools to use, they won't be more productive if writing tests takes
five times as long as writing code. Compilers can detect many errors
a lot cheaper than tests, more reliably, with better diagnosis about
the source of the error.

Valid arguments against adding a mechanism which detects more errors
at compile time are making the language more complex (i.e. more
learning, more verbose code, harder to write compilers). The fact
that errors are now detectable by the compiler makes no sense for me
as an argument against.

How would you judge Boost's concept checking mechanisms? They reject
code which would possibly work, but which is against the rules.

The way you advocate encourages sloppiness: hack the code until current
tests pass, no matter if the code makes sense or will be correct if
something changes. You would change a badly behaving code where the
misbehavior is catched, which is not necessarily the same place where
the error is. A compiler can detect some errors without running the
code in question: it will predict that something is wrong before you
discover a contradiction in its consequences.

If you could test everything and thus if you knew the behavior for
all inputs, you wouldn't have to write the program in the first place.
Testing is no substitute for sane design (I mean design in the small
scale).

--
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
>
> Jim Barry wrote:
> >
> > Pete Becker wrote:
> > > How often have you had a problem because you changed a
> > > virtual function to non-virtual?
> >
> > Sorry, when you first asked this I thought it was a rhetorical question.
> > The answer is that I have no idea, as I haven't been keeping count. But
> > I do sometimes find it necessary to modify a virtual function
> > declaration in order to improve a design, either during the initial
> > development phase or during maintenance. When that happens, it would be
> > rather helpful if the compiler could alert me to any overriders that
> > have been overlooked.
>
> Do you want 'override' to be mandatory? If it isn't, you can't rely on
> it.

Backward compatibility is too important to allow that option. The
presence of 'override' makes it an error for the definition to not be an
'override'. The absense of 'override' leaves things the way they
currently are. Just because it doesn't do 100% of the desired job is no
reason not to let it do the portion it can do.

> Ultimately, 'override' is neither necessary nor sufficient to protect
> programmers from changes in base classes. Tools that only do half the
> job are worse than no tools, because they give misleading information.

I've never seen any tool that did more than half of any major job. It
takes at least a few dozen different tools to do 100% of any signficant
job, and some jobs simply can't be done completely for any reasonable
cost - just try to remove 100% of the dirt from a house, or 100% of the
defects from a large software project. The expensive part is that last
0.01% - it can cost infinitly more to remove than all of the first
99.99%.

Are you the kind of person who would refuse to wear a bicycle helmet,
just because it would be woefully inadequate if you were to collide
head-on with a truck?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
> Do you want 'override' to be mandatory?

Ideally, yes, of course. But I realize that it would have to be optional
in order to retain backward compatibility. So it is a shame that
'override' was not there from the start. All the same, I think it would
still be very useful for new and overhauled code.

> No, it's precisely the issue that this suggestion raises.

I meant that you don't seem at all keen on anything that might help
beginners.

- Jim

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Peter Dimov wrote:
>
> The question is not how many times has this happened to me, though.
> The real question is, how much time have I lost checking signatures. I
> don't consider this productive, so I _think_ that 'override' passes my
> cost/benefit test. Of course this is a sample of one.

Virtual funcitons are only one of several places where signatures need
to be checked if you don't have effective change control.

--
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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> wrote in message news:<3C0D4878.A86E882E@acm.org>...
> Lo? Joly wrote:
> >
> > Pete Becker wrote:
> > >
> > > Jim Barry wrote:
> > > >
> > > > I don't agree that this is an issue that only affects novices.
> > >
> > > How often have you had a problem because you changed a virtual functi
>  on
> > > to non-virtual?
> >
> > I am not sure you read my latest answear, so I repeat it : The proble i
>  s
> >  NOT  changing a function from non virtual to virtual. The problem is
> > making a modification to one parameter of the base virtual function, an
>  d
> > not applying the same modification to the derived function.
> >
>
> Fine. How often have you had a problem because you made a modification
> to one parameter of the base virtual function, and didn't apply the same
> modification to the derived function?

After changing a base virtual function signature, the typical
procedure is to locate all overriders - by hand - and fix them. Rarely
does a programmer wait for the tests to fail. They will. No new
information would be gained.

With consistent use of 'override', the process is automated.

There are ways in current C++ to achieve the same level of error
checking (never override a non-pure virtual) but unfortunately they
can't be applied universally.

> Of course, the same sort of
> problem can arise with overloading -- if you modify one parameter you
> can change which version gets called by other code. Do you also have a
> proposal for fixing that?

A solution for this problem would likely have a different cost/benefit
ratio.

--
Peter Dimov
Multi Media Ltd.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Peter Dimov wrote:
>
> No, I don't agree. Calling the wrong virtual function is sometimes not
> immediately obvious, even with a reasonable test set. An example would
> be a virtual function that is supposed to handle WM_POWERBROADCAST or
> whatever the name of that message is.

If it doesn't at least call this function it's by definition not a
"reasonable test set."

>
> > Once again: how many times has this happened to you?
>
> Never, IIRC. Every good C++ programmer (hopefully) knows how to avoid
> the well known deficiencies of the language.
>
> The question is not how many times has this happened to me, though.
> The real question is, how much time have I lost checking signatures. I
> don't consider this productive, so I _think_ that 'override' passes my
> cost/benefit test. Of course this is a sample of one.
>

Since you've never had a problem because of this, why are you spending
expensive programmer time checking for it? And since you agreed earlier
that "Programmers that use unit tests (group #1) don't need override.",
why are you spending expensive programmer time checking for it?

--
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.research.att.com/~austern/csc/faq.html                ]

Peter Dimov wrote:
>
> After changing a base virtual function signature, the typical
> procedure is to locate all overriders - by hand - and fix them. Rarely
> does a programmer wait for the tests to fail. They will. No new
> information would be gained.
>
> With consistent use of 'override', the process is automated.
>

No, it turns into compile-and-see-what-breaks, which is rarely a good
approach to software engineering.

--
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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
> How often have you had a problem because you changed a
> virtual function to non-virtual?

Sorry, when you first asked this I thought it was a rhetorical question.
The answer is that I have no idea, as I haven't been keeping count. But
I do sometimes find it necessary to modify a virtual function
declaration in order to improve a design, either during the initial
development phase or during maintenance. When that happens, it would be
rather helpful if the compiler could alert me to any overriders that
have been overlooked.

> How far should the language go, adding keywords (and,
> therefore, complexity) in order to protect beginners?

Now that really does sound like a rhetorical question.

- Jim

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
>
> Peter Dimov wrote:
> >
> > After changing a base virtual function signature, the typical
> > procedure is to locate all overriders - by hand - and fix them. Rarely
> > does a programmer wait for the tests to fail. They will. No new
> > information would be gained.
> >
> > With consistent use of 'override', the process is automated.
> >
>
> No, it turns into compile-and-see-what-breaks, which is rarely a good
> approach to software engineering.

I'm sorry, but I have to disagree. Compile-and-see-what-breaks is one of
the many important tools that belongs in every programmer's tool chest.
If you're not using it on a regular basis, you're wasting expensive
human time checking things that compilers can check faster, cheaper, and
more reliably. Only an idiot would expect it to solve every problem, but
it's a different kind of idiocy to waste time doing things computers do
better than humans.

I think you're missing out on one of the most basic problems 'override'
helps with: spelling errors. Without 'override', a misspelled overrider
is a perfectly legal definition of a completely different member
function. If you are consistently misreading it as having been correctly
spelled (a mistake that's easy for human beings to make), it can be very
difficult to detect the problem through testing, or debugging.
Compilers, on the other hand, excel at detecting that kind of error.
Maybe you spell perfectly, but I don't, and neither do most of the other
programmers I've ever worked with.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

petebecker@acm.org (Pete Becker) wrote (abridged):
> Once again: how often has this happened to you?

It happened to me today. A coincidence.

It was indeed caught by my testing. However it then took a couple more
edit-compile-execute cycles to identify the problem. (It's a big program
and take a while to compile.)


> It's certainly not something I spend any time worrying about.

Ah, there we differ. I worry about it, and spend time specifically
checking for it while reading and debugging, even when this particular
problem has not occurred. It is an ever-present danger.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Jim Barry wrote:
>
> Pete Becker wrote:
> > How often have you had a problem because you changed a
> > virtual function to non-virtual?
>
> Sorry, when you first asked this I thought it was a rhetorical question.
> The answer is that I have no idea, as I haven't been keeping count. But
> I do sometimes find it necessary to modify a virtual function
> declaration in order to improve a design, either during the initial
> development phase or during maintenance. When that happens, it would be
> rather helpful if the compiler could alert me to any overriders that
> have been overlooked.

Do you want 'override' to be mandatory? If it isn't, you can't rely on
it.

"Rather helpful" isn't the same as "should be part of the language."
When someone changes something about a class, whether it's the interface
or the implementation, evaluating consequential changes to other classes
requires thought. Mechanical techniques that detect some places where
analysis is needed but doesn't detect others isn't particularly helpful,
since you have to do the full analysis regardless of what your tools
tell you.

Ultimately, 'override' is neither necessary nor sufficient to protect
programmers from changes in base classes. Tools that only do half the
job are worse than no tools, because they give misleading information.

>
> > How far should the language go, adding keywords (and,
> > therefore, complexity) in order to protect beginners?
>
> Now that really does sound like a rhetorical question.
>

No, it's precisely the issue that this suggestion raises.

--
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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> wrote in message news:<3C0FD9D7.8F1845C4@acm.org>...
> Peter Dimov wrote:
> >
> > After changing a base virtual function signature, the typical
> > procedure is to locate all overriders - by hand - and fix them. Rarely
> > does a programmer wait for the tests to fail. They will. No new
> > information would be gained.
> >
> > With consistent use of 'override', the process is automated.
> >
>
> No, it turns into compile-and-see-what-breaks, which is rarely a good
> approach to software engineering.

What are the alternatives - in this particular case? Ignore the
problem and see what tests break? Use a separate tool to locate the
overriders? The compiler _is_ that tool (with override.)

--
Peter Dimov
Multi Media Ltd.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> wrote in message news:<3C0F84A6.8FBD9D12@acm.org>...
> Peter Dimov wrote:
> >
> > No, I don't agree. Calling the wrong virtual function is sometimes not
> > immediately obvious, even with a reasonable test set. An example would
> > be a virtual function that is supposed to handle WM_POWERBROADCAST or
> > whatever the name of that message is.
>
> If it doesn't at least call this function it's by definition not a
> "reasonable test set."

OK, I can agree with this. It follows that a reasonable test set is
difficult to get right.

> > > Once again: how many times has this happened to you?
> >
> > Never, IIRC. Every good C++ programmer (hopefully) knows how to avoid
> > the well known deficiencies of the language.
> >
> > The question is not how many times has this happened to me, though.
> > The real question is, how much time have I lost checking signatures. I
> > don't consider this productive, so I _think_ that 'override' passes my
> > cost/benefit test. Of course this is a sample of one.
> >
>
> Since you've never had a problem because of this, why are you spending
> expensive programmer time checking for it?

It's the other way around. I've never had this kind of problem
_because_ I spend expensive programmer time checking for it. A time I
prefer to spend on other, more productive, things.

> And since you agreed earlier
> that "Programmers that use unit tests (group #1) don't need override.",
> why are you spending expensive programmer time checking for it?

Because "need" and "would benefit from" aren't necessarily the same
thing. Let's assume for a moment that C++ does have 'override.' Would
you not use it?

--
Peter Dimov
Multi Media Ltd.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Jim Barry" <jim.barry@bigfoot.com> writes:

> Pete Becker wrote:
> > How far should the language go, adding keywords (and,
> > therefore, complexity) in order to protect beginners?
>
> Now that really does sound like a rhetorical question.

Pete may or may not have intended this as a rhetorical question (I'll
let him speak for himself), but, in my opinion, his question is a very
important one that we ought to be asking as we begin to consider the
next version of C++.

I believe that C++0x ought to do more to protect beginners than C++98
does.  Naturally that isn't the only design goal for C++0x, and
naturally there may be some tension between that goal and other design
goals.  (Don't pay for what you don't use, C compatibility,
simplicity, expressive power, and so on.)  But I believe we ought to
seriously think about protecting beginners where possible.  Education
is important.

We ought to be thinking about how far we think we should go to protect
beginners (and nonbeginners who make stupid mistakes, for that
matter).


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Valentin Bonnard wrote:
> So you are for the stato-quo, because it's the statu-quo, and
> against changes, because they are changes.

I think Status Quo are great - they haven't changed a bit!

- Jim


---
[ 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.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3C102097.B3C1FEA8@wizard.net...
> Pete Becker wrote:
> >
> > Peter Dimov wrote:
> > >
> > > After changing a base virtual function signature, the typical
> > > procedure is to locate all overriders - by hand - and fix them. Rarely
> > > does a programmer wait for the tests to fail. They will. No new
> > > information would be gained.
> > >
> > > With consistent use of 'override', the process is automated.
> > >
> >
> > No, it turns into compile-and-see-what-breaks, which is rarely a good
> > approach to software engineering.
>
> I'm sorry, but I have to disagree. Compile-and-see-what-breaks is one of
> the many important tools that belongs in every programmer's tool chest.
> If you're not using it on a regular basis, you're wasting expensive
> human time checking things that compilers can check faster, cheaper, and
> more reliably. Only an idiot would expect it to solve every problem, but
> it's a different kind of idiocy to waste time doing things computers do
> better than humans.
>
> I think you're missing out on one of the most basic problems 'override'
> helps with: spelling errors. Without 'override', a misspelled overrider
> is a perfectly legal definition of a completely different member
> function. If you are consistently misreading it as having been correctly
> spelled (a mistake that's easy for human beings to make), it can be very
> difficult to detect the problem through testing, or debugging.
> Compilers, on the other hand, excel at detecting that kind of error.
> Maybe you spell perfectly, but I don't, and neither do most of the other
> programmers I've ever worked with.

I must agree with this.  Let me add another example where if I had
'override' at my disposal, I would have saved hours.

I wrote a project where I overrode a function in a derived class that I had
defined in the base.  It was a fairly simple override, but for some reason
my test code wasn't calling the derived version of the function.  I tried
checking slicing issues.  I tried checking alignment issues.  I tried
checking pointer corruption issues.  I checked spelling issues repeatedly,
until I finally discovered that I wasn't overriding a method at all, but
defining a new method with the exact same signature, but different
_constness_.  (Yes, I know this means the signature wasn't "exactly the
same," but it was supposed to be, and it looked to my human eyes like it
was.)

I know, I know, I should know better than to let const incorrectness slip
into my program, but it did.  And if I had had 'override', I would have
gotten a diagnostic, showing the offending signature and possible
candidate(s) out of the gate, or at least a line number telling me where the
compiler thought the problem was, and why.

Yes, my unit was failing its unit tests, so I knew something was wrong, but
I couldn't pinpoint _what_, and I feel that anything that can be reasonably
done to pinpoint _what_ the problem is (more than _that_ the problem is)
would not go amiss.




---
[ 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.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." wrote:
>
> Pete Becker wrote:
> >
> > Peter Dimov wrote:
> > >
> > > After changing a base virtual function signature, the typical
> > > procedure is to locate all overriders - by hand - and fix them. Rarely
> > > does a programmer wait for the tests to fail. They will. No new
> > > information would be gained.
> > >
> > > With consistent use of 'override', the process is automated.
> > >
> >
> > No, it turns into compile-and-see-what-breaks, which is rarely a good
> > approach to software engineering.
>
> I'm sorry, but I have to disagree. Compile-and-see-what-breaks is one of
> the many important tools that belongs in every programmer's tool chest.

No. When programmers resort to this it's because they're tired of
thinking.

> I think you're missing out on one of the most basic problems 'override'
> helps with: spelling errors. Without 'override', a misspelled overrider
> is a perfectly legal definition of a completely different member
> function. If you are consistently misreading it as having been correctly
> spelled (a mistake that's easy for human beings to make), it can be very
> difficult to detect the problem through testing, or debugging.

Huh? If you haven't overridden a base-class virtual function, then your
test code that exercises the derived-class overrider will fail. That's
not at all hard: it just works.

> Compilers, on the other hand, excel at detecting that kind of error.
> Maybe you spell perfectly, but I don't, and neither do most of the other
> programmers I've ever worked with.

There are lots of places where this could happen. Changing the language
to attack one that's easy to test for isn't particularly useful.

--
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.research.att.com/~austern/csc/faq.html                ]

Peter Dimov wrote:
>
> What are the alternatives - in this particular case? Ignore the
> problem and see what tests break?

Yes. That's what tests are for.

--
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.research.att.com/~austern/csc/faq.html                ]

Peter Dimov wrote:
>
> OK, I can agree with this. It follows that a reasonable test set is
> difficult to get right.

Yes, which is why testing should be left to professionals, not to
moonlighting developers. But that's a separate discussion.

>
> > > > Once again: how many times has this happened to you?
> > >
> > > Never, IIRC. Every good C++ programmer (hopefully) knows how to avoid
> > > the well known deficiencies of the language.
> > >
> > > The question is not how many times has this happened to me, though.
> > > The real question is, how much time have I lost checking signatures. I
> > > don't consider this productive, so I _think_ that 'override' passes my
> > > cost/benefit test. Of course this is a sample of one.
> > >
> >
> > Since you've never had a problem because of this, why are you spending
> > expensive programmer time checking for it?
>
> It's the other way around. I've never had this kind of problem
> _because_ I spend expensive programmer time checking for it. A time I
> prefer to spend on other, more productive, things.

I must have overlooked the place where you said that you had actually
found such problems often enough to justify looking for them. <g>

>
> > And since you agreed earlier
> > that "Programmers that use unit tests (group #1) don't need override.",
> > why are you spending expensive programmer time checking for it?
>
> Because "need" and "would benefit from" aren't necessarily the same
> thing. Let's assume for a moment that C++ does have 'override.' Would
> you not use it?

Probably not. It doesn't add anything significant. More important, I
wouldn't recommend it to inexperienced programmers because it would be
too hard to explain why some signatures can be checked and some can't,
and that signature checking (either in the form of code reviews or in
the form of tests) must be done even if you use override.

--
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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
>
> "James Kuyper Jr." wrote:
> >
> > Pete Becker wrote:
> > >
> > > Peter Dimov wrote:
> > > >
> > > > After changing a base virtual function signature, the typical
> > > > procedure is to locate all overriders - by hand - and fix them. Rarely
> > > > does a programmer wait for the tests to fail. They will. No new
> > > > information would be gained.
> > > >
> > > > With consistent use of 'override', the process is automated.
> > > >
> > >
> > > No, it turns into compile-and-see-what-breaks, which is rarely a good
> > > approach to software engineering.
> >
> > I'm sorry, but I have to disagree. Compile-and-see-what-breaks is one of
> > the many important tools that belongs in every programmer's tool chest.
>
> No. When programmers resort to this it's because they're tired of
> thinking.

I think all day long. It's what I get paid for. Getting tired of
thinking is a normal everyday event. No - make that "hourly", not
"everyday". I prefer to let the compiler spend it's exceedingly cheap
time thinking about the things that it's much better equipped to think
about than I am. I prefer to concentrate my own limited and expensive
supply of time thinking about issues that I'm much better equipped to
handle than the compiler is.

> > I think you're missing out on one of the most basic problems 'override'
> > helps with: spelling errors. Without 'override', a misspelled overrider
> > is a perfectly legal definition of a completely different member
> > function. If you are consistently misreading it as having been correctly
> > spelled (a mistake that's easy for human beings to make), it can be very
> > difficult to detect the problem through testing, or debugging.
>
> Huh? If you haven't overridden a base-class virtual function, then your
> test code that exercises the derived-class overrider will fail. That's
> not at all hard: it just works.

All that unit test will tell me is that there's a problem. If I don't
notice the misspelling, that test WON'T tell me where the problem is.
This is perfectly normal, at least for those of us capable of making
spelling errors. If a person commits a particular misspelling, that
person is also likely to not notice that misspelling when reading it.
With an 'override' keyword, any decent compiler would give me a message
that points me far more precisely at the actual source of the problem.
It will do so as soon as I compile the code, without even waiting for
the unit test.

> > Compilers, on the other hand, excel at detecting that kind of error.
> > Maybe you spell perfectly, but I don't, and neither do most of the other
> > programmers I've ever worked with.
>
> There are lots of places where this could happen. Changing the language
> to attack one that's easy to test for isn't particularly useful.

Nor is it useless. As as judgment call, I think it's usefulness is large
enough to justify the change, but I don't expect agreement on judgment
calls.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> wrote in message news:<3C110711.140411EB@acm.org>...
> Peter Dimov wrote:
> >
> > OK, I can agree with this. It follows that a reasonable test set is
> > difficult to get right.
>
> Yes, which is why testing should be left to professionals, not to
> moonlighting developers. But that's a separate discussion.

For the purposes of this discussion, let's label the moonlighting
developers "group #2". ;-)

> > It's the other way around. I've never had this kind of problem
> > _because_ I spend expensive programmer time checking for it. A time I
> > prefer to spend on other, more productive, things.
>
> I must have overlooked the place where you said that you had actually
> found such problems often enough to justify looking for them. <g>

Yep. Memory is a funny thing. I don't recall having this kind of
problem but I must have had it, or observed someone else having it, or
simply thought about it and its potential costs.

Actually now that I think about it, I _have_ had this problem. Except
that the base virtual was pure, so the compiler caught it immediately.
I don't know whether this qualifies.

> > Because "need" and "would benefit from" aren't necessarily the same
> > thing. Let's assume for a moment that C++ does have 'override.' Would
> > you not use it?
>
> Probably not. It doesn't add anything significant.

I don't believe you. ;-) You're a professional. There is no reason to
deliberately avoid a (useful) tool that is part of the language.

The funny thing about 'override' is that, IMO, it doesn't have any
significant drawbacks. It's intuitive, clear, can be easily explained
to novices, doesn't add any substantial complexity, cannot be misused.
Even the universal counterargument doesn't quite apply to it.

> More important, I
> wouldn't recommend it to inexperienced programmers because it would be
> too hard to explain why some signatures can be checked and some can't,
> and that signature checking (either in the form of code reviews or in
> the form of tests) must be done even if you use override.

Ah, the universal counterargument. ;-) False sense of security.

I think, however, that 'override' is so clear and problem-specific
that even novices will immediately recognize the exact form of
security that it offers.

--
Peter Dimov
Multi Media Ltd.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> wrote in message news:<3C11055C.899A4886@acm.org>...
> Peter Dimov wrote:
> >
> > What are the alternatives - in this particular case? Ignore the
> > problem and see what tests break?
>
> Yes. That's what tests are for.

But, as I said in the previous post, I _know_ what tests will break
(or at least I know what tests ought to break. Tests sometimes have
bugs as well.) There is no need to wait and see. What I need is not
information on what will break, but information on which source lines
have to be fixed. Preferably in double-clickable form.

"Test and see what breaks" is not that different from "Compile and see
what breaks" except that the latter reports errors earlier and
pinpoints their location with greater accuracy. At least in this
particular case.

--
Peter Dimov
Multi Media Ltd.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Al Grant wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3C06A0CE.E91638E8@acm.org...
> > On a construction site, if someone leaves a board with a nail sticking
> > out of it on the ground they get fired immediately.
>
> On a construction site, if someone fails to wear protective
> boots, they also get fired immediately.
>

Not steel-soled boots, which is what would be needed to protect from
this danger.

--
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.research.att.com/~austern/csc/faq.html                ]

Ken Alverson wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3C094998.F387ABB1@acm.org...
> > Peter Dimov wrote:
> > >
> > > Pete Becker <petebecker@acm.org> wrote in message
> news:<3C058126.36357A00@acm.org>...
> > >
> > > [override keyword]
> > >
> > > > The reason that it doesn't get any support from me is that it solves a
> > > > non-problem. If you want to be sure that your member function
> overrides
> > > > a virtual function in the base, write a test case that calls it
> through
> > > > the base. You have to do this anyway, in order to check the behavior
> of
> > > > your derived class. So this error falls out automatically from routine
> > > > testing.
> > >
> > > You are right. Programmers that use unit tests (group #1) don't need
> > > override.
> > >
> > > On the other hand, programmers that do not do proper testing (group
> > > #2) will benefit from it. The cost will be an extra keyword.
> > >
> > > Not giving group #2 what they want will not automatically make them
> > > migrate to #1.
> > >
> >
> > Giving group #2 what they want won't turn them into good programmers.
>
> Everyone makes mistakes and forgets to check things, even the unit test
> writing group #1 people.

Any test that reasonably exercises a derived class will detect that a
base doesn't declare an expected function to be virtual. This isn't
something you design for, and isn't something you can forget to check.
It just happens. Unless, of course, you don't write tests, in which case
'override' isn't going to save you.

> Saying that a feature that would reinforce their
> tests and catch mistakes they might miss is bad

I haven't said it was bad. I said it's unnecessary.

> simply because it shouldn't
> be necessary is like saying that airbags are bad because people should be
> wearing their seatbelts.  Sometimes the seatbelt fails, and it's nice to
> know you have redundant means of protection...even if you do wear your
> seatbelt.
>

Redundant only matters if the other protection can fail.

--
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.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." wrote:
>
> Pete Becker wrote:
> >
> > Peter Dimov wrote:
> ...
> > > On the other hand, programmers that do not do proper testing (group
> > > #2) will benefit from it. The cost will be an extra keyword.
> > >
> > > Not giving group #2 what they want will not automatically make them
> > > migrate to #1.
> > >
> >
> > Giving group #2 what they want won't turn them into good programmers.
>
> No, but it will help group #2 produce better code than they otherwise
> would have.

Maybe. On a scale of 1-10 it might move them up to 2. That's still a
long way from 10.

> It will also help group #1 catch their errors earlier than
> they would otherwise have done.
>

Once again: how often has this happened to you? It's certainly not
something I spend any time worrying about.

--
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.research.att.com/~austern/csc/faq.html                ]

Peter Dimov wrote:
>
> To give an example: making a class abstract is enough, in current C++,
> to prevent instantiation. I don't _need_ to test whether the class can
> be instantiated, copied, sliced to, because I've already taken care of
> this. This probably makes me a bad programmer by your definition

Not by my definition. Please don't attribute positions to me that I do
not hold.

--
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.research.att.com/~austern/csc/faq.html                ]

Peter Dimov wrote:
>
> Similarly, tagging the overrider with 'override' will ensure that a
> whole class of errors become the responsibility of the compiler, not
> the programmer. The keyword is, in essence, my unit test for the
> problem.

A whole class of unimportant errors which do not currently require any
specific test to detect, becuase they become immediately obvious with
any reasonable test set. So this keyword does not simplify testing, it
merely complicates the language.

Once again: how many times has this happened to you?

--
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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
>=20
> Jim Barry wrote:
> >
> > I don't agree that this is an issue that only affects novices.
>=20
> How often have you had a problem because you changed a virtual function
> to non-virtual?

I am not sure you read my latest answear, so I repeat it : The proble is
_NOT_ changing a function from non virtual to virtual. The problem is
making a modification to one parameter of the base virtual function, and
not applying the same modification to the derived function.

> > I thought we were supposed to be in an era of enlightenment
> > where it is actually considered desirable to remove pitfalls for the
> > less experienced user.
> >
>=20
> I wasn't aware that this had been declared universal policy. <g> How fa=
r
> should the language go, adding keywords (and, therefore, complexity) in
> order to protect beginners?

I think that adding keywords can have the result of decreasing
complexity, not increasing it.=20

--=20
Lo=EFc

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Lo=EFc Joly wrote:
>=20
> Pete Becker wrote:
> >
> > Jim Barry wrote:
> > >
> > > I don't agree that this is an issue that only affects novices.
> >
> > How often have you had a problem because you changed a virtual functi=
on
> > to non-virtual?
>=20
> I am not sure you read my latest answear, so I repeat it : The proble i=
s
> _NOT_ changing a function from non virtual to virtual. The problem is
> making a modification to one parameter of the base virtual function, an=
d
> not applying the same modification to the derived function.
>=20

Fine. How often have you had a problem because you made a modification
to one parameter of the base virtual function, and didn't apply the same
modification to the derived function? Of course, the same sort of
problem can arise with overloading -- if you modify one parameter you
can change which version gets called by other code. Do you also have a
proposal for fixing that?

--=20
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.research.att.com/~austern/csc/faq.html                ]

"Lo   c Joly" <loic.actarus.joly@wanadoo.fr> wrote in message

>The problem is
>making a modification to one parameter of the base virtual function, and
>not applying the same modification to the derived function.

Avoiding this problem would be useful.  As PB says, one way to detect the
problem is with better unit tests.

However, I believe the real value is in catching problems sooner.  Why
prefer
   #include "foo.h"
to
   int foo(volatile float*);
if you only want the one declaration?

The second version will catch most of the same bugs (for instance
misspellings) that the first will.  The source file containing the second
version won't need to be recompiled as often, and when it is compiled it
will probably compile faster.  However, I strongly prefer the first version.

A big difference is the cost of repairing errors (such as misspellings, or
forgetting "volatile").  If I misspell a single identifier in some work I'm
involved in right now, the error might be caught
  1) By the compiler, within minutes of my mistake, and the problem will be
fixed in several seconds.
  2) By the linker, within hours of my mistake, and the problem will be
fixed in a few minutes.
  3) By unit tests, perhaps days after my mistake, and it may take the
better part of an hour to fix the problem.
  4) By customers, months after my mistake, and the fix will cost several
hours of man time, loss of customers, and potentially more serious
consequences.

There may be other layers (code review, ...) and your unit tests may be so
good that customers never see your bugs (does anyone have the hubris to make
that claim?), and your costs are probably also different.  However, I expect
that most development processes find it beneficial to catch errors early.

Fortunately, with C++, most misspellings will be caught by the compiler, and
most of the remaining ones will be caught by the linker.  The 'override'
keyword moves a significant number of potential errors from "catch in unit
tests if you are lucky" to "catch in compiler."  To me that is a significant
benefit.

I also believe "override" is useful for making code more readable.  My
current practice is to
  1) Use 'virtual' only in the base class
  2) Use an override comment in derived classes.
It is my feeling (I don't have metrics on this) that this combination makes
the code more readable and maintainable.  An optional override keyword would
be even better.

The cost of adding an override keyword seems to be:
  1) Slightly more complexity for compilers (or any user or tool who wants
to understand C++)
  2) A noisy change to almost any program currently using "override" as a
non-macro identifier.
  3) Undefined behavior for any program using "override" as a macro name or
argument.
Item (3) can be mitigated with relatively simple tools.

IMO the benefits outweigh the costs.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> wrote in message news:<3C0D2B51.3E77E5BA@acm.org>...
> Peter Dimov wrote:
> >
> > To give an example: making a class abstract is enough, in current C++,
> > to prevent instantiation. I don't _need_ to test whether the class can
> > be instantiated, copied, sliced to, because I've already taken care of
> > this. This probably makes me a bad programmer by your definition
>
> Not by my definition. Please don't attribute positions to me that I do
> not hold.

Sorry.

Pete Becker <petebecker@acm.org> wrote in message news:<3C0D2BD7.C58D005E@acm.org>...
> Peter Dimov wrote:
> >
> > Similarly, tagging the overrider with 'override' will ensure that a
> > whole class of errors become the responsibility of the compiler, not
> > the programmer. The keyword is, in essence, my unit test for the
> > problem.
>
> A whole class of unimportant errors which do not currently require any
> specific test to detect, becuase they become immediately obvious with
> any reasonable test set. So this keyword does not simplify testing, it
> merely complicates the language.

No, I don't agree. Calling the wrong virtual function is sometimes not
immediately obvious, even with a reasonable test set. An example would
be a virtual function that is supposed to handle WM_POWERBROADCAST or
whatever the name of that message is.

> Once again: how many times has this happened to you?

Never, IIRC. Every good C++ programmer (hopefully) knows how to avoid
the well known deficiencies of the language.

The question is not how many times has this happened to me, though.
The real question is, how much time have I lost checking signatures. I
don't consider this productive, so I _think_ that 'override' passes my
cost/benefit test. Of course this is a sample of one.

--
Peter Dimov
Multi Media Ltd.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
> On a construction site, if someone leaves a board with a nail
> sticking out of it on the ground they get fired immediately.
> Nobody says "couldn't someone have followed behind him and
> picked this up?"

I don't find the analogy terribly persuasive, I'm afraid.

> There are more important things for a programming language
> to do than protect you from traps set by your own suppliers.

I was thinking of general program development and maintenance rather
than third party libraries.

> As to the cost to fix "later", there shouldn't be much
> elapsed time between changing code and running tests,
> so there's very little incremental cost in postponing this
> particular check.

Maybe, but it's undeniably preferable to get a compiler error than to
find out about it later in testing.

> Certainly beginners do it to themselves from time to time,
> and if they make this mistake they'll learn an important
> lesson. Experienced professionals don't make that sort of
> change.

I don't agree that this is an issue that only affects novices. And even
if I did, it doesn't strike me as a valid reason for rejecting the
proposal. I thought we were supposed to be in an era of enlightenment
where it is actually considered desirable to remove pitfalls for the
less experienced user.

- Jim






---
[ 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.research.att.com/~austern/csc/faq.html                ]

Peter Dimov wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message news:<3C058126.36357A00@acm.org>...
>
> [override keyword]
>
> > The reason that it doesn't get any support from me is that it solves a
> > non-problem. If you want to be sure that your member function overrides
> > a virtual function in the base, write a test case that calls it through
> > the base. You have to do this anyway, in order to check the behavior of
> > your derived class. So this error falls out automatically from routine
> > testing.
>
> You are right. Programmers that use unit tests (group #1) don't need
> override.
>
> On the other hand, programmers that do not do proper testing (group
> #2) will benefit from it. The cost will be an extra keyword.
>
> Not giving group #2 what they want will not automatically make them
> migrate to #1.
>

Giving group #2 what they want won't turn them into good 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.research.att.com/~austern/csc/faq.html                ]

Valentin Bonnard wrote:
>
> Pete Becker  wrote:
> > Gabriel Dos Reis wrote:
> >>
> >> Certainly, it is doable.  But then, the same argument applies for
> >> checking that no object of an abstract class can be created.  Are you
> >> also arguing that that feature solves a non-problem?
> >>
> >
> > No, that's not part of this discussion.
>
> So you are for the stato-quo, because it's the statu-quo, and
> against changes, because they are changes.
>

I see no basis in what I've said for this ad hominem argument. I denied
that I made an argument that I didn't make. That's all.

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


======================================= MODERATOR'S COMMENT:

Let's be careful to keep this discussion focused on the technical,
and avoid the personal.  We don't have a flame war yet, and we
should keep it that way.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Jim Barry wrote:
>
> I don't agree that this is an issue that only affects novices.

How often have you had a problem because you changed a virtual function
to non-virtual?

> And even
> if I did, it doesn't strike me as a valid reason for rejecting the
> proposal.

That's a straw man. I said that it's primarily a beginner's error, and
that it's trivial to detect. The two together make its value minimal.

> I thought we were supposed to be in an era of enlightenment
> where it is actually considered desirable to remove pitfalls for the
> less experienced user.
>

I wasn't aware that this had been declared universal policy. <g> How far
should the language go, adding keywords (and, therefore, complexity) in
order to protect beginners?

--
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.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3C06A0CE.E91638E8@acm.org...
> On a construction site, if someone leaves a board with a nail sticking
> out of it on the ground they get fired immediately.

On a construction site, if someone fails to wear protective
boots, they also get fired immediately.



---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <200111300634.HAA04435@brick.ens.fr>, Valentin Bonnard says...
>
>Pete Becker  wrote:
>> Gabriel Dos Reis wrote:
>>>
>>> Certainly, it is doable.  But then, the same argument applies for
>>> checking that no object of an abstract class can be created.  Are you
>>> also arguing that that feature solves a non-problem?
>>>
>>
>> No, that's not part of this discussion.
>
>So you are for the stato-quo, because it's the statu-quo, and
>against changes, because they are changes.
>
>  --   VB

I can't speak for Pete or Gabriel, but this quite nicely sums up _my_
baseline. You don't change standards for just any reason; the value of
a stable standard must be taken into account.

Do you teach C++? Java? I guess quite some teachers will take this
position, too.

Regards,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Jim Barry wrote:
>
> I don't agree that this is an issue that only affects novices.

To the extent that it's not, it's a process control issue, not a
language issue. If an organization's development process is so badly
controlled that it's possible to lose essential virtuality (<g>) then
there are much more serious problems to deal with. Adding a check for
virtualness is like rearranging the deck chairs on the Titanic.

--
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.research.att.com/~austern/csc/faq.html                ]

Dave Harris wrote:
>
> petebecker@acm.org (Pete Becker) wrote (abridged):
> > So this error falls out automatically from routine testing.
>
> If I preferred unit tests over compile-time error checking, I wouldn't be
> using a statically type-checked language like C++.
>
> Do you realise how much simpler C++ could be if we relegated all error
> detection to unit tests? Why should this particular problem be left to
> testing when the compiler tries so hard to find other problems?

Because it is very rare in professional code, and doesn't need explicit
testing.

--
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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
>
> Peter Dimov wrote:
...
> > On the other hand, programmers that do not do proper testing (group
> > #2) will benefit from it. The cost will be an extra keyword.
> >
> > Not giving group #2 what they want will not automatically make them
> > migrate to #1.
> >
>
> Giving group #2 what they want won't turn them into good programmers.

No, but it will help group #2 produce better code than they otherwise
would have. It will also help group #1 catch their errors earlier than
they would otherwise have done.


======================================= MODERATOR'S COMMENT:
 Standard-related content flatlining...

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3C094998.F387ABB1@acm.org...
> Peter Dimov wrote:
> >
> > Pete Becker <petebecker@acm.org> wrote in message
news:<3C058126.36357A00@acm.org>...
> >
> > [override keyword]
> >
> > > The reason that it doesn't get any support from me is that it solves a
> > > non-problem. If you want to be sure that your member function
overrides
> > > a virtual function in the base, write a test case that calls it
through
> > > the base. You have to do this anyway, in order to check the behavior
of
> > > your derived class. So this error falls out automatically from routine
> > > testing.
> >
> > You are right. Programmers that use unit tests (group #1) don't need
> > override.
> >
> > On the other hand, programmers that do not do proper testing (group
> > #2) will benefit from it. The cost will be an extra keyword.
> >
> > Not giving group #2 what they want will not automatically make them
> > migrate to #1.
> >
>
> Giving group #2 what they want won't turn them into good programmers.

Everyone makes mistakes and forgets to check things, even the unit test
writing group #1 people.  Saying that a feature that would reinforce their
tests and catch mistakes they might miss is bad simply because it shouldn't
be necessary is like saying that airbags are bad because people should be
wearing their seatbelts.  Sometimes the seatbelt fails, and it's nice to
know you have redundant means of protection...even if you do wear your
seatbelt.

Ken


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> wrote in message news:<3C094998.F387ABB1@acm.org>...
> Peter Dimov wrote:
> >
> > Pete Becker <petebecker@acm.org> wrote in message news:<3C058126.36357A00@acm.org>...
> >
> > [override keyword]
> >
> > > The reason that it doesn't get any support from me is that it solves a
> > > non-problem. If you want to be sure that your member function overrides
> > > a virtual function in the base, write a test case that calls it through
> > > the base. You have to do this anyway, in order to check the behavior of
> > > your derived class. So this error falls out automatically from routine
> > > testing.
> >
> > You are right. Programmers that use unit tests (group #1) don't need
> > override.
> >
> > On the other hand, programmers that do not do proper testing (group
> > #2) will benefit from it. The cost will be an extra keyword.
> >
> > Not giving group #2 what they want will not automatically make them
> > migrate to #1.
> >
>
> Giving group #2 what they want won't turn them into good programmers.

Of course. But the definition of a good programmer will change with
the addition of 'override.'

To give an example: making a class abstract is enough, in current C++,
to prevent instantiation. I don't _need_ to test whether the class can
be instantiated, copied, sliced to, because I've already taken care of
this. This probably makes me a bad programmer by your definition, but
I find the tradeoff acceptable.

Similarly, tagging the overrider with 'override' will ensure that a
whole class of errors become the responsibility of the compiler, not
the programmer. The keyword is, in essence, my unit test for the
problem.

This will not prevent anyone from using stricter coding practices. I
fully appreciate the importance of a good unit test; not only that, I
believe that the test should be written not by the original
implementor of the class, but by someone else that doesn't even have
access to the source, but works _only_ by the formal specification of
the interface.

So 'override' does not really compete with a well chosen testing
methodology. The implementor uses 'override' and the tester uses unit
tests.

Incidentally, I do change virtual function signatures, when I can
afford to do so and when this leads to a better design. The tedious
search for overriders that follows is enough to make me a supporter of
'override.'

--
Peter Dimov
Multi Media Ltd.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3C0290D3.DA98AAC0@wanadoo.fr>, =?iso-8859-1?Q?Lo=EFc?= Joly says...

>Michiel Salters wrote:
>> In article <3BFE97B3.91430FB1@wanadoo.fr>, =3D?iso-8859-1?Q?Lo=3DEFc?=3D=
>> Joly says...
>> >Motivation :
>> >struct A
>> >{
>> >  virtual void f(char *s);
>> >};
>> >
>> >struct B : A
>> >{
>> >  virtual void f(char *s);
>> >};
>> >This works just fine, but now, suppose someone in charge of
>> >maintaining
>> >the A class discovers that the declaration of f should have been :
>> >virtual void f(char const *s);
>> >He makes the change, but somehow forget to change class B.

>> I expect a compiler to give a warning for this. Warnings are QOI,
>> though,
>> not mandated by the standard. If all compilers would give a warning, do
>> you think a language change is still in order ?
>
>Yes I do, because there are some case when we want to define a new
>virtual function in a derived class, and some case when we want to
>override an existing one.
>Thus, if I want all warnings to be removed in the final version of the
>code (and I usually want that), I will have to tell somehow that it is
>okay if this function is a new function, but not if that function is a
>new one.
>So I would have to add a compiler-specific flag (#prama, or something
>else) to tell it what kind of function it is.

I thought this was a good argument, but on second thinking I disagree.

class A {
virtual void f( const char* );
};
class B : public A {
virtual void f( char* );
};

and you get a warning about B::f hiding A::f (which was you intended).
And the compiler is right, because when you have

B b;
A* ptr_b=&b;
char buf[16];
b.f(buf);
ptr_b->f(buf);

you call an f method of the B object twice, with the same parameter, but
you get two different methods. I think that warning should be fixed.

Regards,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." wrote:
>
> Pete Becker wrote:
> ...
> > Good point: I missed that in the original discussion. Of course, any
> > maintainence programmer who changes a virtual function to non-virtual
> > should be immediately shot. No trial, no appeal, no pleas for clemency.
> > (Sorry about the harhs images -- I'm watching the news, so I'm in a foul
> > mood).
>
> How is someone supposed to correct an erroneously virtual function,
> without getting killed?
>
> ======================================= MODERATOR'S COMMENT:
>  C++ Standard-related content has also died; no more, please.
>

I don't agree. The standards committee is currently discussing the kinds
of changes that can be made to the standard.

A virtual function, no matter how erroneous, is still part of the
published interface to a class. If it shouldn't have been virtual then
document that it shouldn't be overridden. But don't break users' code.
They won't forgive you. More important, if they decide they can't trust
you then you won't sell to them in the future.

--
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.research.att.com/~austern/csc/faq.html                ]

Bill Wade wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote
>
> >The reason that it doesn't get any support from me is that it solves a
> >non-problem. If you want to be sure that your member function overrides
> >a virtual function in the base, write a test case that calls it through
> >the base. You have to do this anyway, in order to check the behavior of
> >your derived class. So this error falls out automatically from routine
> >testing.
>
> Please show me how to write the test for this template:
>
> template<class T, class U> class foo: T, U
> {
> public:
>   override int foo(){ return 7; }
> };
>

It's not possible to write tests in the absence of specifications. What
is this (invalid) code supposed to do, and what are the constraints on T
and U?

--
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.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis wrote:
>
> Certainly, it is doable.  But then, the same argument applies for
> checking that no object of an abstract class can be created.  Are you
> also arguing that that feature solves a non-problem?
>

No, that's not part of this discussion.

--
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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
> The reason that it doesn't get any support from me is that
> it solves a non-problem. If you want to be sure that your
> member function overrides a virtual function in the base,
> write a test case that calls it through the base. You have
> to do this anyway, in order to check the behavior of your
> derived class. So this error falls out automatically from
> routine testing.

Yes, and then you smack your hand against your forehead and say "Good
grief! Couldn't the compiler have caught a silly mistake like this?". I
would have thought it is better to detect errors at compile time
wherever possible because they are undoubtedly more costly to fix later.

- Jim


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Jim Barry wrote:
>
> Pete Becker wrote:
> > The reason that it doesn't get any support from me is that
> > it solves a non-problem. If you want to be sure that your
> > member function overrides a virtual function in the base,
> > write a test case that calls it through the base. You have
> > to do this anyway, in order to check the behavior of your
> > derived class. So this error falls out automatically from
> > routine testing.
>
> Yes, and then you smack your hand against your forehead and say "Good
> grief! Couldn't the compiler have caught a silly mistake like this?". I
> would have thought it is better to detect errors at compile time
> wherever possible because they are undoubtedly more costly to fix later.
>

On a construction site, if someone leaves a board with a nail sticking
out of it on the ground they get fired immediately. Nobody says
"couldn't someone have followed behind him and picked this up?" A class
author who changes a virtual function to non-virtual is no better. Don't
deal with someone who does this to you. They're not worthy of your
trust. There are more important things for a programming language to do
than protect you from traps set by your own suppliers.

As to the cost to fix "later", there shouldn't be much elapsed time
between changing code and running tests, so there's very little
incremental cost in postponing this particular check. If you want to
analyze costs you also have to look at the likelihood that this will
happen. Certainly beginners do it to themselves from time to time, and
if they make this mistake they'll learn an important lesson. Experienced
professionals don't make that sort of change. How many times has it
happened to you? What consequences were there for the person who did it?

--
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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> wrote in message news:<3C058126.36357A00@acm.org>...

[override keyword]

> The reason that it doesn't get any support from me is that it solves a
> non-problem. If you want to be sure that your member function overrides
> a virtual function in the base, write a test case that calls it through
> the base. You have to do this anyway, in order to check the behavior of
> your derived class. So this error falls out automatically from routine
> testing.

You are right. Programmers that use unit tests (group #1) don't need
override.

On the other hand, programmers that do not do proper testing (group
#2) will benefit from it. The cost will be an extra keyword.

Not giving group #2 what they want will not automatically make them
migrate to #1.

--
Peter Dimov
Multi Media Ltd.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker  wrote:
> Gabriel Dos Reis wrote:
>>
>> Certainly, it is doable.  But then, the same argument applies for
>> checking that no object of an abstract class can be created.  Are you
>> also arguing that that feature solves a non-problem?
>>
>
> No, that's not part of this discussion.

So you are for the stato-quo, because it's the statu-quo, and
against changes, because they are changes.

  --   VB

---
[ 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.research.att.com/~austern/csc/faq.html                ]

petebecker@acm.org (Pete Becker) wrote (abridged):
> So this error falls out automatically from routine testing.

If I preferred unit tests over compile-time error checking, I wouldn't be
using a statically type-checked language like C++.

Do you realise how much simpler C++ could be if we relegated all error
detection to unit tests? Why should this particular problem be left to
testing when the compiler tries so hard to find other problems?

I know people don't like it when we appeal to "the spirit of C++", but
I've just rescanned "Design Rules" chapter of D&E and I do think the
proposed feature is well in accord with them. (Especially the bit about
supporting composition of software from separately developed parts.) It is
also in accord with the stated aim of C++0x to make using C++ less
error-prone.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Valentin Bonnard wrote:
>
> Pete Becker  wrote:
> > Gabriel Dos Reis wrote:
> >>
> >> Certainly, it is doable.  But then, the same argument applies for
> >> checking that no object of an abstract class can be created.  Are you
> >> also arguing that that feature solves a non-problem?
> >>
> >
> > No, that's not part of this discussion.
>
> So you are for the stato-quo, because it's the statu-quo, and
> against changes, because they are changes.
>

Huh? I've said nothing about the status quo, nor have I said anything
for or against abstract classes. Please don't put words in my mouth.

--
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.research.att.com/~austern/csc/faq.html                ]

"Edward Diener" <eldiener@earthlink.net> wrote

> I do not like your proposal for the reason that you are attempting to
> add a feature to the language merely to prevent a programming error,
> rather than justifying some new functionality in C++ or making the
> syntax clearer in a much needed way. Additions to C++ merely to prevent
> programming errors is, to me, not in the spirit of the language.

I'd argue that the keywords private, protected, and public, were added to
the language merely to prevent programming errors, and do not make the
syntax any clearer.  If programmers don't need hand holding, why require a
cast when converting from double to void*?

IMO a major benefit of C++ is the ability to configure it to let me know
when I screw up.  An overload key word, as described earlier, seems to be
very much in that spirit.


---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3C02E8F1.4BDAAF29@acm.org>, Pete Becker <petebecker@acm.org>=20
writes
>Lo=EFc Joly wrote:
>>
>> This works just fine, but now, suppose someone in charge of maintainin=
g
>> the A class discovers that the declaration of f should have been :
>> virtual void f(char const *s);
>> He makes the change, but somehow forget to change class B. The compile=
r
>> will compile silently, but the program will not do the expected thing.
>> This is a real-world example that has already bitten me several times,
>> and is difficult to debug.
>>
>
>You should complain to the person who made that change without
>understanding and documenting its implications. Adding a virtual
>function to a class (whether that's a consequence of adding a new
>function or changing an existing one) is a drastic change, and users of
>the class should be alerted to it.

You mean like the way that the Standard encourages implementors to tell=20
users about adding parameters to functions (thereby changing their=20
signatures, and possibly altering overload resolution when assigning to=20
a pointer to member?  :-)

Unfortunately we live in a far from perfect world. It is a good idea to=20
check that the cars have actually stopped before stepping onto a=20
pedestrian crossing.


--=20
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
>
> In article <3C02E832.3A684B84@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >Edward Diener wrote:
> >>
> >> I take the opposite view that adequate
> >> documentation for classes is needed, outside of source code, and that it
> >> is not the responsibility of the language to become more complicated
> >> merely so that it becomes self-documenting.
> >>
> >
> >Further, it is the responsibity of every programmer to use classes
> >correctly. If a class's documentation isn't good enough to make that
> >possible then don't use that class.
>
> It is also the responsibility of every citizen to avoid walking in front
> of moving vehicles but that is not a reason for dispensing with ways of
> reducing the chances of it happening by accident or thoughtlessness.

Programmers are supposed to be professionals, developing code by sound
engineering, not by accident or thoughtlessness.

> Please also note that programmers do not always have the choice of what
> they use.
>
> Having said that I would agree with Edward.
>

So do you agree or disagree with my agreement with someone you agree
with?

--
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.research.att.com/~austern/csc/faq.html                ]

Edward Diener <eldiener@earthlink.net> wrote in message news:<3C025715.9050709@earthlink.net>...
> My personal view of C++ is that the spirit of the language is that the
> programmer is in charge and should know how to do things within the
> language syntax.

Indeed. This is a good legacy from C which takes the point of view
that the programmer is always right.

> Adding language syntax to make it easier to use the
> language effectively is one thing but adding language syntax to prevent
> a programmer making an error seems to me to be wrong.

There are languages that do this. Eiffel springs to mind. IMO C++ is
ok as it is but would have benefitted from an optional facility for
DbC. Too late now but it can be simulated. The GNU project NANA is an
attempt to provide DbC to C. There is a product called iContract that
provides DbC to java. AFAIK there is no DbC product for C++ yet.

> Many C++ programmers seem to feel that there is no need to document
> classes and class hierarchies effectively but that the language itself
> should become self-documenting. I take the opposite view that adequate
> documentation for classes is needed, outside of source code, and that it
> is not the responsibility of the language to become more complicated
> merely so that it becomes self-documenting.
>
I also believe in separate documentation but at a higher level. For
people that want very low level documentation I think that something
that produces it from the source code it ideal because it avoids the
problem of the code and the documentation getting out of step. Javadoc
is very nice. In C++ there is a package called doxygen that provides a
similar facility. It draws inheritance diagrams and indicates where
functions are acquired via inheritance etc.

Regards,

Andrew M.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
>=20
> In article <3C02E8F1.4BDAAF29@acm.org>, Pete Becker <petebecker@acm.org=
>
> writes
> >Lo=EFc Joly wrote:
> >>
> >> This works just fine, but now, suppose someone in charge of maintain=
ing
> >> the A class discovers that the declaration of f should have been :
> >> virtual void f(char const *s);
> >> He makes the change, but somehow forget to change class B. The compi=
ler
> >> will compile silently, but the program will not do the expected thin=
g.
> >> This is a real-world example that has already bitten me several time=
s,
> >> and is difficult to debug.
> >>
> >
> >You should complain to the person who made that change without
> >understanding and documenting its implications. Adding a virtual
> >function to a class (whether that's a consequence of adding a new
> >function or changing an existing one) is a drastic change, and users o=
f
> >the class should be alerted to it.
>=20
> You mean like the way that the Standard encourages implementors to tell
> users about adding parameters to functions (thereby changing their
> signatures, and possibly altering overload resolution when assigning to
> a pointer to member?  :-)

The standard neither encourages nor discourages this. It allows
implementors to add parameters with default values to non-virtual member
functions. Professional programmers know this, and don't assume that
they know the exact signature of such functions.

So, to answer your question, no, it has nothing to do with what the
standard says. Programmers who maintain classes that are designed to be
derived from must be sure they understand the consequences of any
interface changes they make, and must document those changes.

>=20
> Unfortunately we live in a far from perfect world. It is a good idea to
> check that the cars have actually stopped before stepping onto a
> pedestrian crossing.
>=20

Obviously, when you get an upgraded library you check the documentation
to see if any of the changes affect your code.

--=20
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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:

> Francis Glassborow wrote:
>=20
>>In article <3C02E8F1.4BDAAF29@acm.org>, Pete Becker <petebecker@acm.org=
>
>>writes
>>
>>>Lo=EFc Joly wrote:
>>>
>>>>This works just fine, but now, suppose someone in charge of maintaini=
ng
>>>>the A class discovers that the declaration of f should have been :
>>>>virtual void f(char const *s);
>>>>He makes the change, but somehow forget to change class B. The compil=
er
>>>>will compile silently, but the program will not do the expected thing.
>>>>This is a real-world example that has already bitten me several times=
,
>>>>and is difficult to debug.
>>>>
>>>>
>>>You should complain to the person who made that change without
>>>understanding and documenting its implications. Adding a virtual
>>>function to a class (whether that's a consequence of adding a new
>>>function or changing an existing one) is a drastic change, and users o=
f
>>>the class should be alerted to it.
>>>
>>You mean like the way that the Standard encourages implementors to tell
>>users about adding parameters to functions (thereby changing their
>>signatures, and possibly altering overload resolution when assigning to
>>a pointer to member?  :-)
>>
>=20
> The standard neither encourages nor discourages this. It allows
> implementors to add parameters with default values to non-virtual membe=
r
> functions. Professional programmers know this, and don't assume that
> they know the exact signature of such functions.

That would depend on your definition of "professsional."
Those who have been sufficiently diligent know this, but
I would be confident in saying that the majority of
developers I've met who make a living from programming
(which in some definitions makes them "professionals")
would blindly assume that signatures of standard methods
are always completely constrained by the standard.

You might have been more fortunate in meeting only
highly diligent developers, or I might have been
unfortunate in meeting many for whom programming is
"just a job," but the fact is that many who work as
programmers are not as knowledgeable as they ought
to be, and that places a burden on those who care
to (a) encourage better professionalism, and (b) to
try to minimize the impact of the vast number of
programmers who are not yet fully competent.  (I
say "not yet" because most of us start our
professional work with a particular language without
being fully competent with it.  Deep understanding
takes experience, and it's sadly not always possible
to gain that experience in harmless toy projects.)

-- James Dennett

---
[ 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.research.att.com/~austern/csc/faq.html                ]

petebecker@acm.org (Pete Becker) wrote (abridged):
> Obviously, when you get an upgraded library you check the documentation
> to see if any of the changes affect your code.

I would welcome a tool to automate the checking. It is very error-prone to
do it manually. And I think it's better to put this kind of consistency
check into the compiler than to have a separate Lint-like utility.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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.research.att.com/~austern/csc/faq.html                ]

eldiener@earthlink.net (Edward Diener) wrote (abridged):
> In the example given, the original poster wanted an addition to the
> language added because he missed the fact that a member function
> declared in a base class was virtual.

No. Perhaps you should read the example again.

The problem was that he ended up with *no* function (with matching
signature) in the base class, not a virtual one. And he arrived there
because of a change made by the base class's author; at the time the
derived class was written, it was correct.

Further, the author of the base class may not have been in a position to
check every derived class when he made his change. It is quite a tricky
problem of code management, when several different authors are involved.

I think it would be very helpful for the compiler to verify cross-module
consistency in this area. The issues remind me of type-safe linkage.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Lo   c Joly wrote:
> I would like to make a proposal for an addition to the C++
> standard. It pertains with virtual function that we want to
> be sure exist in the base class.

The "override" keyword is a fairly popular feature request for C++. It
appears relatively easy to implement, easy to teach, breaks no existing
code, and introduces no conflicts with existing language rules. The main
argument against it seems to be that you can get a similar effect by
making the virtual function pure in the base class. However, this stops
working at the second level of derivation. Given that there are
situations where it is necessary to override a non-pure virtual, it
seems useful for there to be a way of ensuring that the override
actually overrides something. So I would be in favour of this proposal
(though I don't like the "=1" idea). Unfortunately, for some reason the
"override" keyword doesn't seem to get much support from implementors or
committee members.

- Jim



---
[ 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.research.att.com/~austern/csc/faq.html                ]

brangdon@cix.co.uk (Dave Harris) wrote in message news:<memo.20011127230352.3025E@brangdon.madasafish.com>...
> I think it would be very helpful for the compiler to verify cross-module
> consistency in this area. The issues remind me of type-safe linkage.
>
>   Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
>       brangdon@cix.co.uk      |   And close your eyes with holy dread,

Maybe but I think C++ will never do this. In D&E and elsewhere
Stroustrup says that he considered making C++ more like an environment
but decided against it. This is one of the reasons why he left as
unspecified how C++ would resolve template instantiation: link-time
instantiate and compile-time instantiate are equally valid.

-apm

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Dave Harris wrote:
>
> petebecker@acm.org (Pete Becker) wrote (abridged):
> > Obviously, when you get an upgraded library you check the documentation
> > to see if any of the changes affect your code.
>
> I would welcome a tool to automate the checking. It is very error-prone to
> do it manually. And I think it's better to put this kind of consistency
> check into the compiler than to have a separate Lint-like utility.
>

It's no more error-prone than writing the original code. Bottom line:
don't replace a library without understanding the consequences.

--
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.research.att.com/~austern/csc/faq.html                ]

Dave Harris wrote:
>
> eldiener@earthlink.net (Edward Diener) wrote (abridged):
> > In the example given, the original poster wanted an addition to the
> > language added because he missed the fact that a member function
> > declared in a base class was virtual.
>
> No. Perhaps you should read the example again.
>
> The problem was that he ended up with *no* function (with matching
> signature) in the base class, not a virtual one. And he arrived there
> because of a change made by the base class's author; at the time the
> derived class was written, it was correct.

Good point: I missed that in the original discussion. Of course, any
maintainence programmer who changes a virtual function to non-virtual
should be immediately shot. No trial, no appeal, no pleas for clemency.
(Sorry about the harhs images -- I'm watching the news, so I'm in a foul
mood).

--
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.research.att.com/~austern/csc/faq.html                ]

Jim Barry wrote:
>=20
> Lo=EFc Joly wrote:
> > I would like to make a proposal for an addition to the C++
> > standard. It pertains with virtual function that we want to
> > be sure exist in the base class.
>=20
> The "override" keyword is a fairly popular feature request for C++. It
> appears relatively easy to implement, easy to teach, breaks no existing
> code, and introduces no conflicts with existing language rules. The mai=
n
> argument against it seems to be that you can get a similar effect by
> making the virtual function pure in the base class. However, this stops
> working at the second level of derivation. Given that there are
> situations where it is necessary to override a non-pure virtual, it
> seems useful for there to be a way of ensuring that the override
> actually overrides something. So I would be in favour of this proposal
> (though I don't like the "=3D1" idea). Unfortunately, for some reason t=
he
> "override" keyword doesn't seem to get much support from implementors o=
r
> committee members.
>=20

The reason that it doesn't get any support from me is that it solves a
non-problem. If you want to be sure that your member function overrides
a virtual function in the base, write a test case that calls it through
the base. You have to do this anyway, in order to check the behavior of
your derived class. So this error falls out automatically from routine
testing.

--=20
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.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote

>The reason that it doesn't get any support from me is that it solves a
>non-problem. If you want to be sure that your member function overrides
>a virtual function in the base, write a test case that calls it through
>the base. You have to do this anyway, in order to check the behavior of
>your derived class. So this error falls out automatically from routine
>testing.

Please show me how to write the test for this template:

template<class T, class U> class foo: T, U
{
public:
  override int foo(){ return 7; }
};


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
...
> Good point: I missed that in the original discussion. Of course, any
> maintainence programmer who changes a virtual function to non-virtual
> should be immediately shot. No trial, no appeal, no pleas for clemency.
> (Sorry about the harhs images -- I'm watching the news, so I'm in a foul
> mood).

How is someone supposed to correct an erroneously virtual function,
without getting killed?


======================================= MODERATOR'S COMMENT:
 C++ Standard-related content has also died; no more, please.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> writes:

| Jim Barry wrote:
| >=20
| > Lo=EFc Joly wrote:
| > > I would like to make a proposal for an addition to the C++
| > > standard. It pertains with virtual function that we want to
| > > be sure exist in the base class.
| >=20
| > The "override" keyword is a fairly popular feature request for C++. I=
t
| > appears relatively easy to implement, easy to teach, breaks no existi=
ng
| > code, and introduces no conflicts with existing language rules. The m=
ain
| > argument against it seems to be that you can get a similar effect by
| > making the virtual function pure in the base class. However, this sto=
ps
| > working at the second level of derivation. Given that there are
| > situations where it is necessary to override a non-pure virtual, it
| > seems useful for there to be a way of ensuring that the override
| > actually overrides something. So I would be in favour of this proposa=
l
| > (though I don't like the "=3D1" idea). Unfortunately, for some reason=
 the
| > "override" keyword doesn't seem to get much support from implementors=
 or
| > committee members.
| >=20
|=20
| The reason that it doesn't get any support from me is that it solves a
| non-problem. If you want to be sure that your member function overrides
| a virtual function in the base, write a test case that calls it through
| the base.

Certainly, it is doable.  But then, the same argument applies for
checking that no object of an abstract class can be created.  Are you
also arguing that that feature solves a non-problem?

--=20
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hello everybody,
This is my first post on this group, so I hope I am on-topic...

I would like to make a proposal for an addition to the C++ standard.
It pertains with virtual function that we want to be sure exist in the
base class.

Motivation :
struct A
{
  virtual void f(char *s);
};

struct B : A
{
  virtual void f(char *s);
};

int main ()
{
  A* a =3D new B;
  a->f();
}

This works just fine, but now, suppose someone in charge of maintaining
the A class discovers that the declaration of f should have been :
virtual void f(char const *s);
He makes the change, but somehow forget to change class B. The compiler
will compile silently, but the program will not do the expected thing.
This is a real-world example that has already bitten me several times,
and is difficult to debug.


Proposal :
Add something that will prevent compilation if a virtual function does
not have a function to override in the base class.
Some notation (with comments) may be :

struct B : A
{
  override virtual void f(char *s);
};

This syntax seems rather clear to me, but requires a new keyword, and
thus may break old programs (maybe we should give to 'static' yet
another signification ;)).
The good point is that is is very easy to compile this code on old (i.e.
current) compilers (just #define away the override keyword).

struct B : A
{
  virtual void f(char *s) =3D 1;
}

This syntax is not so clear, more difficult to #define away, but does
not require any new keyword. It also has the advantage of giving more
consistance to the existing virtual =3D0 syntax ;).




I would like to know what do you think of this proposal; and if there is
something I can do to make it accepted in the next standard, I would
like to have some advise about it.

--=20
Lo=EFc

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Lo   c Joly" <loic.actarus.joly@wanadoo.fr> wrote in message
news:3BFE97B3.91430FB1@wanadoo.fr...
...
> I would like to make a proposal for an addition to the C++ standard.
> It pertains with virtual function that we want to be sure exist in the
> base class.
...
> Proposal :
> Add something that will prevent compilation if a virtual function does
> not have a function to override in the base class.
> Some notation (with comments) may be :
...
>  override virtual void f(char *s);
> I would like to know what do you think of this proposal; and if there is
> something I can do to make it accepted in the next standard, I would
> like to have some advise about it.

Your proposal for an "override" keyword (or a "=1" suffix) at (virtual)
member function declarations
allows the specification of conditions on base / derived classes.

I support this, as I am already using "override" for a long time in my c++
code, like in Delphi.
(
  in fact, I use the following defines to use "override f();" instead of
"virtual f()" where appropiate,
  but are still waiting for supporting compilers
  #define override virtual
  #define final virtual
)

To support more fine tuned and readable specification of the contractual
offers and acceptance of base- and derived- classes,
which will be good for the builders AND users of class-frameworks,
I here propose a generalized version of your proposal (and other proposals
in this direction, such as "final").

The existing suffix "=0" puts a condition on all DERIVED classes from which
actual objects are constructed
(which I will call implementing classes):
f()=0; MUST BE overridden in any derived (constructible) class.
Your proposed "override" prefix puts a condition on BASE classes:
f() MUST have BEen declared (virtual) in one of the specified base classes.

To generalize this and other proposals in this direction,
I would like also to specifiy the opposite conditions,
thus that f() MAY NOT have BEen declared (virtual) in any of the base
classes; f() MUST BE an "additional" virtual,
or that f() MAY NOT BE overridden any more in any derived classes
(some have proposed a "final" keyword here, but the "=1" suffix seems more
consistent for this purpose)

This all can be summarized in the following matrix:

               | Implementing classes and  f()
               | MUST HAVE                    | Maybe                   |
MAY NOT HAVE, overriding f() in derived classes is forbidden
--------+------+---------------------------+-------------------------+------
---------
BASE    | YES  | override virtual f()=0;   |override virtual f();    |
override virtual f()=1;
CLASS   | Maybe| virtual f()=0;            |virtual f();             |
virtual f()=1;
HAS f() | NO   | additional virtual f()=0; | additional virtual f(); | f();
(or additional virtual f() = 1;)

Thus, the relation with base classes can be speficied by optionally using
either "override" or "additional"
(optinally) combined with "virtual",
whereas restrictions on derived classes can be specified by the optional use
of either "=0" or "=1".

Additional semantic rules for overloading non-virtual functions may have to
be defined.

Note that conditions on the allowance of (further) derivation can be
enforced by
specifying the =0 or =1 conditions on the destructor.

Breaking Existing Code?
Existing code can be compiled on compilers that support these extensions
(exept when the keywords "override" or "additional" are used as identifiers;
it would help to put these keywords on a "don't use these anymore, you never
know" list.)

The use of the new keywords "additional" and "override" (instead of new or
static); makes it possible to
compile new featured code on existing compilers (by using two simple
#defines).

New code that uses "=1" cannot be compiled on existing compilers;
but you can use defines here as Compiler-Fine-Tuning:
#define CFT_ABSTR =0
#define CFT_FINAL =1

Conclusions:
Although changing the standard seems to meet much resistance,
I would like the above stated non-code-breaking features to be included in a
future standard.

Maarten Hilferink.


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Lo=EFc Joly wrote:

> Hello everybody,
> This is my first post on this group, so I hope I am on-topic...
>=20
> I would like to make a proposal for an addition to the C++ standard.
> It pertains with virtual function that we want to be sure exist in the
> base class.
>=20
> Motivation :
> struct A
> {
>   virtual void f(char *s);
> };
>=20
> struct B : A
> {
>   virtual void f(char *s);
> };
>=20
> int main ()
> {
>   A* a =3D new B;
>   a->f();
> }
>=20
> This works just fine, but now, suppose someone in charge of maintaining
> the A class discovers that the declaration of f should have been :
> virtual void f(char const *s);
> He makes the change, but somehow forget to change class B. The compiler
> will compile silently, but the program will not do the expected thing.
> This is a real-world example that has already bitten me several times,
> and is difficult to debug.
>=20
>=20
> Proposal :
> Add something that will prevent compilation if a virtual function does
> not have a function to override in the base class.
> Some notation (with comments) may be :
>=20
> struct B : A
> {
>   override virtual void f(char *s);
> };
>=20
> This syntax seems rather clear to me, but requires a new keyword, and
> thus may break old programs (maybe we should give to 'static' yet
> another signification ;)).
> The good point is that is is very easy to compile this code on old (i.e.
> current) compilers (just #define away the override keyword).
>=20
> struct B : A
> {
>   virtual void f(char *s) =3D 1;
> }
>=20
> This syntax is not so clear, more difficult to #define away, but does
> not require any new keyword. It also has the advantage of giving more
> consistance to the existing virtual =3D0 syntax ;).
>=20
>=20
>=20
>=20
> I would like to know what do you think of this proposal; and if there i=
s
> something I can do to make it accepted in the next standard, I would
> like to have some advise about it.


I do not like your proposal for the reason that you are attempting to=20
add a feature to the language merely to prevent a programming error,=20
rather than justifying some new functionality in C++ or making the=20
syntax clearer in a much needed way. Additions to C++ merely to prevent=20
programming errors is, to me, not in the spirit of the language.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Edward Diener wrote:

> I do not like your proposal for the reason that you are attempting to
> add a feature to the language merely to prevent a programming error,
> rather than justifying some new functionality in C++ or making the
> syntax clearer in a much needed way. Additions to C++ merely to prevent
> programming errors is, to me, not in the spirit of the language.

I think that the next round of work on the C++ Standard will look
very hard at prevention of programming errors, and rightly so.
We don't want more complexity for the same of being clever; we
want to make a more practical tool without removing the power.

-- James Dennett

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Edward Diener <eldiener@earthlink.net> writes:

[...]

|  Additions to C++ merely to prevent
| programming errors is, to me, not in the spirit of the language.

Apparently, you do know what is "the spirit of the language".  Please,
would you like to share that knowledge with me?  Thanks.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3BFE97B3.91430FB1@wanadoo.fr>, =?iso-8859-1?Q?Lo=EFc?= Joly says...
>
>Hello everybody,
>This is my first post on this group, so I hope I am on-topic...
>
>I would like to make a proposal for an addition to the C++ standard.
>It pertains with virtual function that we want to be sure exist in the
>base class.
>
>Motivation :
>struct A
>{
>  virtual void f(char *s);
>};
>
>struct B : A
>{
>  virtual void f(char *s);
>};
>
>int main ()
>{
>  A* a =3D new B;
>  a->f();
>}

Neither A::f() nor B::f() can be called without arguments!

>This works just fine, but now, suppose someone in charge of maintaining
>the A class discovers that the declaration of f should have been :
>virtual void f(char const *s);
>He makes the change, but somehow forget to change class B. The compiler
>will compile silently, but the program will not do the expected thing.
>This is a real-world example that has already bitten me several times,
>and is difficult to debug.

I expect a compiler to give a warning for this. Warnings are QOI, though,
not mandated by the standard. If all compilers would give a warning, do
you think a language change is still in order ?

Regards,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis wrote:

> Edward Diener <eldiener@earthlink.net> writes:
>
> [...]
>
> |  Additions to C++ merely to prevent
> | programming errors is, to me, not in the spirit of the language.
>
> Apparently, you do know what is "the spirit of the language".  Please,
> would you like to share that knowledge with me?  Thanks.

In the example given, the original poster wanted an addition to the

language added because he missed the fact that a member function declared

in a base class was virtual. This was his error but he felt that an
addition to the language which would have alerted him to this fact would
be beneficial. I think better documentation of his class hierarchy is
all he needs and not for the language to have to tell him which member
functions are originally virtual in an immediate base class or not.

My personal view of C++ is that the spirit of the language is that the
programmer is in charge and should know how to do things within the
language syntax. Adding language syntax to make it easier to use the
language effectively is one thing but adding language syntax to prevent
a programmer making an error seems to me to be wrong.

Many C++ programmers seem to feel that there is no need to document
classes and class hierarchies effectively but that the language itself
should become self-documenting. I take the opposite view that adequate
documentation for classes is needed, outside of source code, and that it
is not the responsibility of the language to become more complicated
merely so that it becomes self-documenting.


---
[ 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.research.att.com/~austern/csc/faq.html                ]

If you had made function f() a pure virtual function, you could avoid this
problem.

"Lo   c Joly" <loic.actarus.joly@wanadoo.fr> wrote in message
news:3BFE97B3.91430FB1@wanadoo.fr...
Hello everybody,
This is my first post on this group, so I hope I am on-topic...

I would like to make a proposal for an addition to the C++ standard.
It pertains with virtual function that we want to be sure exist in the
base class.

Motivation :
struct A
{
  virtual void f(char *s);
};

struct B : A
{
  virtual void f(char *s);
};

int main ()
{
  A* a = new B;
  a->f();
}

This works just fine, but now, suppose someone in charge of maintaining
the A class discovers that the declaration of f should have been :
virtual void f(char const *s);
He makes the change, but somehow forget to change class B. The compiler
will compile silently, but the program will not do the expected thing.
This is a real-world example that has already bitten me several times,
and is difficult to debug.


Proposal :
Add something that will prevent compilation if a virtual function does
not have a function to override in the base class.
Some notation (with comments) may be :

struct B : A
{
  override virtual void f(char *s);
};

This syntax seems rather clear to me, but requires a new keyword, and
thus may break old programs (maybe we should give to 'static' yet
another signification ;)).
The good point is that is is very easy to compile this code on old (i.e.
current) compilers (just #define away the override keyword).

struct B : A
{
  virtual void f(char *s) = 1;
}

This syntax is not so clear, more difficult to #define away, but does
not require any new keyword. It also has the advantage of giving more
consistance to the existing virtual =0 syntax ;).




I would like to know what do you think of this proposal; and if there is
something I can do to make it accepted in the next standard, I would
like to have some advise about it.

--
Lo   c

---
[ 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.research.att.com/~austern/csc/faq.html                ]


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Michiel Salters wrote:
>=20
> In article <3BFE97B3.91430FB1@wanadoo.fr>, =3D?iso-8859-1?Q?Lo=3DEFc?=3D=
 Joly says...
> >
> >Hello everybody,
> >This is my first post on this group, so I hope I am on-topic...
> >
> >I would like to make a proposal for an addition to the C++ standard.
> >It pertains with virtual function that we want to be sure exist in the
> >base class.
> >
> >Motivation :
> >struct A
> >{
> >  virtual void f(char *s);
> >};
> >
> >struct B : A
> >{
> >  virtual void f(char *s);
> >};
> >
> >int main ()
> >{
> >  A* a =3D new B;
> >  a->f();
> >}
>=20
> Neither A::f() nor B::f() can be called without arguments!
>=20
Oups ! Of course, I meant :
a->f("Hello world");

> >This works just fine, but now, suppose someone in charge of maintainin=
g
> >the A class discovers that the declaration of f should have been :
> >virtual void f(char const *s);
> >He makes the change, but somehow forget to change class B. The compile=
r
> >will compile silently, but the program will not do the expected thing.
> >This is a real-world example that has already bitten me several times,
> >and is difficult to debug.
>=20
> I expect a compiler to give a warning for this. Warnings are QOI, thoug=
h,
> not mandated by the standard. If all compilers would give a warning, do
> you think a language change is still in order ?

Yes I do, because there are some case when we want to define a new
virtual function in a derived class, and some case when we want to
override an existing one.
Thus, if I want all warnings to be removed in the final version of the
code (and I usually want that), I will have to tell somehow that it is
okay if this function is a new function, but not if that function is a
new one.
So I would have to add a compiler-specific flag (#prama, or something
else) to tell it what kind of function it is.
Here goes portability.

--=20
Lo=EFc

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Edward Diener wrote:
>
> I take the opposite view that adequate
> documentation for classes is needed, outside of source code, and that it
> is not the responsibility of the language to become more complicated
> merely so that it becomes self-documenting.
>

Further, it is the responsibity of every programmer to use classes
correctly. If a class's documentation isn't good enough to make that
possible then don't use that class.

--
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.research.att.com/~austern/csc/faq.html                ]

Lo=EFc Joly wrote:
>=20
> This works just fine, but now, suppose someone in charge of maintaining
> the A class discovers that the declaration of f should have been :
> virtual void f(char const *s);
> He makes the change, but somehow forget to change class B. The compiler
> will compile silently, but the program will not do the expected thing.
> This is a real-world example that has already bitten me several times,
> and is difficult to debug.
>=20

You should complain to the person who made that change without
understanding and documenting its implications. Adding a virtual
function to a class (whether that's a consequence of adding a new
function or changing an existing one) is a drastic change, and users of
the class should be alerted to it.

--=20
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.research.att.com/~austern/csc/faq.html                ]

Edward Diener wrote:
>=20
> In the example given, the original poster wanted an addition to the
>=20
> language added because he missed the fact that a member function declar=
ed
>=20
> in a base class was virtual.

I am sorry if I did not express myself clearly enough. What I miss is
the possibility to ensure that a virtual function overrides a function
in a base class,  and is not the declaration of a brand new function.
The case when I find it most usefull is in case of a modification in the
base class, that has to be applied to all derived classes.

[...]

> My personal view of C++ is that the spirit of the language is that the
> programmer is in charge and should know how to do things within the
> language syntax. Adding language syntax to make it easier to use the
> language effectively is one thing but adding language syntax to prevent
> a programmer making an error seems to me to be wrong.

What is your opinion about the use of protected, private, declaring and
not defining a copy constructor... ?
I think my proposal goes in the same direction : Helping the programmer
to avoid errors. Removing those in a correct program would not change
the program, but using them helped to make the program correct in the
first place.
My proposal incurs no runtime penalty, and I think it would not be
difficult to implement it.

[...]

--=20
Lo=EFc

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3C02E832.3A684B84@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Edward Diener wrote:
>>
>> I take the opposite view that adequate
>> documentation for classes is needed, outside of source code, and that it
>> is not the responsibility of the language to become more complicated
>> merely so that it becomes self-documenting.
>>
>
>Further, it is the responsibity of every programmer to use classes
>correctly. If a class's documentation isn't good enough to make that
>possible then don't use that class.

It is also the responsibility of every citizen to avoid walking in front
of moving vehicles but that is not a reason for dispensing with ways of
reducing the chances of it happening by accident or thoughtlessness.
Please also note that programmers do not always have the choice of what
they use.

Having said that I would agree with Edward.


--
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Mon, 26 Nov 2001 17:18:04 GMT, Edward Diener <eldiener@earthlink.net> pisze:

> My personal view of C++ is that the spirit of the language is that the
> programmer is in charge and should know how to do things within the
> language syntax. Adding language syntax to make it easier to use the
> language effectively is one thing but adding language syntax to prevent
> a programmer making an error seems to me to be wrong.

What about public, private and protected? They don't increase
expressiveness, only make some mistakes detected by the compiler.

--
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK

---
[ 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.research.att.com/~austern/csc/faq.html                ]