code::gallery

Developing cross-platform C/C++ code is not difficult, but definitely challenging and has to be disciplined. Usually, a separate interface is designed so that the platform-specific code is encapsulated. The challenges are presented on multiple fronts - every platform (OS and/or CPU architecture) has its own API for system operations, its own Endianness, implementation of pointers and more.

Today, developers have access to a plethora of cross-platform abstraction libraries. What this means is that the developers don’t have to worry about differences in the platforms and focus on their applications. The differences are abstracted into the libraries/toolkits/frameworks. Shlomi Fish has a nice extensive list including the popular Standard Template Library (STL).

Out of these, I have worked with Posix Threads for Win32, Boost and Mozilla XUL.

In addition to this Mozilla has a Cross Platform Component Object Model (XPCOM), which is the underlying base for every Mozilla application. I have also used Xerces C++ Parser. In addition to this, Ch language environment, an embeddable interpreter for cross-platform C/C++ scripting, is available for developing XML-based applications using C/C++..

Andrei Alexandrescu has developed a cross-platform library, called Loki (through his book Modern C++ Design), for illustrating benefits of policy-based programming. It employs template metaprogramming to the fullest.

Then there are Blitz++ and Matrix Template Library (MTL) (via O’Reilly Network).

As mentioned earlier, the code development should be disciplined to ensure portability. Mozilla has a C++ portability guide for making code portable.

I am sure all the libraries are not included here, if you know any that are not mentioned here, feel free to add them in the comments. I will update the post accordingly.

Tags: cross platform, abstraction, portable code, guidelines

Just like we have to read from left to right or right to left depending upon what language we are reading, programs should know how are integers stored before reading a binary. This is Endianness. Just like the languages it just a matter of preference. The two schemes are big endian and little endian.

In the big endian version, the most significant byte (MSB) is stored in the lowest memory address, whereas in the little endian version the least significant bit (LSB) is stored in the lowest memory address. Here is an example:

The 32-bit integer 2D441B36 has to be stored at memory address 400 - 2D is stored in 400, 44 in 401 (1 byte offset) and so on in the big endian scheme. In case of the little endian scheme, the bytes are stored in the order 36 1B 44 and 2D.

Unfortunately, both are being actively implemented and programmers need to know the endianness of a system. Here is a program in C to differentiate between big endian and little endian systems:

int isBigEndian()
{
    /* assign 00000001 */
    int sample = 1;
	
    /* convert to equivalent character array */
    char *sample_array = (char *) &sample;
	
    /* if little endian, the lowest memory address will contain
       the least significant byte, i.e., 01 */
    if (sample_array[0] == 1)
    {
        return 0;
    }
    else
    {
        return 1;
    }
}

Endianness becomes a critical issue for portable code when it is targetted for multiple architectures.

In addition to the computer architectures, endianness becomes imperative to consider in network protocols like TCP. If the byte ordering is not considered, it leads to the popular NUXI problem. Here is a function to swap between the two schemes by using bit-wise operations:

int swapByteOrder(int sample)
{
    int sample_reverse = ((sample & 0xff000000) >> 24) | /* MSB */
                         ((sample & 0x00ff0000) >> 8) |
                         ((sample & 0x0000ff00) << 8) |
                         ((sample & 0x000000ff) << 24);  /* LSB */
	
    return sample_reverse;
}

More reading

• Introduction to Endianness
• An Essay on Endian Order

Tags: endianness, big endian, little endian, c, nuxi, byte order.