Differences between Windows and Linux Compilers

Differences between Windows and Linux compilers-general Linux technology-Linux programming and kernel information. The following is a detailed description. The first step after the porting starts is to compile on the Target Platform Linux and link the source code. Because the software to be transplanted has not been compiled on the Linux platform, the compilation process may be very difficult. In general, compilation errors caused by type declarations are easier to fix. For example, the header file of Microsoft C/C ++ uses _ declspec (dllimport/dllexport) to input and output DLL functions. In Linux, the function is declared as extern "C ", or use the DEF file together and use the corresponding link command to solve these problems. However, the difficulty lies in the difference between compilers, which is also an important factor that may cause many runtime problems. It is necessary for readers to fully understand the problem before starting porting. This section describes some aspects that are easy to ignore and have serious consequences.

Take Visual C ++ 2003 and GCC 4.1.0 as examples. The former is the mainstream compiler on Windows, and has good compatibility, but does not strictly follow the C ++ standard. This means that even if the developer writes a program that does not conform to the standard, the compiler may tolerate it. On the contrary, GCC follows much stricter standards, which can easily cause unexpected compilation or even running errors in Windows programs and Linux systems.

(1) alignment of Basic Types and structures

The first is the size of the basic C/C ++ language type and the corresponding structure alignment problems. A typical example is the long keyword. In Visual C ++ 2003, sizeof (long double) is 8, and its size is the same as that of double. But on GCC 4.1.0, sizeof (long double) is equal to 12, which is 4 more than double. Another issue related to size is alignment. The default alignment sizes of different compilers are different. In general, the program logic has nothing to do with alignment, but when it involves reading the structure from a disk or network file (such as parsing resources), precise alignment is required. Measure the test taker's knowledge about the following sections:

# Include
Struct

{
Char;
Double B;
};

Int main ()
{
Printf ("% d \ n", sizeof (long double ),
Sizeof (long), sizeof ());
Return 0;
}

In the default settings of the Visual C ++ 2003 compiler, the output result of the above program is 8 to 16. In the default settings of the GCC 4.1.0 compiler, the output value is 12 to 12. From the size of sizeof (A), we can see that Visual C ++ 2003 is 8-byte aligned, while gcc is 4-byte aligned. In this case, you need to use the # pragma pack pre-compilation command to modify the structure declaration in the header file, or adjust the position of the structure members in the memory at runtime. No matter what method is used, alignment requires careful processing.

The most troublesome basic type is wchar_t. In the Visual C/C ++ 2003 compiler, wchar_t is 2 bytes in size and can be assigned to each other with the unsigned short type. A series of Unicode-related functions associated with this feature, such as wcslen and wcscmp, all accept Unicode strings in UTF16 format. In GCC, the size is 32 bits. The wcslen and wcscmp functions related to this function all accept Unicode strings in UTF32 format. To solve this problem, you must develop a set of UTF16 interfaces of the wcs series functions on Linux to ensure that the UTF16 strings are correctly processed. At the same time, use the macro definition to replace the wchar_t keyword with the unsigned short to ensure the compatibility of function declaration.

(2) error handling of the new operator

Another problem is the error handling of the new operator. The new operator may have different behaviors due to different compiler settings. Test the following code snippet:

# Include
Class
{
Public:
Void * operator new (size_t size)
{
Return NULL;
}
A ()
{
Printf ("Constructor called \ n ");
A = 0;
}
Private:
Int;
};

Int main ()
{
A * p = new ();
Printf ("% x \ n", p );
Return 0;
}

In Visual C ++ 2003, the above program outputs 0. The output result of the GCC 4.1.0 compiler is:

Constructor called
Segmentation fault

That is to say, the compiler of Visual C ++ 2003 checks the return value of new. If the returned value is null, the constructor will not execute it. But must gcc be added? The fcheck-new compilation parameter has this line: g ++? Fcheck-new test. cpp. In this way, the above program will output 0 in Linux.

(3) Structural and C ++ exceptions

Another hidden difference exists in exception handling. Visual C ++ does not follow the C ++ specification for exception handling. Measure the test taker's knowledge about the following sections:

# Include
Int main ()
{
Int * p = NULL;
Try
{
* P = 0;
}
Catch (...)
{
Printf ("caught the exception \ n ");
Return 1;
}
Return 0;
}

Readers can use Visual C ++ 2003 and GCC to test the program respectively. The program generated by the former runs normally on Windows, outputs the exception, and Exits normally. The program generated by GCC only outputs Segmentation fault. Therefore, in Windows, the catch statement captures an exception. According to the C ++ standard, only throw statements can generate exceptions. However, in the above section, it is just a simple value assignment statement. The reason is that Visual C ++ 2003 maps C ++ exception handling to Windows structured exception handling. In the preceding statement, * p = 0 will cause a Windows exception. Visual C ++ processes it into a C ++ exception and enters the catch Block. In Linux, the program crashes directly because no C ++ exception occurs.