Am I inherited?

Discussion in 'C++' started by Mike - EMAIL IGNORED, Jul 21, 2006.

  1. Within class MyClass, I can think of two ways
    to tell if MyClass is inherited in a particular
    use:

    1. pass an appropriate bool in the ctor args;

    2. use a virtual method that returns, for
    example, a siring containing the class name.

    Is there a better way?

    Thanks,
    Mike.
     
    Mike - EMAIL IGNORED, Jul 21, 2006
    #1
    1. Advertising

  2. * Mike - EMAIL IGNORED:
    > Within class MyClass, I can think of two ways
    > to tell if MyClass is inherited in a particular
    > use:
    >
    > 1. pass an appropriate bool in the ctor args;
    >
    > 2. use a virtual method that returns, for
    > example, a siring containing the class name.
    >
    > Is there a better way?


    Design the class so it doesn't need that knowledge.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Jul 21, 2006
    #2
    1. Advertising

  3. On Sat, 22 Jul 2006 00:42:59 +0200, Alf P. Steinbach wrote:

    > * Mike - EMAIL IGNORED:
    >> Within class MyClass, I can think of two ways
    >> to tell if MyClass is inherited in a particular
    >> use:
    >>
    >> 1. pass an appropriate bool in the ctor args;
    >>
    >> 2. use a virtual method that returns, for
    >> example, a siring containing the class name.
    >>
    >> Is there a better way?

    >
    > Design the class so it doesn't need that knowledge.


    That is often a good idea; but in this case, it is not.
     
    Mike - EMAIL IGNORED, Jul 22, 2006
    #3
  4. * Mike - EMAIL IGNORED:
    > On Sat, 22 Jul 2006 00:42:59 +0200, Alf P. Steinbach wrote:
    >
    >> * Mike - EMAIL IGNORED:
    >>> Within class MyClass, I can think of two ways
    >>> to tell if MyClass is inherited in a particular
    >>> use:
    >>>
    >>> 1. pass an appropriate bool in the ctor args;
    >>>
    >>> 2. use a virtual method that returns, for
    >>> example, a siring containing the class name.
    >>>
    >>> Is there a better way?

    >> Design the class so it doesn't need that knowledge.

    >
    > That is often a good idea; but in this case, it is not.


    That would be interesting, if true. However, I'm disinclined to believe
    that claim without some concrete evidence. Please post a small example
    that compiles, or where the compilation error illustrates the problem.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Jul 22, 2006
    #4
  5. On Sat, 22 Jul 2006 02:28:41 +0200, Alf P. Steinbach wrote:

    > * Mike - EMAIL IGNORED:
    >> On Sat, 22 Jul 2006 00:42:59 +0200, Alf P. Steinbach wrote:
    >>
    >>> * Mike - EMAIL IGNORED:
    >>>> Within class MyClass, I can think of two ways
    >>>> to tell if MyClass is inherited in a particular
    >>>> use:
    >>>>
    >>>> 1. pass an appropriate bool in the ctor args;
    >>>>
    >>>> 2. use a virtual method that returns, for
    >>>> example, a siring containing the class name.
    >>>>
    >>>> Is there a better way?
    >>> Design the class so it doesn't need that knowledge.

    >>
    >> That is often a good idea; but in this case, it is not.

    >
    > That would be interesting, if true. However, I'm disinclined to believe
    > that claim without some concrete evidence. Please post a small example
    > that compiles, or where the compilation error illustrates the problem.


    Off point: the question is how, not whether to do it. There is no error.
     
    Mike - EMAIL IGNORED, Jul 22, 2006
    #5
  6. * Mike - EMAIL IGNORED:
    > On Sat, 22 Jul 2006 02:28:41 +0200, Alf P. Steinbach wrote:
    >
    >> * Mike - EMAIL IGNORED:
    >>> On Sat, 22 Jul 2006 00:42:59 +0200, Alf P. Steinbach wrote:
    >>>
    >>>> * Mike - EMAIL IGNORED:
    >>>>> Within class MyClass, I can think of two ways
    >>>>> to tell if MyClass is inherited in a particular
    >>>>> use:
    >>>>>
    >>>>> 1. pass an appropriate bool in the ctor args;
    >>>>>
    >>>>> 2. use a virtual method that returns, for
    >>>>> example, a siring containing the class name.
    >>>>>
    >>>>> Is there a better way?
    >>>> Design the class so it doesn't need that knowledge.
    >>> That is often a good idea; but in this case, it is not.

    >> That would be interesting, if true. However, I'm disinclined to believe
    >> that claim without some concrete evidence. Please post a small example
    >> that compiles, or where the compilation error illustrates the problem.

    >
    > Off point: the question is how, not whether to do it. There is no error.


    I think that protest means you know your design is triple UnGood, and
    just want a quick and dirty kludge.

    Which will hopefully give an endless nightmare of problems so that you
    learn to do things properly. :)

    For now, if a virtual class name member function is one solution, as you
    have indicated, then a version of the same idea using built-in support
    is the typeid operator.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Jul 22, 2006
    #6
  7. Mike - EMAIL IGNORED

    Kai-Uwe Bux Guest

    Mike - EMAIL IGNORED wrote:

    > On Sat, 22 Jul 2006 02:28:41 +0200, Alf P. Steinbach wrote:
    >
    >> * Mike - EMAIL IGNORED:
    >>> On Sat, 22 Jul 2006 00:42:59 +0200, Alf P. Steinbach wrote:
    >>>
    >>>> * Mike - EMAIL IGNORED:
    >>>>> Within class MyClass, I can think of two ways
    >>>>> to tell if MyClass is inherited in a particular
    >>>>> use:
    >>>>>
    >>>>> 1. pass an appropriate bool in the ctor args;
    >>>>>
    >>>>> 2. use a virtual method that returns, for
    >>>>> example, a siring containing the class name.
    >>>>>
    >>>>> Is there a better way?
    >>>> Design the class so it doesn't need that knowledge.
    >>>
    >>> That is often a good idea; but in this case, it is not.

    >>
    >> That would be interesting, if true. However, I'm disinclined to believe
    >> that claim without some concrete evidence. Please post a small example
    >> that compiles, or where the compilation error illustrates the problem.

    >
    > Off point: the question is how, not whether to do it. There is no error.


    Not off at all:

    a) If we get to see your real problem, we might be able to suggest a better
    design.

    b) You should also consider the motivation we might have to provide you with
    a solution, while there is this nagging feeling that you may be chasing a
    red herring.


    Best

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Jul 22, 2006
    #7
  8. [...]
    > For now, if a virtual class name member function is one solution, as you
    > have indicated, then a version of the same idea using built-in support
    > is the typeid operator.


    I just tried typeid. It appears that it doesn't know where I
    would like to know: in the constructor.

    FYI, the situation is a hierarchy of complex mathematical
    operations, each one in its own class. Most of the classes
    can function alone or in concert with others. The sequence
    of events is controlled by ctor of the most inherited class.
    The data for all classes are mostly the same type, voluminous,
    and kept protected in a base class. Virtual inheritance is
    used. The most inherited class must recognize itself in the
    ctor. There are, of course, other designs, but this provides
    simplicity for the unsophisticated user and ease of expansion
    as other mathematical procedures and interactions are developed.
     
    Mike - EMAIL IGNORED, Jul 22, 2006
    #8
  9. Mike - EMAIL IGNORED

    Ian Collins Guest

    Mike - EMAIL IGNORED wrote:
    > [...]
    >
    >>For now, if a virtual class name member function is one solution, as you
    >>have indicated, then a version of the same idea using built-in support
    >>is the typeid operator.

    >
    >
    > I just tried typeid. It appears that it doesn't know where I
    > would like to know: in the constructor.
    >

    Then you have a bit of a problem, don't you? You can't use virtual
    methods in a constructor.

    --
    Ian Collins.
     
    Ian Collins, Jul 22, 2006
    #9
  10. Mike - EMAIL IGNORED

    Kai-Uwe Bux Guest

    Mike - EMAIL IGNORED wrote:

    > [...]
    >> For now, if a virtual class name member function is one solution, as you
    >> have indicated, then a version of the same idea using built-in support
    >> is the typeid operator.

    >
    > I just tried typeid. It appears that it doesn't know where I
    > would like to know: in the constructor.
    >


    What did you try?

    I tried:

    #include <typeinfo>

    namespace {

    template < typename B >
    B unimplemented ( void );

    }

    template < typename B >
    bool has_dynamic_type ( B const & b ) {
    return ( typeid( unimplemented<B>() ) == typeid( b ) );
    }


    #include <iostream>

    class Base {
    protected:

    Base ( void ) {
    std::cout << has_dynamic_type< Base >( *this ) << '\n';
    }

    public:

    bool is_base ( void ) const {
    return ( has_dynamic_type< Base >( *this ) );
    }

    virtual
    ~Base ( void ) {}

    static
    Base* create ( void ) {
    return new Base;
    }

    };

    struct Derived : public Base {
    protected:

    Derived ( void ) {
    std::cout << has_dynamic_type< Base >( *this ) << '\n';
    }

    public:

    static
    Derived* create ( void ) {
    return new Derived;
    }

    };


    int main ( void ) {
    Base* b_ptr = Base::create();
    Base* d_ptr = Derived::create();
    std::cout << b_ptr->is_base() << '\n';
    std::cout << d_ptr->is_base() << '\n';
    }


    a) I am not sure whether there is UB in the above.

    b) A little bit of the code complexity is because I wanted something that
    does not require default constructibilty.

    c) On my machine, the output is:

    1 // construction of *b_ptr
    1 // construction of *d_ptr Base() part
    0 // construction of *d_ptr Derived() part
    1 // b_ptr->is_base();
    0 // d_ptr->is_base();


    > FYI, the situation is a hierarchy of complex mathematical
    > operations, each one in its own class. Most of the classes
    > can function alone or in concert with others. The sequence
    > of events is controlled by ctor of the most inherited class.
    > The data for all classes are mostly the same type, voluminous,
    > and kept protected in a base class. Virtual inheritance is
    > used.


    Could you provide a little example code that demonstrates the design?


    > The most inherited class must recognize itself in the ctor.


    Note that when Base() is called, it truly constructs a Base object and
    nothing else. The constructor has no way of telling how it is invoked.

    Also, the other methods you mentioned in your first post have trouble in
    this situation:

    > 1. pass an appropriate bool in the ctor args;


    In order to pass that bool, you would need to know already, won't you?

    > 2. use a virtual method that returns, for
    > example, a siring containing the class name.


    Virtual functions are not necessarily resolved the way you like in
    constructors. I feel there might be some UB involved.


    If you classes are just wrapping operations, then maybe you can move the
    logic from the constructors to the destructors?


    [snip]


    Best

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Jul 22, 2006
    #10
  11. Mike - EMAIL IGNORED

    Bo Persson Guest

    "Mike - EMAIL IGNORED" <> skrev i meddelandet
    news:p...
    > [...]
    >> For now, if a virtual class name member function is one solution,
    >> as you
    >> have indicated, then a version of the same idea using built-in
    >> support
    >> is the typeid operator.

    >
    > I just tried typeid. It appears that it doesn't know where I
    > would like to know: in the constructor.


    If you need to know something in a constructor, that something should
    generally be a parameter to that constructor. You could add a
    protected constructor, that the subclasses can call. Then at least you
    know where that call comes from.

    But, as Alf said, in a base class you generally don't want to know
    your subclasses. They should take care of themselves.

    >
    > FYI, the situation is a hierarchy of complex mathematical
    > operations, each one in its own class. Most of the classes
    > can function alone or in concert with others. The sequence
    > of events is controlled by ctor of the most inherited class.
    > The data for all classes are mostly the same type, voluminous,
    > and kept protected in a base class. Virtual inheritance is
    > used. The most inherited class must recognize itself in the
    > ctor.


    And we all wonder why. :)

    > There are, of course, other designs,


    Right!

    > but this provides
    > simplicity for the unsophisticated user and ease of expansion
    > as other mathematical procedures and interactions are developed.


    To me it looks more like the "ease of expansion" is not at all obvious
    here, if the base class needs to know all expansions. But, what do I
    know?



    Bo Persson
     
    Bo Persson, Jul 22, 2006
    #11
  12. Mike - EMAIL IGNORED

    Guest

    Mike - EMAIL IGNORED wrote:
    > [...]
    > > For now, if a virtual class name member function is one solution, as you
    > > have indicated, then a version of the same idea using built-in support
    > > is the typeid operator.

    >
    > I just tried typeid. It appears that it doesn't know where I
    > would like to know: in the constructor.


    Well, duh. In the base class ctor, the derived ctor hasn't yet run, so
    it is
    not inherited /yet/. typeid knows that, but it isn't psychic. It can't
    tell if the
    object will ever become derived (an exception may prevent the derived
    ctor
    from completing) so it can only tell you what's certain.

    HTH,
    Michiel Salters
     
    , Jul 24, 2006
    #12
  13. On Mon, 24 Jul 2006 08:43:28 -0700, Michiel.Salters wrote:

    >
    > Mike - EMAIL IGNORED wrote:
    >> [...]
    >> > For now, if a virtual class name member function is one solution, as you
    >> > have indicated, then a version of the same idea using built-in support
    >> > is the typeid operator.

    >>
    >> I just tried typeid. It appears that it doesn't know where I
    >> would like to know: in the constructor.

    >
    > Well, duh. In the base class ctor, the derived ctor hasn't yet run, so
    > it is
    > not inherited /yet/. typeid knows that, but it isn't psychic. It can't
    > tell if the
    > object will ever become derived (an exception may prevent the derived
    > ctor
    > from completing) so it can only tell you what's certain.
    >
    > HTH,
    > Michiel Salters


    Yes, I found that out. For the same reason, option 2 in
    my original post is not possible. From all I have seen
    in these responses, it appears that option 1 in my
    original post is the way to go, which is what I have
    done.

    Thanks for your help,
    Mike.
     
    Mike - EMAIL IGNORED, Jul 24, 2006
    #13
    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. Jim Schueler
    Replies:
    2
    Views:
    450
  2. :crp:
    Replies:
    0
    Views:
    613
    :crp:
    Jan 25, 2005
  3. steven shingler
    Replies:
    0
    Views:
    346
    steven shingler
    Jul 18, 2003
  4. Jon Stranger
    Replies:
    1
    Views:
    879
    Natty Gur
    Aug 24, 2003
  5. 7stud --
    Replies:
    11
    Views:
    426
    7stud --
    Nov 9, 2007
Loading...

Share This Page