Why not cross-platform?

[S6k9GNh0]

In certain occasions I might be able to understand. But when people write servers that are clearly able to become cross-platform and/or even more effecient, they write code using the WinAPI where barely even needed. Or when we create GUIs that clearly are able to be made and compiled on different platforms, why not go through the extra 5 minutes of your time to make your program more flexible? Am I missing something?

[kbw]

IHistorically, C programs were portable because C implied a Unix programming interface. When C moved off Unix, it took much of that interface with it. The C Standardisation process went some way in untangling what was Unix and what was C; and since then the Unix parts have been formalised with the POSIX standards.

It's not always clear what's a C/C++ library function and what is an OS function. On Windows, it's easy to spot a Platform SDK call, they have big names like CreateProcess, whereas it's not so easy if it looks like a C name.

You can't be sure your app is portable unless you have the target platform to hand to test it. Making something portable takes more than 5 minutes.

By sticking with platform agnostic code, you can loose out on platform specific optimisations.

[helios]

You can't be sure your app is portable unless you have the target platform to hand to test it.

True, but you can certainly increase the portability probability.

On the high level, you just need to avoid any function call that isn't standard. If you need to do something that isn't standard, you use a portable library (e.g. instead of making windows by directly calling the WinAPI, using a GUI toolkit).

On the lower level, you have to avoid making assumptions about type sizes and endianness.

Finally, sometimes a library that's supposed to be portable behaves slightly differently on different platforms and you have to compensate by not using the unreliable feature. SDL_BlitSurface() gave me a surprise once when I tested my program on Linux.

Making something portable takes more than 5 minutes.

Nah, not really. On average, making an app portable doesn't take significantly longer than making it unportable.

By sticking with platform agnostic code, you can loose out on platform specific optimisations.

But you can take advantage of them and still keep the application portable by writing different versions of the same code for different platforms.

More often than not, applications are unportable due to the author's shortsightedness or indifference, not because of any technical reasons.
The same applies to applications lacking Unicode support when it would be appropriate. Among the more annoying examples I know of are IrfanView, TotalCommander, and anything that comes out of Japan.

[kbw]

In the environment I work in, if you can't test it, you can't say it works.

You are corrent in saying you can compromise the effort by

making assumptions about type sizes and endianness

. But not doing so doesn't gurantee success.

You can't code for the general case if you don't know what that is. When you start out, the target platform is all the project has budget for. Most of the time that will do, but it's only time and opprotunity that will tell if change is needed later on.

[helios]

In the environment I work in, if you can't test it, you can't say it works.

I was agreeing with you. What I was trying to say was that you can make something more portable by avoiding certain things.

You can't code for the general case if you don't know what that is. When you start out, the target platform is all the project has budget for. Most of the time that will do, but it's only time and opprotunity that will tell if change is needed later on.

Come on, now. There are things that it's just stupid not to do and are yet a tremendous help in porting. For example, using forward slashes.
And I'd say it's cheaper to start with the objective of writing code as portable as possible than to go back later on and rewrite it for portability. Obviously, I'm not saying this makes sense for all projects, but it does make sense for quite a few.