Re: Stroustrup's FAQ causes infinite loop when executed

From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 03/30/04 

Date: Mon, 29 Mar 2004 19:11:21 -0500

Claudio Puviani wrote:

> "Steven T. Hatton" <susudata@setidava.kushan.aa> wrote
 
> I missed that completely. Call me a fuddy-duddy, but "the feature isn't
> really needed since the same effect can be obtained as follows..." doesn't
> draw gales of laughter from me. Maybe I'm just getting old.

I believe it's called wry humor.

>> There may be hard requirements such as a class that somehow
>> manages its copy constructor to copy on modify, or perhaps a
>> class used in establishing secure connections.
>
> Secure connections can still be established in derived classes, unless the
> class' design is completely absurd. That argument is bogus.

I believe one example that was given for a reason to cap a class was a
callback function. My point regarding a secure connection is that
preventing a programmer from extending it might be a means of establishing
a level of certainty for an auditor who can look at a known commodity and
identify it as trusted. There may be ways in which inheritance could
compromise the integrity of the class by opening a second data path to the
most derived class.

As you have said, there are ways a class might be extended that the
programmer could not have foreseen.

>> Stroustrup does suggest there are times when it is appropriate to
>> restrict inheritance.
>
> He then debunks those alleged "needs" in the subsequent paragraphs.
>
>> Going back to real-time simulation, that can involve rather
>> complex calculations such as multiplying numerous transformation
>> matrices each iteration. In that case there may be a performance
>> reason to cap the class.
>
> Bull. Inheritance per se doesn't add computational costs. You're
> practicing design by superstition. In the following example:

I would have to think through this very carefully and examine how the type
resolution might produce an extra cost. If it does, that will compound very
quickly when repeated for each calculation. I'm not certain certain type
resolution can't be resolved at compile time, rather than runtime unless
the function were overridden.

> Throwing in "real-time" just to impress the
> ignorant masses doesn't do a thing for your argument and makes you look
> like a blustering teen to those who actually have worked with real-time
> systems.

No. Real-time simulation means that you want the frames drawn as they are
calculated rather than producing the frames one by one through a series of
time consuming rendering process such as ray tracing. And then playing the
simulation back. It's the distinction between http://www.povray.org/ and
OpenGL.

> Project guidelines and design/code reviews serve that purpose amply
> without the need to throw in training wheels.
>
>> People won't always read, or heed your suggestions provided
>> in comments.
>
> They do if they want to keep their jobs. Maybe you work in a free-spirited
> environment where flowers line the walls and the smell of burning hemp
> permeates the air as you dance barefoot to psychadelic melodies, but in an
> engineering environment, people actually have to follow rules and justify
> their design decisions.
>
>> They don't always remember what the comment said.
>
> Most programmers I know have the good sense to review the docs before
> jumping into something as drastic as inheriting from a foreign class.
>
>> If the option simply isn't there, and a clear alternative is
>> capping the class ensures people stay on the path you chose.
>
> People stay on the path that a project team has chosen because they're not
> morons, not because they have their legs shackled.

http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=Kansas+City+Hyatt+Regency+Walkway+Collapse&btnG=Search

>> The programmers aren't idiots argument could be applied as a
>> counter-argument to his choice as well.
>
> This, I don't follow.

Why not make it easy to use the feature in case the programmer does believe
there is a compelling reason for it? Because you don't think they should be
using it? 

-- 
p->m == (*p).m == p[0].m

Relevant Pages

  • Re: Object Oriented simpleton design pattern
    ... makes me believe that Inheritance and Polymorphism are the joint ... For reuse without any changes, ... functions but rather functionality. ... Implemenation inheritance is simply a means where a programmer can instruct ...
    (microsoft.public.vb.general.discussion)
  • Re: Why Is This Bad Code?
    ... What happens if the programmer ... If there were some other reason to abstract them, ... > polymorphism. ... time permits. ...
    (comp.lang.cpp)
  • Re: ALTER design (Was: Code problems with Perform Thru Exit causes fall through)
    ... Or losing one's job. ... decent, sane, well-educated, clean-fingernailed programmer can see - then ... have to be re-run and one can lose customers because of dissatisfaction ... certain there was a Very Good Reason for that. ...
    (comp.lang.cobol)
  • Re: should every thing be zero indexed?
    ... they usually count with zero indexed ... > There is a logical reason why you should do this with arrays, ... I just don't know why a programmer would want his 4th ... efficient code is probably produced by counting down, ...
    (comp.programming)
  • Re: Modularity problems with multiple dispatch
    ... rules for inheritance etc. Do the same for B', ... a so-called 'effective method' is run, ... but they cannot capture all aspects of a function's behaviour under run-time dispatch. ... means for the programmer that he/she should be prepared to ...
    (comp.lang.functional)