Jim Hill wrote:
>
> If so, it seems to me you're combining a perfectly valid pet peeve

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

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

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. So, is the proposal that
every overriding function must be marked 'override'? Thus breaking just
about every C++ program in existence?

> if you can argue that
> good programmers will always test, I can argue they'll always read the
> doc.
>

Long experience shows that reading the documentation doesn't
automatically translate into writing correct code. It makes it far more
likely, but testing is still needed.

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

petebecker@acm.org (Pete Becker) wrote (abridged):
> So, is the proposal that every overriding function must be
> marked 'override'? Thus breaking just about every C++ program
> in existence?

Well, no, but vendors of compilers or lint-like tools could issue optional
warnings. I'd switch it on. It'd be worth half a day tracking down all the
overrides and fixing them.

It's also worth considering making "override" mandatory for functions that
override functions that themselves have "override". Thus adding the
keyword to base class functions would enforce good practice on the derived
classes, at least to a degree. I'm not sure if this is actually a good
idea - it might discourage library vendors from using "override", for fear
of breaking clients that don't want to use it. But it's worth considering.

  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                ]

"James Kuyper Jr." wrote:
>
> Pete Becker wrote:
> ...
> > Prototypes serve some purposes that are not made redundant by testing.
> > In particular, by specifying the types of the arguments to a function,
> > they enable the compiler to determine what conversions are needed at the
> > point where a function is called. If they weren't available these
> > conversions would have to be provided by the programmer. Experience has
> > amply demonstrated the added time it takes to get function calls right
> > under these circumstances, so removing them would be a big step
> > backwards. ...
>
> Automatic type checking is the primary advantage provided by prototypes.

Yes, obviously. The claim that I responded to was that testing made this
irrelevant, so I pointed out other benefits.

> Automatic conversions are just a useful side-effect, made possible by
> the same constructs that made the type checking possible. Automated type
> checking is certainly redundant with proper software development
> process, a fact that is just as poor an argument against function
> prototypes as your argument is against checked exception specifications.

How did checked exception specifications get into this discussion? If
you're referring to my objection to 'override', the point is that
prototypes provide benefits other than automatic checking, while
'override' only provides automatic checking. Since the automatic
checking that would come from 'override' checks for an error that's rare
to non-existent in professional code, testing is a better alternative.

--
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:
...
> > Automatic conversions are just a useful side-effect, made possible by
> > the same constructs that made the type checking possible. Automated type
> > checking is certainly redundant with proper software development
> > process, a fact that is just as poor an argument against function
> > prototypes as your argument is against checked exception specifications.
>
> How did checked exception specifications get into this discussion? If

Sorry - I lost track of the different threads going on. :-( It's still a
poor argument against 'override', but I have to admit it's not quite as
poor.

> you're referring to my objection to 'override', the point is that
> prototypes provide benefits other than automatic checking, while
> 'override' only provides automatic checking. Since the automatic
> checking that would come from 'override' checks for an error that's rare
> to non-existent in professional code, testing is a better alternative.

I'd say that this fact weakens the case for 'override', but does not
refute it. That's just a judgement call, of course.

---
[ 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:
>
> I propose that we suppress function prototypes, since
> their use is redondant with well written test cases.
>

Prototypes serve some purposes that are not made redundant by testing.
In particular, by specifying the types of the arguments to a function,
they enable the compiler to determine what conversions are needed at the
point where a function is called. If they weren't available these
conversions would have to be provided by the programmer. Experience has
amply demonstrated the added time it takes to get function calls right
under these circumstances, so removing them would be a big step
backwards. Further, since they're already in both C and C++, removing
them would break a great deal of code. For these reasons, eliminating
function prototypes would not be a good idea.

--
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:
...
> Prototypes serve some purposes that are not made redundant by testing.
> In particular, by specifying the types of the arguments to a function,
> they enable the compiler to determine what conversions are needed at the
> point where a function is called. If they weren't available these
> conversions would have to be provided by the programmer. Experience has
> amply demonstrated the added time it takes to get function calls right
> under these circumstances, so removing them would be a big step
> backwards. ...

Automatic type checking is the primary advantage provided by prototypes.
Automatic conversions are just a useful side-effect, made possible by
the same constructs that made the type checking possible. Automated type
checking is certainly redundant with proper software development
process, a fact that is just as poor an argument against function
prototypes as your argument is against checked exception specifications.

> ... Further, since they're already in both C and C++, removing
> them would break a great deal of code. For these reasons, eliminating
> function prototypes would not be a good idea.

I'm fairly certain that Valentin was being sarcastic when he made that
proposal.

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