Weblogs Forum - Polymorphism without Planning

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Polymorphism without Planning

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

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

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 3:58 PM

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 9:59 AM

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 10:01 AM

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 10:21 AM

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 8:06 AM

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 8:19 AM

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 10:08 AM

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 ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use