I'm looking for the best solution to write cross-platform software, aka code that I write and that I have to interface with different libraries and platforms each time.
What I consider the easiest part, correct me if I'm wrong, is the definition of new types, all I have to do is to write an hpp file with a list of typedefs, I can keep the same names for each new type across the different platforms so my codebase can be shared without any problem. typedefs also helps me to redefine a better scope for my types in my code.
I will probably end up having something like this:
include
|-windows
| |-types.hpp
|-linux
| |-types.hpp
|-mac
|-types.hpp
For the interfaces I'm thinking about the same solution used for the types, a series of hpp files, probably I will write all the interfaces only once since they rely on the types and all "cross-platform portability" is ensured by the work done on the types.
include
|
|-interfaces.hpp
|
|-windows
| |-types.hpp
|-linux
| |-types.hpp
|-mac
| |-types.hpp
For classes and methods I do not have a real answer, I would like to avoid 2 things:
- the explicit use of pointers
- the use of templates
I want to avoid the use of the pointers because they can make the code less readable for someone and I want to avoid templates just because if I write them, I can't separate the interface from the definition.
What is the best option to hide the use of the pointers?
I would also like some words about macros and how to implement some OS-specifics calls and definitions.
Best Answer
The easiest way to think about cross-platform programming is that you need a strategy for dealing with changes in the behaviour of the program's environment, across space (i.e. different hardware architectures and operating systems) and time (i.e. different versions of an operating system with new features and different bugs). There already is a pattern for implementing strategies.
You can imagine defining a polymorphic type with member functions that define the "logic" of what you're trying to do. These member functions call abstract member functions that are responsible for entertaining the underlying platform's needs. Clients call a factory method to get an instance of your class: the factory method chooses what concrete implementation to return based on the details of the platform.
This approach results in a public interface with no templates and (with the information I know about the problem) no explicit pointer use. Clients just call a factory method and then use the public interface on your virtual base class. It also completely hides all of the complexity you want to introduce regarding headers and their locations - your clients just include the headers for your virtual types.