CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 24 of 24
  1. #16
    Join Date
    Jan 2007
    Posts
    491

    Re: Diamond Inheritance Problem - C#

    Well, .NET certainly don't support multiple inheritance, but by using a wrapper class you can solve the problem:
    Code:
    class AllRounderWrapper : Bowler
    {
            class AllRounderInsider : Batsman
           {
           }
    }
    Altought it's recommended to use interfaces instead.
    And besides, I can't see why what you're doing is good for. Maybe the upsidedown proccess will be useful: derive from Batsman & Bowler from a base class, as you acually already did in the code above.

  2. #17
    Join Date
    Apr 2006
    Posts
    220

    Re: Diamond Inheritance Problem - C#

    Quote Originally Posted by TheCPUWizard
    This is one of the biggest pitfalls in going from one language to a comletely different one that has similar (but distinctly different) usage.

    There is alot of very good C++ code, that you can copy over to C# and it will compile and run. However it will be very bad code.

    When I train people in .NET I avoid this by always training C++ programmers in VB.NET and VB 6.0 programmers in C#. This helps break the habits of the old language.

    Consider the following:
    Code:
    class MyClass
    {
         public MyClass(int x) { m_x = x}
         ~MyClass() {}
         public int Calc(int y) { return m_x = y; }
         private int m_x;
    }
    There is a MAJOR flaw in this class that will cripple system performance (slowing it down by up to a factor of 10!). However I see exactly this type of construct in code written by people that learn C++.

    I strongly recommend that you make a concerted attempt to FORGET (or at least IGNORE) EVERYTHING you know about C++. Get a good C# book and start from scratch just as if you have never programmed before.

    The primary reason (in my professional experience as a consultant) that many .NET applications have poor performance is directly attributable to developers bringing over patterns and practices that served them well in their previous environment, but have absolutely no place in .NET
    What design flaw you are talking about exactly ?

  3. #18
    Join Date
    Mar 2002
    Location
    St. Petersburg, Florida, USA
    Posts
    12,125

    Re: [RESOLVED] Diamond Inheritance Problem - C#

    The empty destructor.

    This will cause the object to be processed through the Garbage Collector, and can slow down performance the the application by a factor of over 1000! (e.g. 10 Seconds rather than 0.01 sections. )
    TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!)
    2008, 2009,2010
    In theory, there is no difference between theory and practice; in practice there is.

    * Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
    * How NOT to post a question here
    * Of course you read this carefully before you posted
    * Need homework help? Read this first

  4. #19
    Join Date
    Jul 2008
    Posts
    8

    Re: [RESOLVED] Diamond Inheritance Problem - C#

    Quote Originally Posted by TheCPUWizard
    The empty destructor.

    This will cause the object to be processed through the Garbage Collector, and can slow down performance the the application by a factor of over 1000! (e.g. 10 Seconds rather than 0.01 sections. )
    Can you please elaborate on this one?

  5. #20
    Join Date
    May 2007
    Posts
    1,546

    Re: [RESOLVED] Diamond Inheritance Problem - C#

    I assume he means in the absolute worst case scenario when you are creating 1000's of objects a second all of which have empty destructors. I've no interest in even attempting to benchmark that scenario though
    www.monotorrent.com For all your .NET bittorrent needs

    NOTE: My code snippets are just snippets. They demonstrate an idea which can be adapted by you to solve your problem. They are not 100% complete and fully functional solutions equipped with error handling.

  6. #21
    Join Date
    Jul 2008
    Posts
    8

    Resolved Re: [RESOLVED] Diamond Inheritance Problem - C#

    My bad... I read it wrongly... I was reading it as if it was a constructor.. rather than reading it correctly as a destructor..

    Yup now I get the point ! and yeah I agree too... coz C++ gave the responsibility of doing memory cleanup to the programmer himself, an empty destructor prolly didnt make much of a deal, but since Java and C# have their own garbage collectors, I guess it does add an overhead on the part of the garbage collector to call the destructors of all the objects...

    Question cleared....

  7. #22
    Join Date
    Mar 2002
    Location
    St. Petersburg, Florida, USA
    Posts
    12,125

    Re: [RESOLVED] Diamond Inheritance Problem - C#

    Quote Originally Posted by Mutant_Fruit
    I assume he means in the absolute worst case scenario when you are creating 1000's of objects a second all of which have empty destructors. I've no interest in even attempting to benchmark that scenario though
    Actually over 38K per second, dropping to 1.5K with a finalizer.

    Also remember that every LIVE object takes GC resources. DEAD objects do not. Therefore if can be faster to create/destory thousands of objects then it is to keep references to a few hundred.

    This contradicts many (good) C++ designs where items are cached that will be (or even might be) used later.

    Even a "null" member of a class can induce performance (time) overhead.

    I consulted on a graphics analysis program about a year ago where the performance was far below expectations [22 seconds to run one analysis]. A quick analysis showed that over 30% of the time was spent in garbage collection.

    Refstructuring the code so that objects were created/used/abandoned as quick as possible, and that no extranious reference variables were in existance reduced the GC time to under 2% of the application time. The total time per analysis was reduced to just over 9 seconds.
    TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!)
    2008, 2009,2010
    In theory, there is no difference between theory and practice; in practice there is.

    * Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
    * How NOT to post a question here
    * Of course you read this carefully before you posted
    * Need homework help? Read this first

  8. #23
    Join Date
    Mar 2013
    Posts
    1

    Re: [RESOLVED] Diamond Inheritance Problem - C#

    we can use interface to solve diamond problem .

    interface player
    {
    void testplayer();

    }
    interface batsman : player
    {
    void testbatsman();

    }
    interface bowler : player
    {
    void testbowler();

    }
    interface allrounder : batsman, bowler
    {
    void testallrounder();

    }
    public class sachin : allrounder
    {

    void player.testplayer()
    {
    Console.WriteLine("test player");
    }
    void batsman.testbatsman()
    {
    Console.WriteLine("test batsman");
    }

    void bowler.testbowler()
    {
    Console.WriteLine("test bowler");
    }

    void allrounder.testallrounder()
    {
    Console.WriteLine("test allrownder");
    }

    }

    the interface can inherit more than two interface and class can inherit the interface which inherit more than two class . obviously you problem solved. some thing like above code .

  9. #24
    Join Date
    Jan 2010
    Posts
    1,133

    Re: [RESOLVED] Diamond Inheritance Problem - C#

    @gunasekaranmca: This thread is from 2008 - it is generally not encouraged to revive old threads; but, since you did, and I didn't notice and made a sample demo project (...), I think it might be helpful to you and others who might be searching the forums if I post it.

    About the original question: To clarify things, the main thing people don't understand when it comes to the diamond inheritance in C# is how to avoid writing duplicate code, if they need to have implementations of classes on every level of the hierarchy. The answer is rather simple - encapsulate the common behaviors (or implementations) into another class, and use composition. IIRC, it was in the Go4 book that they said "composition is a flexible alternative for inheritance".

    This is entirely a design question - C#'s restriction to single implementation inheritance is precisely imposed to avoid various problems and bugs associated with multiple inheritance - diamond problem among them. However, since it allows multiple interface inheritance, it is possible to create a diamond-shaped inheritance ("is-a") hierarchy in C#; furthermore, the classical diamond problem ("which implementation should be inherited") is non-existent here.

    Forget about C# interface types for the moment. As you probably know, the in language-independent context, in OOP the term "(public) interface" simply denotes the set of all public members of a type, which other types can use when they need to interact. Now, C# interface type, aside from defining a new type, represents a contract of sorts, with respect to anything that implements it. A class which implements an interface is simply saying: "I hereby declare that I will provide implementations of such and such public methods, properties, etc..." (to put it that way). These implementations can come from wherever - the interface type doesn't care.

    So, they can come from other objects. In OOP, classes and objects can be used to represent anything - not just some real world thing with various attributes; they can represent imaginary concepts, constructs purely designed for programming-tasks, they can even represent behaviors (which can then be dynamically replaced), and so on. An implementation class can represent a part of the implementation of some other class, and an instance of the implementation class can then be composed into another object to provide that implementation. This also means that it can be shared (the implementation, not the object itself, although that's also possible), so code duplication is avoided.

    It may all sound complicated, but it really isn't, as you'll see from the sample attached.

    Essentially, in the sample, there are four interfaces: A, B, C, D (for this particular occasion, I temporarily abandoned the usual "I" prefix for interfaces, since IA, IB, etc... might be somewhat distracting and harder to read).

    To form the diamond shaped hierarchy, B and C inherit A, and then D inherits B and C. Then for classes implement these iterfaces - ConcreteA, ConcreteB, ConcreteC and ConcreteD. The implementation for, say, A, is extracted and encapsulated into another class, called AImpl, an instance of which is then referenced from all other classes. This way, the implementation for A is written only once. Similar approach is used for B and C. Some comments in the example provide additional explanations. It's a VS2010 project (console app).
    Attached Files Attached Files

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured