Pete Becker <petebecker@acm.org> wrote in message news:<3C1256DD.ABDE823C@acm.org>...

> Interesting how many posters to this group claim to know my thoughts
> without my having told them.

I really think that was uncalled-for.  (a) Do "have I got that right"
and "it seems to me" mean nothing? (b) What is this if not our
attempts to make our thoughts known?

I know you feel strongly about tests and sufficiency.  That's very
plain; I daresay I know the nature of your thoughts on that subject.
I'm trying to put the argument so far into terms that can be
considered dispassionately.

> As I've said several times, unless 'override' is mandatory on all
> overriding functions, it doesn't save anything

Yes, I gathered that from other subthreads. And I think you have a
worthwhile point; but a point for or against doesn't make an argument,
let alone a decision.

For instance, that reasoning applies to requiring `int`, because
`(*f);` isn't obviously a declaration. I very seriously doubt that
anybody here can remember the last time that one cost any time at all
(yes, I still use C, too), and even though it's mandatory in C++ [at
namespace scope, anyway] it doesn't help because I still have to test,
and even the simplest test will show that `(*f);` doesn't do anything
at all.

If you can't distinguish the two cases on some grounds other than the
status quo, you don't have an argument but a strongly held conviction.
It's worth as much as any conviction strongly held by an experienced
engineer: it demands consideration. But the only actual argument
you've been providing to back up your conviction apparently isn't
winning people over, and simply repeating it,

> So, is the proposal that
> every overriding function must be marked 'override'?

or getting sarcastic, isn't going to change that.

I find the argument for `override` much weaker than that for `default`
in argument lists: it's yet another new keyword, it only helps detect
a rare albeit obviously nasty error, and as you point out if it isn't
made mandatory it'll only help when programmers have the discipline to
use it and the foresight to tell where it's needed.

On the other hand, there's the case when you don't really trust the
people supplying your interfaces, i.e. it's not your discipline that's
lacking, but "theirs".  Switching vendors is a huge cost and, for
example, when the "vendor" is another department, may not be possible
at all.  I can see the keyword providing real value in those cases.

If it mattered any, I'd say it's close enough to a tie thus far that
I'd resolve it in favor of the status quo. But I wouldn't agree to
resolve it, yet. Not enough evidence, lots of time.

Regards,
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 Hill" <jthill_@mac.com> wrote

> o  there's no experience showing it would actually save time
> (stipulated),

I've got the experience.

> o  nobody here can remember losing much time for screwing this up
> (errm...),

I can remember.  A simplified example:

Given:

// Engine interfaces and class
struct Engine{ virtual double Value()=0; };
struct TransientEngine: Engine { virtual double Time()=0; virtual void
Speed()=0; };
struct T: TransientEngine { /* override */ double Value();
                                         /* override */ double Time();
                                         /* override */  void Speed(); };
....
// Proxy interfaces and classes allowing access to remote engines.
struct EngineProxy{ double Value()=0; };
struct TransientEngineProxy: EngineProxy{ virtual double Time(); };
struct TCorbaProxy: TransientEngineProxy{ /* override */ double Value(); };
struct TComProxy: EngineProxy{ /* override */ double Value(); };
....

I don't have the source for all code that uses Engine or EngineProxy, but I
do have all of the source code that implements or uses any of the other
classes I listed.  Changing requirements meant that client code needed
access to Speed() through any proxy to a transient engine.  I added the
following members
   virtual void TransientEngineProxy::Speed()=0;
   /* override */ void TCorbaProxy::Speed();
   /* override */ void TComProxy::Speed();
In the client code I used
   TransientEngineProxy* tep =
dynamic_cast<TransientEngineProxy*>(some_proxy);
   if(tep)
     tep->Speed();
   else
     DoSomethingElse();
I wrote unit tests that tested all of the combinations.  They told me that
something was wrong.   However it took me about 30 minutes to find the bug,
a couple of minutes to fix the bug, and another 45 minutes (of my time, more
elapsed time) to build and test again.

If override were a keyword rather than a comment, I would have gotten a
compiler error that told me that TComProxy doesn't inherit from anything
that has Speed().  That would have probably been enough for me to find the
error within a couple of minutes.  I would have gotten the message before I
did a complete build or unit test.

Is this kind of bug the main reason I want 'override'?  No.  I do code
reviews and that involves checking override comments by hand.  I'd much
rather have the compiler make that check for me.

---
[ 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

> As I've said several times, unless 'override' is mandatory on all
> overriding functions, it doesn't save anything, becuase you still have
> to use other methods for finding such errors.

I suspect that the New York Times uses both proof-readers and automated
spelling checkers.  So why use automated spelling checkers if ewe still
knead proof-readers to find some spelling errors?  Perhaps redundant error
Czechs actually do save something?


---
[ 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" <wrwade@swbell.net> wrote in message news:<EwhR7.4195$OU3.2566763738@newssvr11.news.prodigy.com>...

> Is this kind of bug the main reason I want 'override'?  No.  I do code
> reviews and that involves checking override comments by hand.  I'd much
> rather have the compiler make that check for me.

I think the ~tools for external-interface-firewall-checking~ is the
strongest argument for the proposal too.  I worry that, in practice,
it would be as valuable as exception specifications (imvho useful only
in the same situations, but they require cooperation on both sides).

Then again, if people didn't stick exception specifications in places
where the pain exceeds the gain, maybe they wouldn't be regarded as
such a pain; and maybe that same line would be useful here.

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 <petebecker@acm.org> wrote in message news:<3C095BF4.98D5A3E0@acm.org>...
> Experience has amply demonstrated the added time it takes to get function
> calls right [without prototypes], so removing them would be a big step
> backwards.

This makes the argument against `override`:

o  there's no experience showing it would actually save time
(stipulated),
o  nobody here can remember losing much time for screwing this up
(errm...),
o  even if `virtual` novices <g> do tend to break things this way
(unknown),
o  it would be wrong to make `override` a keyword again just for them,
because
o  it would make good testing discipline somewhat less-apparently
necessary.

Have I got that right?

If so, it seems to me you're combining a perfectly valid pet peeve
with a rather weak argument.  I don't see any contradiction in
demanding good tests and wanting this, especially when it would detect
the problem as soon as the derived class is compiled.

I'll note, with others, that this will detect the problem sooner than
unit tests, and tell customers when their vendor has moved their
cheese.

I'll also note that it's not always an error when a vendor does this,
unless you want to argue that vendors should never document interfaces
as e.g. useful but not yet stable, and instead should make immature
interfaces `private` and declare everything that uses them internally
a `friend`, then go back and rework the whole thing when it's finally
stable.  That strikes me as genuinely pointless: if you can argue that
good programmers will always test, I can argue they'll always read the
doc.

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                ]

I propose that we suppress function prototypes, since
their use is redondant with well written test cases.

  --   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                ]

Valentin.Bonnard@free.fr (Valentin Bonnard) wrote in message news:<200112011243.NAA10502@brick.ens.fr>...
> I propose that we suppress function prototypes, since
> their use is redondant with well written test cases.
>
>   --   VB

Indeed. In fact you don't even need to write test cases. You just need
to be a competent programmer then the code will be correct. Strong
typing is for weak minds. The language should not have to change to
support the feeble-minded. Separate tools should be used. The tools
will have to be implemented by the feeble-minded since the competent
ones are far too busy writing correct C++. See the lint++ discussion
in comp.lang.c++.moderated.

-Andrew M.


======================================= MODERATOR'S COMMENT:
 I'm approving this on the assumption that it's "refutation by overt sarcasm"...

---
[ 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                ]