0

Apparently, I did good enough of a job on a previous project that I've been handed a new task of making a program (written in Visual Studio 2008) cross-platform for Windows (xp and 7) and Redhat/CentOS. My goal is to avoid using #ifndefs as much as possible and include as many libraries as I need for the program (its not too big, a few thousand lines).

Some immediate issues I've ran into are string manipulation and time related functions. What other things should I keep in mind?

Community
  • 1
  • 1
z -
  • 7,130
  • 3
  • 40
  • 68

2 Answers2

4

I've found this document Ten Rules for Writing Cross-Platform Programs in C useful.

Since you are also using C++, I second the motion to use the Boost Libraries as much as possible. They are, unless otherwise documented, designed to be cross-platform.

cjm
  • 61,471
  • 9
  • 126
  • 175
Andy Finkenstadt
  • 3,547
  • 1
  • 21
  • 25
  • 1
    Boost is giant and a bit bloated, it seems like overkill for a program of a few thousand lines unless he needs an aspect of it especially. Most likely the std library will provide what's needed. – Arelius May 03 '11 at 20:23
  • 2
    Most likely, but I disagree about Boost's bloatedness. If the original poster is CONVERTING a program from Windows to Linux, he likely already has random parts of Windows-specific and Microsoft C Runtime-specific functions strewn throughout his code. It will be faster to change those to use a common cross-platform API, than to write emulation functions for them for Linux. `Been there, done that. Still have the scars.` – Andy Finkenstadt May 03 '11 at 20:25
  • 1
    It's common to use one or two libraries from Boost. Boost even has a tool to help do exactly that ( http://www.boost.org/doc/libs/1_46_1/tools/bcp/doc/html/index.html ). – Max Lybbert May 03 '11 at 20:29
  • But depending on what you are doing, std may already exist as the common cross-platform API. That is to say, boost may be fine, but you shouldn't use it until it's clear that it'd be actually very helpful. – Arelius May 03 '11 at 20:32
  • 3
    std is way too limited. No encoding, no filesystem abstraction, no xml, no image processing... Not using boost can easily make code less maintainable. For example, not using boost::function and boost::bind when you should will increase code coupling, which is almost always bad. – BatchyX May 03 '11 at 21:09
  • You shouldn't use anything that isn't helpful. But there's no reason to fear Boost, especially since the Boost developers have gone out of their way to create tools like `bcp`. Which is better, opening an `std::fstream` or `FILE*` and `seek`-ing to the end in order to find the file size, or using Boost.filesystem? – Max Lybbert May 03 '11 at 21:40
  • IMO, using FILE* doing a fseek, and an ftell is much easier then having to get boost compiled and linked in when windows is a platform to deal with. – Arelius May 03 '11 at 22:36
  • That's interesting. I've never had trouble building Boost, although from comments here it is apparently a common problem. OTOH, I *have* had significant trouble getting the Apache Portable Runtime built on Windows. – Max Lybbert May 04 '11 at 05:17
  • You're going to need a cross platform layer for any cross platform work. You either write it (eg., the "Ten Rules for Writing Cross Platform Programs in C" approach) or you use somebody else's. I don't really care if "somebody else's" is NSPR, APR, Boost, etc., but I do strongly believe it makes sense to leverage somebody else's work, especially their testing and work dealing with platform quirkiness. – Max Lybbert May 04 '11 at 05:18
2

Overall, I cannot stress how the best way to avoid making it difficult, is to get it running on multiple platforms ASAP, and then keep testing on all platforms. It's easy to solve any platform problem when it comes up early, individually, and while working on the specific aspect of the application. It only becomes a problem when you have to deal with it all at once.

It's entirely dependent on what platform specific libraries you are using. I for instance wouldn't expect string manipulation to be an issue, as I normally see that done using c string libraries. or std::string.

Time is pretty common to be done in a platform specific way.

Some developers like to use win32 File I/O.

Is the program a console program? Normally UI toolkits is the big and difficult one.

Other then that, anything that deals with file paths is generally suspect, slashes going the wrong way, case sensitivity, etc.

edit: I was under the impression that you were porting an app, not writing one from scratch. It'd be very helpful if you would outline the things your app does.

But in general use std classes, or standard C functions, if you find you've included "windows.h" anywhere in a non-platform specific file you're probably doing something wrong is the basic just. As mentioned elsewhere, you could use boost but for a program that's only 1000 lines or so, it's doubtful that you will need it IMO.

Arelius
  • 1,216
  • 8
  • 15
  • String manipulation will definitely be an issue; the natural string representation on Windows is wstring. – Mark Ransom May 03 '11 at 20:16
  • 1
    a wstring is just a basic_string wchars, this type is a part of standard c++. – Arelius May 03 '11 at 20:19
  • The length of `wchar_t` on Linux varies from Windows. Been there, learned that. – Andy Finkenstadt May 03 '11 at 20:26
  • iirc, linux uses utf-8 while windows uses utf-16. This is true, but in general, the code should still work just fine, separate from the actual encoding. – Arelius May 03 '11 at 20:28
  • 1
    "separate from the actual encoding", no this is the Whole issue. If you have to generate strings or files in a specific encoding (hint : xml) then you HAVE to care about encoding, and abstract your internal representation from the encoding of the OS, or else your program won't work with a latin1 OS if your XML contains non-latin1-translatable characters. – BatchyX May 03 '11 at 20:57
  • This is only true if you have data that is saved and transferable between platforms, this is not always the case, and even if it is, while windows uses UTF-16 for it's native C calls, I don't think I've ever seen a win32 app save it's text files in UTF-16. That'd be a disaster waiting to happen even if Windows was your only platform. – Arelius May 03 '11 at 21:10
  • Your experience, @Arelius, is not complete. I regularly write BOM identified UTF-16 text files for an application. I read them, too, using simple tools like `Notepad`. Aside from that, `wchar_t` on GCC, by default on some common platforms, is 32-bit wide. – Andy Finkenstadt May 03 '11 at 22:27