Re: Alternatives to using virtuals for cross-platform development
Me wrote:
On Thu, 07 Jun 2007 14:38:47 -0700, Noone wrote:
Now that I've presented my case, a couple of questions :
1. Am I just being silly? Should I just use virtuals and be done with
it? I know when the performance impact of virtual functions has been
discussed in the past, the advice often is 'profile it and make a
decision based on the results'. The thing is, I'm still at the design
process and hence have nothing to profile. also, I would expect that
there is at least some variation between OSs/compilers. What if it
performs great on 3 out of 4 platforms? I would be locked in with that
design.
2. Am I trying to use C++ in a way that it was not designed to be used?
For example, C# and Java have the concept of a module (or package or
assembly or whatever) that is a monilithic unit that exposes some types
and interfaces. C++'s answer to this would be a pure virtual class.
3. Is there a 'standard' approach to cross-platform developement that
I've completely missed?
There is something that rubs me the wrong way about trying to include OS
specific code for multiple OSs in a single executable, and to be honest, I
don't think it will work well, if at all. Different OS means different
support libraries and probably different startup and linkage mechanisms.
Take the
example of windoze vs linux executable. Even a simple dosbox application
that
tries to run natively (intelligently) in linux and determines which OS is
active at runtime is gonna have real problems because IIRC the startup for
the executables is different even if they use the same native CPU.
Stick with separate compile builds for each OS and you'll be much happier
in the long run. KISS: keep it simple, stupid. :^)
I do something similar to what you mention with virtual base classes all
the time but it is from the opposite direction. I have an operator
control unit application for unmanned vehicles. I must support a variety
of human interface devices that have differing physical interfaces,
protocols, etc. I create an inteface base class with virtuals, then
implement the HW specific functions in subclasses and use try/catch blocks
to create the HID object for the first one in which the constructor
doesn't fail. This works extremely well and allows me to add any number
of different human interface devices: keyboards, touchscreens, joysticks,
whatever.
They are not necessarily in the same executable, only in the same
code-set. And if he is specializing on different versions of the same
OS, and especially if the set of OS-specific facets he's modeling is
small, I don't think having them in the same code-set is a problem. As
an example of handling different version of an OS, and as an extension
to my previous post, this (tested):
#include <iostream>
using namespace std;
enum { OS_A, OS_B_V2, OS_B_V2_1 };
const int OS = OS_B_V2_1;
template<int> class OSClass;
// Not used, not present in the executable
template<> class OSClass<OS_A> {
public: void Bar() { cout << "osA.Bar()" << endl; }
public: void OSFunc() { /* some OS_A-specific interface */ }
private: //store some OS_A specific data
};
template<> class OSClass<OS_B_V2> {
public: void Bar() { cout << "osBv2.Bar()" << endl; }
public: void OSFunc() { /* some OS_B_V2-specific interface */ }
private: //store some OS_B_V2 specific data
};
template<> class OSClass<OS_B_V2_1> {
typedef OSClass<OS_B_V2> osv2_t;
public:
void Bar() {
m_osv2.Bar();
cout << "osBv2_1.Bar()" << endl;
}
public: void OSFunc() { /* some OS_B_V2.1-specific interface */ }
private: //store some OS_B_V2.1 specific data
osv2_t m_osv2; // Use OS_B version 2 stuff in secret.
};
// Application code
int main (void)
{
OSClass<OS> os;
os.Bar();
}