Re: Choose between class implementations at compiletime
* James Kanze:
On Sep 11, 4:11 pm, "Alf P. Steinbach" <al...@start.no> wrote:
On Sep 11, 8:46 am, Christoph Mathys <cmat...@gmail.com> wrote:
Can you define the concrete class (e.g. Foo) in a header
file but implement N implementations of Foo in various
.cpp files that correspond to your APIs and put each in a
Yes, of course! Why didn't I think of that... Thanks for
But I must say, that can complicate your build and also your
I'd be interested in hearing how. It's the standard technique,
and I've not found it to cause any particular problems for the
build or for testing.
Using and Abstract Base Class and some sort of a factory
that returns the correct derived class at run time based on
a configuaration parameter might be easier overall in the
That's a Java technique.
It's also a C++ technique. I think what you meant to say is
that it's the only technique available in Java, so people used
to Java end up using in even in cases like this where it is
totally inappropriate. (When all you have is a hammer,
everything looks like a nail.)
In standard C++ there are no shared libraries,
In C++ as it is actually practiced, there are, and it's actually
common practice to use something like this, e.g. loading a
different look and feel for a GUI according to an environment
A better example than *nix GUI might be Windows COM object instantiation. :-)
Since you're going to work in Windows, check out CoCreateInstance & friends.
It's the factory pattern taken to the extreme, but unfortunately, while designed
primarily *for* C++, it's implemented in C style (it also supports use from C).
hence with that solution as an *alternative* to the linking,
all the code for the different systems would have to be
present, which is just not practical.
Depending on what the different versions do, the code for one
platform might not even compile on another.
Right. That's part of why it's impractical.
With a shared library the Java factory technique becomes
practically possible, but then it's most likely, depending on
the app, just a redundant layer of complication, since the
basic shared library dynamic linking does it all.
In short, transferring Java patterns uncritically to C++ isn't
a good idea.
They're two different languages, and in particular in this
case, with ordinary C++ you build a different executable for
each platform (link time selection is a good idea), while with
Java you may build a common executable for all platforms (run
time selection, implying a factory, is a good idea).
In Java, if you have code accessing specific system level API's
(e.g. the registry under Windows) which aren't addressed by the
standard library, the only solution available to you is to
create a native class, with the implementation in some other
language (like C++); in such cases, it is usual to provide
platform specific versions, each with the appropriate dynamic
object containing the native code.
Technically yes, the machine-specific things are necessarily machine-specific
and thus different, heh. I assumed that to be understood. You're forgetting that
in Java the main program can be and usually is the same on all platforms, at the
bytecode level, while with C++ it typically has hardcoded the shared library
usage, different on each platform. You *can* do about the same in C++, explitly
loading a shared library at run-time, and wasting time on writing small wrappers
or casts for invoking each relevant routine. But that won't get you a machine
code level identical executable for different systems, and unless the design is
royally screwed up it won't even make the source code more system independent,
and happily there's seldom any need to add this extra layer. :-)