views:

86

answers:

1

I'm writing a Linux program that currently compiles and works fine on x86 and x86_64, and now I'm wondering if there's anything special I'll need to do to make it work on other architectures.

What I've heard is that for cross platform code I should:

  • Don't assume anything about the size of a pointer, int or size_t
  • Don't make assumptions about byte order (I don't do any bit shifting -- I assume gcc will optimize my power of two multiplication/division for me)
  • Don't use assembly blocks (obvious)
  • Make sure your libraries work (I'm using SQLite, libcurl and Boost, which all seem pretty cross-platform)

Is there anything else I need to worry about? I'm not currently targeting any other architectures, but I expect to support ARM at some point, and I figure I might as well make it work on any architecture if I can.

Also, regarding my second point about byte order, do I need to do anything special with text input? I read files with getline(), so it seems like that should be done automatically as well.

+3  A: 

In my experience, once code works well on a couple architectures, it will port more easily to a third one. Input shouldn't be an issue. Structure alignment may be an issue if you do anything where alignment is an issue.

Pay attention to anything that might be platform-dependent: relying on bitfields being aligned the same way, assuming variables are a particular size, etc. If your code is relatively abstract from the hardware, you will likely encounter few problems. If you are doing something with something like networking code, you will have to make sure you align with network byte order properly.

I have ported device drivers from PPC to x86, and then to x86_64; in a few thousand lines, there were maybe a couple changes, primarily related to structure and integer ordering.

The only way to know for sure is to try it, of course.

WhirlWind
Yeah, I was hoping that since my network code is just curl, and my input is all using cin or getline that there wouldn't be much to worry about.
Brendan Long