C + + portability and cross-platform development [5]: Operating system

The previous post mentions the "hardware system" related topics, which today speak about operating systems. C + + cross-platform development and OS-related trivia is very much, so today will be long-winded more lengthy, please reader forgive:-)

In order not to bypass the mouth, the following Linux and a variety of Unix collectively referred to as the POSIX system.

★ File System (filesystem hereinafter referred to as FS)

Novice developers who have just started cross-platform development are likely to encounter FS-related problems. So let's talk about FS first. summed up, the development of an easily encountered FS differences are mainly as follows: directory separator differences, case sensitive differences, the path of disabled characters in the difference.

To deal with these differences, you should pay attention to the following points:

1, file and directory naming to specification

When naming files and directories, try to use only letters and numbers. Do not foo.cpp files in the same directory with two names similar to those in the name that differ only in case, for example, Foo.cpp. Do not use reserved words for certain OS (such as aux, con, nul, PRN) as file names or directory names.

To add, the naming that you have just said includes source code files, binaries, and other files created by the runtime.

2, #include语句要规范

When you write a #include statement, be careful to use the forward slash "/" (more generic) instead of the backslash "\" (Only available in Windows). #include语句中的文件和目录名要和实际名称保持 the exact same case.

3, the code involved in the FS operation, as far as possible to use off-the-shelf library

There are already a lot of 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 help you save a lot of things.

★ Text file's carriage return cr/to change the line LF

This annoying problem is caused by several well-known operating systems that are inconsistent with carriage return/line wrapping. The current scenario is that Windows uses both CR and Lf;linux, and most UNIX uses LF, and the Mac family of apples uses CR.

For source control, many version management software (CVS, SVN, for example) intelligently handles the problem, allowing you to retrieve local source code from the codebase to fit in the local format.

If your program needs to work with text files at run time, pay attention to the difference between open and binary mode. In addition, if you are involved in transferring text files across different systems, consider doing the appropriate processing.

★ File search path (including search executables and dynamic libraries)

Under Windows, if you want to execute a file or load a dynamic library, you typically search the current directory, and the POSIX system is not. So if your application involves starting a process or loading a dynamic library, be careful with this difference.

★ Environment Variables

For the above mentioned search path problems, some students want to modify the path and Ld_library_path to introduce the current path. If this method is used, it is recommended that you modify only process-level environment variables, and do not modify system-level environment variables (modifying system-level other software that may affect the same machine, resulting in side effects).

★ Dynamic Library

If your application uses dynamic libraries, it is highly recommended that dynamic libraries export standard C-style functions (try not to export classes). If you load a dynamic library in a POSIX system, remember to use the RTLD_GLOBAL flag bit carefully. This flag will enable the global symbol table, there may be a number of dynamic libraries between the symbol name conflict (once encountered this kind of thing, there will be strange run-time errors, very difficult to debug).

On the topic of dynamic library is relatively large, limited to space, later write a separate post discussion.

★ Service/Caretaker Process

If you are not clear about the concept of service and caretaker processes, see Wikipedia (here and here). In order to describe the convenience, hereinafter referred to as services.

Since C + + developed modules are mostly back-end modules, often encounter service problems. Writing a service requires several system-related APIs to be invoked, resulting in tight coupling with the operating system, which is difficult to handle with a single set of code. So the better approach is to abstract a generic service shell and then mount the business logic code as a dynamic library under it. In this case, at least the code that guarantees the business logic needs a set; The code for the service shell needs two sets (one for Windows, one for POSIX), but they are business-independent and can be easily reused.

★ Default Stack size

Different operating systems, the default size of the stack varies widely from dozens of KB (it is said that Symbian is only 12K, really stingy) to several MB. So you have to inquire about the default stack size of the target system, and if you run into a stingy one like Symbian, consider using the compiler option to resize it. Of course, it is also important to develop a good habit of "not defining large arrays/objects on the stack", otherwise large stacks will be blown up.