# implementation hiding library

This topic is 3954 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Right now I'm writing a library that requires me to create different implementations of the same functionality for different hardware. What I ideally want to do is create a library that allows me to write a program in the same manner for each and every situation, but that automatically selects the right implementation for the hardware. Given that I can determine the specific situation I'm in (which hardware, etc.) I wonder how I could structure my library in such a way that it allows for the automatic use of the appropriate functionality. Lets assume I have a class SomeClass that I want to program with. But I have specific implemenations like SomeClassHardwareA, SomeClassHardwareB, etc. What would be a nice way to be able to work with SomeClass, while under the hood the appropriate implementation gets used. (Note that I'm not fixed to this separate class approach, it is just for illustration). And ideas for a clean solution? I have some ideas, but most of them are quite messy.

##### Share on other sites
dll?

make difrrent dlls for each type of hardware configuration and then load the appropriate dll

##### Share on other sites
sigh.......... why on earth didn't I think of that. That might be a nice solution indeed.
Thank you very much. It's just one of those- "how do I climb over the wall?" while the gate is open- kind of days.....

Any other comments/suggestions are still welcome though.

##### Share on other sites
Ive never seen a better situation in which to use Virtual Interfaces.

A virtual interface is basically a class that is all virtual, and it's subclasses actually define the different implementations. The cool thing is, you can do something like this:

VirtualInterface *VI = 0;VI = new Implementation1;orVI = new Implementation2;

Just google up some tutorials on virtual interfaces.

##### Share on other sites
Perhaps looking at the structure of wxWidgets would help, although it's a static platform abstraction layer. Also, there is the bridge design pattern that might be of interest http://en.wikipedia.org/wiki/Bridge_pattern :)

##### Share on other sites
Quote:
 Original post by Foot SoldierIve never seen a better situation in which to use Virtual Interfaces. A virtual interface is basically a class that is all virtual, and it's subclasses actually define the different implementations. The cool thing is, you can do something like this:VirtualInterface *VI = 0;VI = new Implementation1;orVI = new Implementation2;Just google up some tutorials on virtual interfaces.

And add a factory method which hides the creation of the specific implementation object away from the calling code.

##### Share on other sites
Why use an interface which forces you to virtualize all your functions when you can put the implementations of each function neatly in its own cpp and conditionally compile the cpp for the platform targeted?

##### Share on other sites
Quote:
 Original post by DrEvilWhy use an interface which forces you to virtualize all your functions when you can put the implementations of each function neatly in its own cpp and conditionally compile the cpp for the platform targeted?

Because you want to hide the implementation. An interface is just what it says, along the lines with "here is what I provide" whereas an implementation is more like "here is what I provide and also how I provide it". This is bad, especially in this case when library should not be implementation specific. Or as I learned in a design patterns course "program to an interface, not to an implementation" :)

Also, using preprocessors to conditionally compile depending on the platform is IMHO also a bad design decision as it's much like having a long switch-statement. The code becomes very cluttered very fast. It's easier to have a class for each platform dealing with its own tasks.

##### Share on other sites
Quote:
Original post by arthur83
Quote:
 Original post by DrEvilWhy use an interface which forces you to virtualize all your functions when you can put the implementations of each function neatly in its own cpp and conditionally compile the cpp for the platform targeted?

...

Also, using preprocessors to conditionally compile depending on the platform is IMHO also a bad design decision as it's much like having a long switch-statement. The code becomes very cluttered very fast. It's easier to have a class for each platform dealing with its own tasks.

I think you may have misread what he said. In my experience, this is how a cross platform library should work:

crender.cpp // common functionality shared on all platforms
crender_win32.cpp // windows specific functionality
crender_tools.cpp // tools specific functionality
crender_x360.cpp // xbox specific functioniality
crender_ps3.cpp // ps3 specific functionality
crender_ps2.cpp // ps2 specific functionality

This is very easy to manage and stays away from having to have a virtual interface. There are of course other alternatives but for me managing 6 platforms with 4 targets each, this has been the easiest and cleanest method. Not to mention that it requires no overhead from virtual calls and additional code bloat.

##### Share on other sites
Quote:
Original post by David Neubelt
Quote:
Original post by arthur83
Quote:
 Original post by DrEvilWhy use an interface which forces you to virtualize all your functions when you can put the implementations of each function neatly in its own cpp and conditionally compile the cpp for the platform targeted?

...

Also, using preprocessors to conditionally compile depending on the platform is IMHO also a bad design decision as it's much like having a long switch-statement. The code becomes very cluttered very fast. It's easier to have a class for each platform dealing with its own tasks.

I think you may have misread what he said. In my experience, this is how a cross platform library should work:

crender.cpp // common functionality shared on all platforms
crender_win32.cpp // windows specific functionality
crender_tools.cpp // tools specific functionality
crender_x360.cpp // xbox specific functioniality
crender_ps3.cpp // ps3 specific functionality
crender_ps2.cpp // ps2 specific functionality

This is very easy to manage and stays away from having to have a virtual interface. There are of course other alternatives but for me managing 6 platforms with 4 targets each, this has been the easiest and cleanest method. Not to mention that it requires no overhead from virtual calls and additional code bloat.

Exactly! That's the way I would structure it aswell. Then if a new platform is to be implemented, you just have to look at the interface and implement functionality for those methods. If you just have an implemented class for each platform without an inteface then, for each new platform you have to quess what methods to create as it is determined from the method calls. The process is much easier if you have an interface to follow. Plus you can extend the design through decorators and whatnot :)