Delve into some of the compiler options used to build Visual C++ projects and the UNIX and g++ equivalents, take a closer look at the g++ attribute mechanism as it relates to porting, and examines some common problems you might encounter while porting from a 32-bit Windows environment to a 64-bit UNIX environment.
Internals of Porting C/C++ Sources
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
If you code by the standards, g++ is much more friendlier. As the article points out, i had many issues porting from g++ to msvc++, because visual C++ likes to mix up calling conventions all over the place, which avoided some code from working, as well as the scoping issue, which is for compatibility with 6.0. All issues can be fixed with compiler flags in msvc, thankfully.
Though I agree with you in every point, msvc is very ISO compliant since msvc 7.1 and porting software between g++ and cl is easier than before. msvc 6.0 is a nightmare.
If it is easier with msvc 7.1, I wouldn’t want to imagine what msvc 6 was like. It’s nightmarish enough with msvc 7.1.
No, I don’t consider msvc 7.1 to be ISO complaint; there are still a lot of little things that break, and make porting really hard. May be it is at a fundamental level, but not at a practical level; of course, part of it is due to the archaicness of Windows programming too.
MSVC may be getting closer to ISO but it is not ISO compliant and the Microsoft product managers for many years have stated that being fully ISO compliant will never be a goal, they’d rather spend their effort interoperating with the rest of the dot-NET stack.
It is a goal of gcc/g++ to reach full ISO compliant, where the specs are unambiguous (it is reasonably difficult to do given the complexity of C++).
Edited 2007-11-15 02:00
This really isn’t much of an issue as one can use the C pre-processor to create the ability to do this well. I’ve done it, and it works beautifully. This is also probably why Qt and other similar programs make extensive use of a pre-processor too, whether C’s or a custom pre-processor.
This is also what makes tools like CMake useful in that you can put all this stuff together and change it on the fly for each compiler environment. 😉
[Edit: Afterthought to original post – you can easily use the pre-processor to setup an environment that you can use a single function set and common API to do everything on both Unix and Win32 platforms. It takes a bit of work to setup, but works beautifully when done. Threading can easily be done this way, as can events, mutexes, networking, and more. This is part of what I meant in the first paragraph.]
Edited 2007-11-14 14:19
The main obstacle in porting Windows apps to Linux is the nonexistent capability of Linux/glibc to convert synchronous signal to exceptions. There is a common practice to neutralize innocent segfaults (like null pointer assignment) by try-catch technique in Windows. Microsoft compiler do even provide a proprietary extension __try,__except,__finally you can use to do it in pure C.
On Linux you can only simulate similar technique by nonlocal goto (losing stack unwinding capability). Some attempts to fix this ended half way recently. One can achieve it by some esoteric gcc switches, but not on the i386 architecture.
It’s sad, the only instance you can make use of it, is running Windows binaries under WINE. Wine developers were forced to support this, since real Windows applications would crash too often. So it’s nothing impossible, just another religions prejudice against features invented outside of the Linux camp.