Key points for writing a portable C + + program (12 articles)

1. Layered design, isolate the platform-related code. Just like testability, portability needs to be grabbed from the design. In general, the top and bottom layers are not well-portable. The top level is the GUI, and most of the GUIs are not cross-platform, such as the WIN32 SDK and MFC. The bottom layer is the operating system API, and most of the operating system APIs are dedicated.

If these two layers of code are scattered throughout the software, then the usability of the software will be very poor, it is self-evident. So how to avoid this situation? Layered design, of course:

At the bottom of the adapter mode, the APIs of different operating systems are encapsulated into a unified set of interfaces. As for encapsulation into a class or package into a function, depends on whether you use C or C + + written program. This looks simple, not really (as you'll see after reading the whole article), it will take you a lot of time to write code to test them. Using the existing library is a good idea, there are many such libraries, such as the C library has glib (Gnome's basic Class), C + + library has ace (ADAPTIVE communication environment), etc., in the development of the first platform to use these libraries, Can greatly reduce the workload of the transplant.

The top layer uses the MVC model, separating the interface representation from the internal logic code. Put most of the code inside the internal logic, the interface is only to display and receive input, even if you want to change a GUI, the workload is not big. It is also one of the ways to improve testability, and of course there are some additional benefits. So even if you use a cross-platform GUI design software interface such as QT or GTK +, separating the interface and internal logic is also very useful.

If the above two points, the portability of the program is basically guaranteed, the other is only technical details of the problem.

2. Prior familiarity with the target platform, reasonable abstraction of the underlying functions. This is based on layered design, most of the underlying functions, such as threading, synchronization mechanism and IPC mechanism, and so on, the functions provided by different platforms, almost one by one corresponding, encapsulation of these functions is very simple, to achieve adapter work is almost only physical activity. However, for some of the more special applications, the shape component itself, take GTK +, based on the function of X window and based on the function of the Win32, the difference is huge, in addition to Windows, events and other basic concepts, almost nothing the same, if not in advance to understand the characteristics of each platform, In the design of the careful consideration, the abstraction of the extraction in another platform is almost impossible to achieve.

3. Use the standard C + + function as much as possible. Most platforms implement the functions specified by the POSIX (portable Operating System Interface), but these functions may be more performance-based than native (Native) functions, and are not as easy to use as primitive functions. However, it is best not to covet this cheap and use the native function function, otherwise the lifted stone will eventually roll over to its own feet. For example, file operations use functions such as fopen, rather than functions such as CreateFile.

4. Try not to use features that appear in the new C + + standard. Not all compilers support these features, such as VC does not support the C99 inside the variable parameters of the macro, VC support for some template features is not comprehensive. For security reasons, don't be too aggressive about this.

5. Try not to use features that are not explicitly specified in the C + + standard. For example, you have more than one dynamic library, each dynamic library has global objects, and the construction of these global objects have dependencies, you will have trouble sooner or later, the order of these global object constructs is not stipulated in the standard. Running on one platform correctly, on the other platform may be a panic, and ultimately the program to make a lot of changes.
6. Try not to use quasi-standard functions. Some functions are available on most platforms, and they are so widely used that everyone treats them as standard, such as atoi (converting strings to integers), strdup (cloning strings), ALLOCA (allocating automatic memory on stacks), and so on. Don't be afraid of 10,000, just be afraid in case, unless you understand what you are doing, or do not touch them as well.

7. Pay attention to the details of the standard function. Perhaps you don't believe that even the standard functions, regardless of the internal implementation, are sometimes surprisingly different in their outward manifestations. Here are a few examples:

int accept (int s, struct sockaddr *addr, socklen_t *addrlen), Addr/addrlen is the output parameter, if it is a C + + programmer, anyway, you are used to initializing all the variables, there is no problem. If it is a C programmer, it is hard to say, if not initialized, the program may be inexplicably crash, and you do not dream of it to doubt its head. This is not a problem under WIN32, it will only appear under Linux.

int snprintf (char *str, size_t size, const char *format, ...); The second parameter, size, which does not include null characters under WIN32, includes null characters under Linux, and this character difference can also take a few hours.

int stat (const char *file_name, struct stat *buf); This function itself is not a problem, the problem is on the structure stat, st_ctime in Win32 represents the creation time, under Linux represents the last modification (change) time.

File *fopen (const char *path, const char *mode); there is nothing wrong with reading the binaries. In reading the text file can be careful, Win32 under the automatic preprocessing, read the content and the actual length of the file is not the same, there is no problem in Linux.

8. Beware of data standard data types. Many people have eaten the type of int from 16-bit to 32-bit, which is already the past, here and not talk about. Do you know that Char is signed on some systems and is unsigned in some systems? Do you know that wchar_t is 16-bit under WIN32 and 32-bit under Linux? Do you know the bit fields of the signed 1bit, and the values are 0 and 1 instead of 0 and 1? The dubious of these things, the end of the shadowy, accidentally the way it.

9. It is best not to use the unique features of the platform. For example, Win32 DLL can provide a DllMain function, at a certain time, the loader of the operating system will automatically call this function. This kind of function is very useful, but it is best not to use, the target platform can not guarantee that this function.

10. It is best not to use compiler-specific features. Modern compilers are very user-friendly, thoughtful consideration, some features are very convenient to use. Like in the VC, you want to implement thread-local storage, you do not call Tlsgetvalue/tls tlssetvalue such functions, before the variable with a __declspec (thread) on the line, however, although there are similar functions in Pthread, It cannot be implemented in this way, so it cannot be ported to Linux. GCC also has a lot of extensions that are not available in VC or other compilers.

11. Note the features of the platform. Like what:

In DLLs under Win32, unless explicitly specified as the export function, the other functions are invisible to the outside. Under Linux, all non-static global variables and functions are visible to the outside world. This should be especially careful, the same name function caused by the problem, let you check for two days is not too.

Directory separator, under Win32 with ' \ \ ', under Linux with '/'.

Text file line break, under Win32 with ' \ r \ n ', under Linux with ' \ n ', under MacOS with ' \ R '.

BYTE order (big endian/small end), the byte order of different hardware platforms may not be the same.

byte alignment, in some platforms (such as x86), byte misalignment, nothing more slow, and some platforms (such as ARM), it completely in the wrong way to read the data, and will not give you a hint. If something goes wrong, you may not have a clue.

12. It is best to understand the resource constraints on different platforms. Presumably you remember that the number of files opened at the same time in DOS is limited to dozens of cases, now the operating system is much more powerful, but not unlimited. For example, the default maximum value for shared memory under Linux is 4M. If you are familiar with the resource limitations of the target platform, it may be helpful to have some problems easily located

Http://www.cnblogs.com/guoxiaoqian/p/3984974.html

Key points for writing a portable C + + program (12 articles)