Relationship between multiple diamonds

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Immortal Nephi

    Relationship between multiple diamonds

    You may have heard diamond shape. You create one base class. One
    base class has member functions and member variables. You create two
    derived classes. All member functions and member variables from one
    base class are inherited into two derived classes.

    You want both derived classes to share member variables of the one
    base class. You can do this way so you don't need keyword -- friend.
    You can add virtual public One_Base_Class on both derived classes.
    You need to create fourth derived class. Fourth derived class is
    derived from both (two) derived classes. All four classes look like
    diamond shape. It does the same what IOS looks like.

    What happen if you want multiple diamonds? You can create two
    diamonds. Then another class is dervied from both diamonds. You do
    too many derived classes as long as more diamonds are related together
    and very complex.

    Finally, the last bottom class is derived from multiple diamond
    classes. All member functions and member variables from the top base
    class are inherited down to the last bottom class through multiple
    diamonds.

    What happen to a large vtable in the bottom class?. A large vtable
    contains hundreds or thousands of member functions and hundreds of
    member variables. You may want to define one pointer to member
    function variable. Then pointer to member function variable can be
    called to access thousands of member functions.

    According to my test, only single pointer to member function variable
    with thousands of member functions are much faster than sub-member
    functions. Let's say that each main member functions (total 256 main
    member functions) have 16 sub-member functions. Combined with main
    member functions and sub-member functions are slow because it requires
    extra overhead CPU time. Only single main member functons (total
    4,096 main member functions) are faster.

    Please let me know what you think about multiple diamonds. You know
    what my writing means, but I do not need to provide sample source
    code. It is easier to understand my post.

    Nephi
  • Salt_Peter

    #2
    Re: Relationship between multiple diamonds

    On Nov 6, 9:59 pm, Immortal Nephi <Immortal_Ne... @hotmail.comwro te:
    You may have heard diamond shape. You create one base class. One
    base class has member functions and member variables. You create two
    derived classes. All member functions and member variables from one
    base class are inherited into two derived classes.
    >
    You want both derived classes to share member variables of the one
    base class. You can do this way so you don't need keyword -- friend.
    You can add virtual public One_Base_Class on both derived classes.
    You need to create fourth derived class. Fourth derived class is
    derived from both (two) derived classes. All four classes look like
    diamond shape. It does the same what IOS looks like.
    >
    What happen if you want multiple diamonds? You can create two
    diamonds. Then another class is dervied from both diamonds. You do
    too many derived classes as long as more diamonds are related together
    and very complex.
    >
    Finally, the last bottom class is derived from multiple diamond
    classes. All member functions and member variables from the top base
    class are inherited down to the last bottom class through multiple
    diamonds.
    >
    What happen to a large vtable in the bottom class?. A large vtable
    contains hundreds or thousands of member functions and hundreds of
    member variables. You may want to define one pointer to member
    function variable. Then pointer to member function variable can be
    called to access thousands of member functions.
    >
    According to my test, only single pointer to member function variable
    with thousands of member functions are much faster than sub-member
    functions. Let's say that each main member functions (total 256 main
    member functions) have 16 sub-member functions. Combined with main
    member functions and sub-member functions are slow because it requires
    extra overhead CPU time. Only single main member functons (total
    4,096 main member functions) are faster.
    >
    Please let me know what you think about multiple diamonds. You know
    what my writing means, but I do not need to provide sample source
    code. It is easier to understand my post.
    >
    Nephi
    I fail to see your point. A diamond shaped inheritance scheme like

    istream
    / \
    ios_base - ios iostream
    \ /
    ostream

    fits the bill since istream and ostream provide facilities to other
    sections of the hierarchy (ifstream, istringstream and ofstream,
    ostringstream respectively), iostream is but one of them. You describe
    a design where the various corners of the diamonds are meant to serve
    nothing but the final derived class.

    A class with 256 member functions is grossly overburdened. And you
    suggested 4096 member functions? If speed is such a concern, why store
    pointers to member functions in the first place? Are you using
    inheritance where you should be using composition?

    The main reason why one should use inheritance hierarchies is for
    reusability, maintainability and flexibility. Keep it simple. If your
    idea is to write a complex program with 100K lines using one class and
    4096 functions, then do it at your own peril. If thats your idea of
    gaining speed, then i'll counter with 'buggy programs' don't run very
    well at all. Without classes you lose type-checking. A few weeks after
    you implement the design you'll find you can't even maintain it let
    alone explain it. You'll do one tiny modification and the ship sinks.
    You'll need 20 days instead of 20 minutes to add a tiny feature.
    Customers don't like that.

    Comment

    • Immortal Nephi

      #3
      Re: Relationship between multiple diamonds

      On Nov 7, 1:51 am, Salt_Peter <pj_h...@yahoo. comwrote:
      On Nov 6, 9:59 pm, Immortal Nephi <Immortal_Ne... @hotmail.comwro te:
      >
      >
      >
      >
      >
      You may have heard diamond shape.  You create one base class.  One
      base class has member functions and member variables.  You create two
      derived classes.  All member functions and member variables from one
      base class are inherited into two derived classes.
      >
      You want both derived classes to share member variables of the one
      base class.  You can do this way so you don't need keyword -- friend.
      You can add virtual public One_Base_Class on both derived classes.
      You need to create fourth derived class.  Fourth derived class is
      derived from both (two) derived classes.  All four classes look like
      diamond shape.  It does the same what IOS looks like.
      >
      What happen if you want multiple diamonds?  You can create two
      diamonds.  Then another class is dervied from both diamonds.  You do
      too many derived classes as long as more diamonds are related together
      and very complex.
      >
      Finally, the last bottom class is derived from multiple diamond
      classes.  All member functions and member variables from the top base
      class are inherited down to the last bottom class through multiple
      diamonds.
      >
      What happen to a large vtable in the bottom class?.  A large vtable
      contains hundreds or thousands of member functions and hundreds of
      member variables.  You may want to define one pointer to member
      function variable.  Then pointer to member function variable can be
      called to access thousands of member functions.
      >
      According to my test, only single pointer to member function variable
      with thousands of member functions are much faster than sub-member
      functions.  Let's say that each main member functions (total 256 main
      member functions) have 16 sub-member functions.  Combined with main
      member functions and sub-member functions are slow because it requires
      extra overhead CPU time.  Only single main member functons (total
      4,096 main member functions) are faster.
      >
      Please let me know what you think about multiple diamonds.  You know
      what my writing means, but I do not need to provide sample source
      code.  It is easier to understand my post.
      >
      Nephi
      >
      I fail to see your point. A diamond shaped inheritance scheme like
      >
                       istream
                     /         \
      ios_base - ios             iostream
                     \         /
                       ostream
      >
      You are right. I guess that you understand.
      fits the bill since istream and ostream provide facilities to other
      sections of the hierarchy (ifstream, istringstream and ofstream,
      ostringstream respectively), iostream is but one of them. You describe
      a design where the various corners of the diamonds are meant to serve
      nothing but the final derived class.
      Let me show you an example of multiple diamonds scheme. You will see
      more than two inheritance.

      A E M Q
      / \ / \ / \ / \
      B C F G N O R S
      \ / \ / \ / \ /
      D H P T
      \ / \ /
      \ / \ /
      \ / \ /
      I U
      / \ / \
      J K V W
      \ / \ /
      L X
      \ /
      \ /
      \ /
      \ /
      \ /
      \ /
      \ /
      Y

      If you add virtual to each derived class like this "virtutal public
      A...Y" You will be able to share and modify member variables in base
      class when you invoke to call derived class' member function.
      A class with 256 member functions is grossly overburdened. And you
      suggested 4096 member functions? If speed is such a concern, why store
      pointers to member functions in the first place? Are you using
      inheritance where you should be using composition?
      No, it is not composition. I talk about multiple diamond
      inheritance. You always define "pointer to member function" variable
      in the bottom of derived "class Y". You can see that each derived
      class inherits member functions down to the bottom from the top. Each
      derived class can have 10-100 member functions.

      You can see that class Y receives all member functions from all
      derived classes through inheritance. You can invoke to call pointer
      to member function variable in the class Y before member function in
      one of these derived class is in turn to be called.

      You can have 4,096 or 32,768 or more member functions when your
      project is getting too large. Each member function's memory address
      is stored in a large vtable pointer.
      The main reason why one should use inheritance hierarchies is for
      reusability, maintainability and flexibility. Keep it simple. If your
      idea is to write a complex program with 100K lines using one class and
      4096 functions, then do it at your own peril. If thats your idea of
      gaining speed, then i'll counter with 'buggy programs' don't run very
      well at all. Without classes you lose type-checking. A few weeks after
      you implement the design you'll find you can't even maintain it let
      alone explain it. You'll do one tiny modification and the ship sinks.
      You'll need 20 days instead of 20 minutes to add a tiny feature.
      Customers don't like that.- Hide quoted text -
      You are referring global variables and global functions, but you can
      still use class when you declare static to both member variables and
      member functions. You don't need type-checking unless your source
      code is very simple when your writing code is very careful to be
      tested without bugs.

      You add too many derived classes. They gain more pounds. The ship is
      too heavy with tons of derived classes before it sinks because of
      overweight. How can you do maintainability ?

      Nephi

      Comment

      Working...