Considerations for cross-platform C, C + + code

In our development, the demand for cross-platform is more and more strong, how to keep C + + code can be compiled on multiple platforms, is a more worthy of research issues. There are a lot of cross-platform articles on the web, and there are many cross-platform libraries online. So I talk about my experiences from my own cross-platform development experience. Hope for everyone can play a certain role.

Mainly related to Windows and Linux two operating systems.
1. Questions about path and header file path separators
In Windows, both forward slashes and backslashes are available. But in Linux, it can only be/.
In Windows, path capitalization and lowercase do not matter, and uppercase and lowercase are strictly distinguished in Linux.
2. Char problem
Assume that you consider cross-platform. It is necessary to understand that the designation is signed or unsigned, because the direct declaration of char on different platforms can lead to signed or unsigned uncertainties.
3, about the wide character problem.

In Windows. wchar_t accounts for two bytes and four bytes in Linux, but can specify two bytes in Linux. This also creates the problem that some third-party libraries may only specify four bytes of wchar_t. This can lead to incompatibilities.
4, Linux there is no stricmp function, the following linux is a strcasecmp function comparison string.
5, platform-related calls as far as possible to use macros isolated. Typically, different folders represent different platforms. BOOST, Ogre, and so on, can also be in a class or file, which leads to the definition of the operating system and compiler-related macros everywhere.
6, about the header file including
The header files for some C standard libraries under Windows do not have to be explicitly included, but they need to be explicitly included under Linux. Therefore, in the. C and. cpp files, try to include the header files that are required in this file.
7. Notice the difference between the large tail end and the small tail end of the machine
The end of the size has a very large impact on the read and write of the file. To write a cross-platform C + + program. The end of the size is an issue that must be considered. Example. You write a file on the big tail machine and read it on a small tail machine. So the result must be wrong, so when we design the file format, we need to specify whether the file is large end storage or small end storage. Or a file that specifies that certain parts of the big tail end are small tails.

8. Try to use only the functions or classes that the STL has seen earlier
Earlier things are relatively stable, and STL implementations will basically be implemented so that multiple platforms can be compatible across platforms.
9, when using std::exception need to pay attention to. Under Linux, it is not supported to throw exceptions, assuming that the exception class that inherits from the standard library writes its own exception class, under Linux. The destructor of the subclass needs to indicate that no exception is thrown. So the destructor is followed by a throw () to be able.

10. When inheriting template classes. Need to be cautious
In your own code, you need to inherit the template class. Suppose you need to access the member functions or member variables of the base class template class, preceded by This->.

In addition, constructors need to be constructed using a base class. The type of the base class needs to be initialized with the type parameters of the class. Otherwise, you will be prompted to find the name of the base class under Linux.
11, try to use standard C and C + + functions and STL. Use the type defined in the C language.
12. The problem that the header file includes repeatedly
As far as possible to protect the macro to achieve the prevention of the head file repeatedly included, very much code in Windows directly with #pragma once, which does not guarantee cross-platform needs.
13, about the structure of the alignment problem.

The CPU is designed to simplify the processing between memory and CPU and to speed up the CPU's fetching of data from memory. Tend to do a certain amount of alignment, that is, the structure of the individual members are not compact storage, often in the middle of the member to fill some bytes. Therefore, we generally do not recommend to use the structure to read and write data directly, so that the different systems or computers in the migration, there will be incorrect results.
14. Note The trap of BOM (byte order mark)
Suppose you create a source file in Windows with Notepad. Then Windows will add a BOM tag to the front of the file. The so-called byte order mark, this source code does not have the problem under Windows, but compiles under the Linux only, therefore needs to use the other text editor or directly in the VS inside creates the source file.

Linux under gcc/g++ does not recognize the source file with the BOM tag.
15. Note that when calling a function, the type of the form and the function declaration do not match the types of the list. This refers to whether there is a const or if it is a reference parameter. There is no problem with the CL compiler under Windows, and Linux gcc/g++ will error.
16. Note that two angle brackets should not be written in an attached. For example, std::vector<std::vector<int>> VEC; it's all right to write under Windows, so Linux is just a compilation, so Linux can leave a space between two consecutive angle brackets. namely std::vector<std::vector<int> > VEC;



In fact. These are just the tip of the iceberg. There are many other explorations that need to be made on cross-platform/C + + development.

Considerations for cross-platform C, C + + code