The Artima Developer Community
Sponsored Link

Weblogs Forum
Polymorphism without Planning

21 replies on 2 pages. Most recent reply: Feb 9, 2005 1:08 PM by Christopher Diggins

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 21 replies on 2 pages [ « | 1 2 ]
Jonathan Turkanis

Posts: 3
Nickname: jdt
Registered: Nov, 2004

Re: Polymorphism without Planning Posted: Nov 29, 2004 6:58 PM
Reply to this message Reply
Advertisement
Hi,

I've written a fairly detailed overview of Boost.Interfaces for the Boost Wiki:

http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Interfaces

Best Regards,
Jonathan Turkanis

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Polymorphism without Planning Posted: Nov 30, 2004 12:59 PM
Reply to this message Reply
Does this solve the same problem as the Adapter pattern? If that's the goal, it seems like simply using the Adapter pattern may require more typing, but might also create easier to understand code. Or does this technique have other applications?

By the way, maybe I misunderstand what's being done/created by the macros, but the final code snippet inside main() didn't quite make sense to me. Maybe it is pseudocode? If these classes don't overload the assignment operator, what's "i = f;" or "i = b;" doing? I thought the usage code would look something like this:

void UseIFuBar( IFuBar & i )
{
i.Bar(i.Fu());
}

int main
{
Faz f;
Baz b;
UseIFuBar(f);
UseIFuBar(b);
}

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Polymorphism without Planning Posted: Nov 30, 2004 1:01 PM
Reply to this message Reply
Oops! That should be main(), with parans of course. (I don't know how that got through the Artima "Preview" preprocessor as well as the "Post Message" compiler!)

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Polymorphism without Planning Posted: Nov 30, 2004 1:21 PM
Reply to this message Reply
It's not psuedo-code, it's template metaprogramming pre-processor black magic ;-)

I explain the techique in more depth at CodeProject.com in the article http://www.codeproject.com/cpp/retrofitpolymorphism2.asp

There are many far reaching implications of the technique, somer are outlined at: http://tinyurl.com/4s84a

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Polymorphism without Planning Posted: Dec 1, 2004 11:06 AM
Reply to this message Reply
Sidenote: anyone know what the status is of the concept checking stuff that Stroustrup wrote about last year?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Polymorphism without Planning Posted: Feb 3, 2005 11:19 AM
Reply to this message Reply
Although this technique is useful for retro-fitting and for aspect-oriented programming, it certainly does not practically help in reducing the memory footprint of an application. The reason is simple: polymorphic objects usually live on the heap. The presented example is the most trivial case using stack objects.

If I want to have, let's say, 40 polymorphic objects stored in a collection using interface references, there is exactly no difference in the memory usage: it may be that 4 bytes are spared from the 40 objects, but I have another 40 interface reference objects with 4 bytes each that reference the original 40 objects.

Another point is that when I use interface reference types, I break the contract between the classes: another programmer, unaware of needing to use a specific class through interface references, might come along and use the non-polymorphic classes without interface references, and thus break the interface contract. This is a serious problem, especially in large programs.

Then there is also the problem of maintaining the interfaces: when a method that is part of an interface changes changes in some class, then there are some big problems:

1) the interfaces need to be maintained.
2) if the changed method is overloaded, the compiler would happily accept the overloaded method, possibly introducing subtle bugs. The problem is even bigger if the interface itself has overloaded methods.

Finally, a compiler might optimize vtables better than interface references (I am not sure about that, though).

So, from a software engineering point of view, using interface references is bad: if there is an interface, then it must be obeyed by all subscribers at all times. When the interface changes, it must automatically be reflected to all subscribers to the interface. Since there is practically no memory benefit and certainly no execution speed benefit, BIL sounds like a software engineering method that is asking for trouble.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Polymorphism without Planning Posted: Feb 9, 2005 1:08 PM
Reply to this message Reply
> If I want to have, let's say, 40 polymorphic objects
> stored in a collection using interface references, there
> is exactly no difference in the memory usage: it may be
> that 4 bytes are spared from the 40 objects, but I have
> another 40 interface reference objects with 4 bytes each
> that reference the original 40 objects.

Even if allocated on the heap you don't *have* to store them as interface references, in fact that would be naive if they are all of the same type.

> Another point is that when I use interface reference
> types, I break the contract between the classes: another
> programmer, unaware of needing to use a specific class
> through interface references, might come along and use the
> non-polymorphic classes without interface references, and
> thus break the interface contract. This is a serious
> problem, especially in large programs.

What are you talking about? This doesn't make any sense!

> Then there is also the problem of maintaining the
> interfaces: when a method that is part of an interface
> changes changes in some class, then there are some big
> problems:
>
> 1) the interfaces need to be maintained.

This is no different than any other polymorphic system, e.g. abstract base classes.

> 2) if the changed method is overloaded, the compiler would
> happily accept the overloaded method, possibly introducing
> subtle bugs. The problem is even bigger if the interface
> itself has overloaded methods.

Overloading is always a danger, no more so with interfaces than otherwise.

> Finally, a compiler might optimize vtables better than
> interface references (I am not sure about that, though).

They do, but interfaces are still more efficient because intra-class calls are non-virtual and can be inlined.

> So, from a software engineering point of view, using
> interface references is bad:

Your logic for arriving at this conclusion is faulty.

Please take a look at http://www.kangaroologic.com/interfaces for more information on interfaces.

Flat View: This topic has 21 replies on 2 pages [ « | 1  2 ]
Topic: How to think like a Jinition Previous Topic   Next Topic Topic: Announcing Head First Design Patterns


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us