The private-inheritance variant allows Car to override Engine's virtual functions

Discussion in 'C++' started by puzzlecracker, Sep 28, 2007.

  1. The statement is taken from FAQ [24.2]. What about non-virtual
    functions? Can they be overriden? I still don't see a good
    justification to prefer private inheritance over composition. In
    fact, I have never seen it in a commercial code. If someone did,
    please share the use-case and decisions behind it.


    Thanks
    puzzlecracker, Sep 28, 2007
    #1
    1. Advertising

  2. puzzlecracker wrote:
    > The statement is taken from FAQ [24.2]. What about non-virtual
    > functions? Can they be overriden?


    No. The term "override" relates only to virtual functions. Non-
    virtual functions are either inherited or hidden. They can also
    be overloaded if brought into the derived class' scope with the
    help of a 'using' declaration.

    > I still don't see a good
    > justification to prefer private inheritance over composition. In
    > fact, I have never seen it in a commercial code. If someone did,
    > please share the use-case and decisions behind it.


    I am too lazy to search through our multimillion-LOC codebase,
    and there is no guarantee I'd find anything. If you don't see
    a good justification now, you won't see any justification given
    to you as good, either. Goodness is in the eye of the beholder.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Sep 28, 2007
    #2
    1. Advertising

  3. On Sep 28, 6:30 am, puzzlecracker <> wrote:
    > The statement is taken from FAQ [24.2]. What about non-virtual
    > functions? Can they be overriden? I still don't see a good
    > justification to prefer private inheritance over composition. In
    > fact, I have never seen it in a commercial code. If someone did,
    > please share the use-case and decisions behind it.
    >
    > Thanks


    I think it's fair to say that there's nothing that can be done with
    private inheritance that can't be done with aggregation/composition.
    The usual justification is that you want to aggregate a class and
    override some virtual methods that it provides. Consider a class that
    will use a timer. The timer has a virtual method OnTick which is
    called every n seconds as defined in the class.
    You could derive a class and override the OnTick method to do
    something specific for your class and then aggregate that derivation.
    Or, you could inherit privately and override OnTick within your class
    giving you slightly/arguably cleaner code.
    Jonathan Lane, Sep 28, 2007
    #3
  4. On Sep 28, 6:30 am, puzzlecracker <> wrote:
    > The statement is taken from FAQ [24.2]. What about non-virtual
    > functions? Can they be overriden? I still don't see a good
    > justification to prefer private inheritance over composition. In
    > fact, I have never seen it in a commercial code. If someone did,
    > please share the use-case and decisions behind it.
    >
    > Thanks


    AFAIK one reason to prefer private inheritance over
    composition is to simplify delegation: eg:

    class Embedee {
    public:
    void foo();
    int bar(double);
    char* baz(int);
    void dont_want_to_expose_this_one();
    };
    class Agreggator : private Embedee {
    public:
    using Embedee::foo;
    using Embedee::bar;
    using Embedee::baz;
    :
    };

    This saves having to write and maintain
    forwarding functions for these methods.
    Of course you can't have more than one
    Embedee in this case.
    I think one of Herb sutter's "Exceptional
    C++" books covers this btw.

    HTH
    tragomaskhalos, Sep 28, 2007
    #4
  5. puzzlecracker

    werasm Guest

    On Sep 28, 7:30 am, puzzlecracker <> wrote:
    > The statement is taken from FAQ [24.2]. What about non-virtual
    > functions? Can they be overriden? I still don't see a good
    > justification to prefer private inheritance over composition. In
    > fact, I have never seen it in a commercial code. If someone did,
    > please share the use-case and decisions behind it.
    >
    > Thanks


    Private inheritance provides a way to give selective polymorphism
    e.g. if a class only wants expose his interface to specific
    clients, not necessarily because no true isA relationship exists,
    but because selective clients may call the methods e.g.

    I provide serviceA, ..B, and ..C. I don't want clientB to make
    use of serviceA, but I nevertheless want to provide it to whom
    I dictate (I've seen an article on this but can't remember where).

    One could achieve the same by other means, but private inheritance
    makes it easier. We have an example where we have two parallel
    hierarchies (3 deep in this case, each level abstracting a
    certain responsibility). The bases in the hierarchy make use of
    template method pattern to dictate behavior in terms of
    derived classes, and they in turn have enough information to
    extend the template method (so to speak). Each of the
    classes in the hierarchy make use of services provided by
    the same class at different levels, and private inheritance
    makes this possible. I have contemplated other ways to do
    this, but decided that it is more natural to implement using
    private inheritance. Of course, template method itself could
    have been implemented using a <bridge>, if you know what I
    mean? In the above mentioned case though, things played
    out nicely using private inheritance and intent was very clear
    (IMHO).

    Regards,

    Werner
    werasm, Sep 28, 2007
    #5
  6. puzzlecracker

    werasm Guest

    On Sep 28, 7:30 am, puzzlecracker <> wrote:
    > The statement is taken from FAQ [24.2]. What about non-virtual
    > functions? Can they be overriden? I still don't see a good
    > justification to prefer private inheritance over composition. In
    > fact, I have never seen it in a commercial code. If someone did,
    > please share the use-case and decisions behind it.
    >
    > Thanks


    Private inheritance provides a way to give selective polymorphism
    e.g. if a class only wants expose his interface to specific
    clients, not necessarily because no true isA relationship exists,
    but because selective clients may call the methods e.g.

    I provide serviceA, ..B, and ..C. I don't want clientB to make
    use of serviceA, but I nevertheless want to provide it to whom
    I dictate (I've seen an article on this but can't remember where).

    One could achieve the same by other means, but private inheritance
    makes it easier. We have an example where we have two parallel
    hierarchies (3 deep in this case, each level abstracting a
    certain responsibility).

    The bases in one hierarchy make use of
    template method pattern to dictate behavior in terms of
    derived classes, and they in turn have enough information to
    extend the template method (so to speak).

    Each of the levels in one hierarchy make use of services provided by
    corresponding levels in another hierarchy, and private inheritance
    makes this possible. I have contemplated other ways to do
    this, but decided that it is more natural to implement using
    private inheritance. Of course, template method itself could
    have been implemented using a <bridge>, if you know what I
    mean? In the above mentioned case though, things played
    out nicely using private inheritance and intent was very clear
    (IMHO).

    Regards,

    Werner
    werasm, Sep 28, 2007
    #6
  7. puzzlecracker

    Howard Guest

    "werasm" <> wrote in message
    news:...
    > On Sep 28, 7:30 am, puzzlecracker <> wrote:
    >> The statement is taken from FAQ [24.2]. What about non-virtual
    >> functions? Can they be overriden? I still don't see a good
    >> justification to prefer private inheritance over composition. In
    >> fact, I have never seen it in a commercial code. If someone did,
    >> please share the use-case and decisions behind it.
    >>
    >> Thanks

    >
    > Private inheritance provides a way to give selective polymorphism
    > e.g. if a class only wants expose his interface to specific
    > clients, not necessarily because no true isA relationship exists,
    > but because selective clients may call the methods e.g.
    >
    > I provide serviceA, ..B, and ..C. I don't want clientB to make
    > use of serviceA, but I nevertheless want to provide it to whom
    > I dictate (I've seen an article on this but can't remember where).
    >
    > One could achieve the same by other means, but private inheritance
    > makes it easier. We have an example where we have two parallel
    > hierarchies (3 deep in this case, each level abstracting a
    > certain responsibility). The bases in the hierarchy make use of
    > template method pattern to dictate behavior in terms of
    > derived classes, and they in turn have enough information to
    > extend the template method (so to speak). Each of the
    > classes in the hierarchy make use of services provided by
    > the same class at different levels, and private inheritance
    > makes this possible. I have contemplated other ways to do
    > this, but decided that it is more natural to implement using
    > private inheritance. Of course, template method itself could
    > have been implemented using a <bridge>, if you know what I
    > mean? In the above mentioned case though, things played
    > out nicely using private inheritance and intent was very clear
    > (IMHO).
    >


    I find the comments above very confusing. (Does anyone else?)

    How does private inheritance allow a class to expose its interface only to
    specific clients? What does "the same class at different levels" mean?
    What's a "<bridge>"?

    Perhaps some code example might illustrate your point(s) better. I'm just
    not following.

    -Howard
    Howard, Sep 29, 2007
    #7
  8. puzzlecracker

    werasm Guest

    On Sep 29, 1:46 am, "Howard" <> wrote:
    > I find the comments above very confusing. (Does anyone else?)
    >
    > How does private inheritance allow a class to expose its interface only to
    > specific clients?


    See the example. Cmd exposes the function execute only to Processor.

    > What does "the same class at different levels" mean?
    > What's a "<bridge>"?


    Refer to bridge pattern in wikipedia.

    > Perhaps some code example might illustrate your point(s) better. I'm just
    > not following.


    Here goes:

    struct Executable
    {
    virtual void execute() = 0;
    protected:
    virtual ~Executable(){ }
    };

    struct Processor
    {
    virtual void process( Executable& );
    //...
    };

    class Cmd : Executable
    {
    public:
    Cmd( Processor* p = 0 ): p_( p ){ }
    void operator()()
    {
    if( p_ )
    {
    p_->process( *this );
    }
    else
    {
    execute();
    }
    }
    private:
    virtual void execute()
    {
    //...Some default behavior...
    // Most probably overridden
    }
    Processor* p_;
    };


    void clientFunction()
    {
    Processor p;
    Cmd cmd( &p );
    cmd(); // Processor calls execute...
    cmd.execute();//Fails to compile...
    }

    Regards,

    Werner
    werasm, Sep 29, 2007
    #8
  9. puzzlecracker

    werasm Guest

    On Sep 29, 10:32 am, werasm <> wrote:
    > Here goes:
    >
    > struct Executable
    > {
    > virtual void execute() = 0;
    > protected:
    > virtual ~Executable(){ }
    >
    > };
    >
    > struct Processor
    > {
    > virtual void process( Executable& );
    > //...
    >
    > };
    >
    > class Cmd : Executable
    > {
    > public:
    > Cmd( Processor* p = 0 ): p_( p ){ }
    > void operator()()
    > {
    > if( p_ )
    > {
    > p_->process( *this );
    > }
    > else
    > {
    > execute();
    > }
    > }
    > private:
    > virtual void execute()
    > {
    > //...Some default behavior...
    > // Most probably overridden
    > }
    > Processor* p_;
    >
    > };
    >
    > void clientFunction()
    > {
    > Processor p;
    > Cmd cmd( &p );
    > cmd(); // Processor calls execute...
    > cmd.execute();//Fails to compile...
    > }


    The purpose of this BTW, is to allow the command to be executed
    in the context (or thread) or processor when associate with it, and
    in the context of its own thread if not. It also allows you to
    bind (to derived classes of commands) arguments that get sent
    to a callback associated with classes derived from commands.

    Unfortunately I can't go the whole nine yards with explaining
    this, because the more I explain, the more questions would
    be asked, but the little example illustrates the point, I
    think.

    Regards,

    Werner

    >
    > Regards,
    >
    > Werner
    werasm, Sep 29, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. qazmlp
    Replies:
    19
    Views:
    789
    Daniel T.
    Feb 4, 2004
  2. Replies:
    7
    Views:
    299
  3. John Goche
    Replies:
    10
    Views:
    741
    Marcus Kwok
    Dec 8, 2006
  4. Nick Keighley

    can I override private functions?

    Nick Keighley, Mar 13, 2007, in forum: C++
    Replies:
    7
    Views:
    350
    Rolf Magnus
    Mar 13, 2007
  5. Chris Gordon-Smith
    Replies:
    20
    Views:
    908
    Daniel Pitts
    May 29, 2008
Loading...

Share This Page