Portability and cross-platform development of C ++ [5]: Operating System

The previous post mentioned the topic related to the "Hardware System". Today I am talking about the topic related to the operating system. There are a lot of OS-related things in C ++ cross-platform development, so today it will take a long time. Please look at the list and forgive me.
Linux and UNIX are collectively referred to as POSIX systems.

★File System (FS)
Most new users who have just started cross-platform development will encounter FS-related problems. So let's talk about FS first. To sum up, the FS differences that are easily encountered during development are mainly as follows: Differences in directory delimiters, differences in Case sensitivity, and differences in disabled characters in paths.
To cope with the preceding differences, pay attention to the following points:
1. Standardized file and directory naming
When naming files and directories, try to use only letters and numbers. Do not place two files with the same name in the same directory (names are case-insensitive, such as Foo. cpp and foo. cpp. Do not use reserved words (such as AUX, Con, NUL, and PRN) of some operating systems as file names or directory names.
The name just mentioned includes the source code file, binary file, and other files created during the operation.
2,# IncludeStatement specifications
When you write# IncludeYou must use the forward slash "/" (more common) instead of the Backslash "/" (only available in Windows ).# IncludeThe file and directory names in the statement must be case-sensitive.Complete.
3. FS operations are involved in the code, and ready-made libraries should be used whenever possible
There are already many mature third-party libraries for FS (such as boost: filesystem ). If your Code involves FS operations (such as Directory Traversal), try to use these third-party libraries to save you a lot of trouble.

★Text File carriage return Cr/line feed lf
This is annoying because several well-known operating systems have inconsistent handling of carriage return/line breaks. The current situation is: Windows uses Cr and LF at the same time; Linux and most UNIX use lf; Apple's Mac series uses Cr.
For source code management, many version management software (such as CVS and SVN) intelligently handles this problem, allowing you to retrieve local source code from the code library to adapt to the local format.
If your program needs to process text files at runtime, pay attention to the differences between opening in this document and opening in binary mode. In addition, if it involves transferring text files across different systems, appropriate processing should be considered.

★File Search Path (including searching for executable files and dynamic libraries)
In Windows, if you want to execute a file or load a dynamic library, the current directory is generally searched, while the POSIX system does not. Therefore, if your application involves starting processes or loading dynamic libraries, be careful with this difference.

★Environment Variable
For the search path mentioned above, some users want to introduce the current path by modifying the path and LD_LIBRARY_PATH. If this method is used, it is recommended that you modify only the process-level environment variables instead of the system-level environment variables (modifying the system level may affect other software on the same machine, resulting in side effects ).

★Dynamic library
If your application uses a dynamic library, it is strongly recommended that the dynamic library Export Standard C-style functions (try not to export classes ). If you load a dynamic library in the POSIX system, use it with caution.Rtld_globalFlag. This flag will enable the global symbol table, which may lead to symbol name conflicts between multiple dynamic libraries (Once this happens, an incredible runtime error will occur, making debugging extremely difficult ).
The topic of the dynamic library is relatively large, limited by space. I will write a separate post for discussion later.

★Service/guard Process
If you do not know the concept of service and guard processes, see Wikipedia (here and here ). For ease of description, the following are collectively referred to as services.
　
Most modules developed by C ++ are backend modules, which often encounter service problems. Writing a service requires calling several system-related APIs, resulting in tight coupling with the operating system, making it difficult to use a set of code. Therefore, it is better to abstract a General Service shell and mount the business logic code as a dynamic library to it. In this way, at least one set of business logic code is required. Although the code of the service SHELL requires two sets (one for Windows and the other for POSIX), they are unrelated to the business, it can be easily reused.

★Default stack size
For different operating systems, the default stack size varies greatly, from dozens of KB (it is said that Symbian only has 12 kb, really tricky) to several Mb. Therefore, you need to check the default stack size of the target system in advance. If you encounter something like Symbian, you can use the compiler option to increase the size. Of course,"Do not define large arrays/large objects on the stack"The good habits are also very important, otherwise a large stack will be burst.

Some may have asked why I didn't talk about process management and multithreading? I want to know what to do later, and listen to the next decomposition.

Http://program-think.blogspot.com/2009/02/cxx-cross-platform-develop-5-os.html