Re: Top 10 tips for code porting c/c++

[helios]

I wanted to reply in the thread, but it was archived, so here goes:

The best way to introduce code portability is while coding.

As opposed to introducing it while juggling?

Non-portable code introduces problems like maintenance of different versions, reduces readability, reduces understanding of code etc...

Huh? How exactly does portability increase readability?
Also, the first phrase is completely backwards. It's portable code that often requires several versions. Code that's meant to work for a single platform needs a single version, while it's not always possible to use the same code for different platforms.
For example, suppose you're writing a library to abstract file system operations. The function that creates a directory will need one version for Windows, another for POSIX, etc.

So, the best policy is to keep portability into account while writing code, it saves lots of time

Portability takes time. If, for whatever reason, the project doesn't need to be portable, then making it portable is a pure waste of time. You might argue that it's easier to make it portable early on, than the requirements changing later and having to do a lot of rewriting, my answer to which is YAGNI.

2) Don't use specific system constant.

What? Define "system constant".

3) System file/folder path notation may vary on different platform.

But forward slash and relative paths are universally accepted.

5) Always write default statement in switch case.

What does that have to do with portability?

6) Always specify return type for functions.

Wait. Is this for C, C++, or code that can be compiled by either compiler? The shortest valid C89 program is main(){}. C99 issues a warning.

7) Always specify type with static variables.

8) Always take care of scope of variable.

10) Take care of include depth for header files and also for file code size.

What's any of that supposed to mean?


Finally, https://developer.mozilla.org/en/C___Portability_Guide
Not all the points in that guide will be relevant for everyone, but it's good nonetheless.
Also, partly relevant to portability: http://www.jorgon.freeserve.co.uk/GoasmHelp/Unicode.htm

[chrisname]

I think you've misunderstodd some of what he said.

Also, the first phrase is completely backwards. It's portable code that often requires several versions. Code that's meant to work for a single platform needs a single version, while it's not always possible to use the same code for different platforms. For example, suppose you're writing a library to abstract file system operations. The function that creates a directory will need one version for Windows, another for POSIX, etc.

I think he meant that if you write portable code for a cross-platform program, you only need to write one version (if you use conditional compilation inline with your code) as apposed to having a windows version, a Linux version, a Mac OS version, etc. of the whole program.

But forward slash and relative paths are universally accepted.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

$ for C in A B C D E F G H I J K L M N O P Q R S T U V W X Y Z; do cd $C:/; done

bash: cd: A:/: No such file or directory bash: cd: B:/: No such file or directory bash: cd: C:/: No such file or directory bash: cd: D:/: No such file or directory bash: cd: E:/: No such file or directory bash: cd: F:/: No such file or directory bash: cd: G:/: No such file or directory bash: cd: H:/: No such file or directory bash: cd: I:/: No such file or directory bash: cd: J:/: No such file or directory bash: cd: K:/: No such file or directory bash: cd: L:/: No such file or directory bash: cd: M:/: No such file or directory bash: cd: N:/: No such file or directory bash: cd: O:/: No such file or directory bash: cd: P:/: No such file or directory bash: cd: Q:/: No such file or directory bash: cd: R:/: No such file or directory bash: cd: S:/: No such file or directory bash: cd: T:/: No such file or directory bash: cd: U:/: No such file or directory bash: cd: V:/: No such file or directory bash: cd: W:/: No such file or directory bash: cd: X:/: No such file or directory bash: cd: Y:/: No such file or directory bash: cd: Z:/: No such file or directory

Always write default statement in switch case.

What does that have to do with portability?

Compiler portability.

[helios]

I think he meant that if you write portable code for a cross-platform program, you only need to write one version (if you use conditional compilation inline with your code)

Conditional compilation involves keeping different versions of code that does the same thing.

as apposed to having a windows version, a Linux version, a Mac OS version, etc. of the whole program.

You're describing a portable program. Unless the PM is completely incompetent and at least mildly retarded, he's not going to write a completely different codebases for each targeted platform. There will be a shared codebase and several platform-specific portions of code.
Now, a program that isn't portable will have a single monolithic codebase. No different versions of anything and no conditional compilation (unless maybe the code has to be compiled by different compilers).

Portable programs involve platform-specific code that grows in differentiation with complexity. What starts as checking sizeof and endianness soon becomes conditional compilation, multiple makefiles, and different toolkits being used in different platforms.

I'm not saying that unportable code is better. I'm just saying that claiming portable code is simpler is absurd.

bash: cd: A:/: No such file or directory

Which part of "relative paths" are you having difficulty with?

Compiler portability.

No compiler will reject a switch for lacking a default case.
GCC has becomes rather touchy in recent years and likes to vomit warnings for nothing. How dares it tell me that (a && b || c)==((a && b) || c)? I didn't take Boolean algebra in high school for nothing!

[jsmith]

[soapbox]

Sorry, but portability is almost a joke.

C/C++ can't even guarantee me the range of values an int can hold from machine to machine.
When C was invented, programming was all about squeezing every ounce of speed out of
the hardware (why? because C was invented to write an OS). "Portability" meant that my
program would run "optimally" on any machine it was compiled on. That says nothing about
whether it does the same thing on every machine it runs on. Speed isn't the concern
any more.

But while x++; increments x on any platform, it's hard to write any non-trivial C/C++ program
(or any compiled language for that matter) such that it will compile and execute on multiple
different architectures with, as helios mentions, writing some platform-specific code. Let's
face it: unices have POSIX APIs, Windows has, well, Windows APIs. They're not the same.

And GUIs... Unix has a plethora of GUIs/Window managers to choose from; Windows you
have Windows. If you want to try to write an application that is "portable" and uses a
GUI (most non-trivial apps these days), you're pretty much stuck with a cross-platform
GUI toolkit like Qt. And just ask the guys at Trolltech about portability. Exactly how much
platform-specific code have they written? Lots.

Essentially, portability nowadays comes down to wrapping the kernel/OS in an abstraction
layer. But that could be done in any compiled language.

[/soapbox]

[S6k9GNh0]

Its not C, the programming language,'s fault that different OSs decided to choose different API interfaces. Everything chooses to take a different path because it thinks its way is better (although I have no clue what X11 had in mind originally, but what it turned out to be was probably not that.). We can come up with a universal API for everything but what good does that do if nobody uses it?

There's a reason why C/++ does that probably. I'm sure they didn't just say, "Hey, lets not make sense and do this to make people ask questions." There was original intent in it most likely with the large amount of planning placed in the language.

Not everyone can get up and make a windowing system. It requires time, devotion, and knowledge ( and more often than not, wisdom). Because of this, we have no choice but to comply to those that take the time to implement what we need to program. What would you suggest?

EDIT: It's completely possible in C to make a layer between the user and the OS that is the same on ALL OSes in the developers view. C++ is actually taking this to its advantage to implement things like std::thread.

[chrisname]

@helios,
I wasn't disagreeing with you. I was just suggesting that you misunderstood some of what he meant and took it the wrong way. I wasn't saying he was right.

Edit: also, MSDOS doesn't accept forward slashes, only backward ones.

[helios]

MSDOS doesn't accept forward slashes

No one cares about DOS.

[chrisname]

DOS is fun to play with. No hardware protection means you can basically write your own OS within it and then kick it out the way.

My profile thing wrote:

Currently working on:
...
# A DOS "bootloader" called "DOSTheif" (it loads an OS from within DOS and then passes control to the new OS, like LoadLin)