Cross-platform programming Created 13 years ago2011-04-04 02:02:22 UTC by DiscoStu

For a while now I've wanted to write a particular client-server app. So far the only thing I've done about it is a mock GUI prototype on VB2005 a few years ago. However, after some intense thinking I've decided it would be best to make it cross-platform. Good apps should run on every OS

The problem is, besides knowing I should probably write it in c++, I have no idea where should I start - or even how to make a bunch of c++ code to compile correctly and run across different platforms. So this leads to the question: does anybody here know how to do this?

And now, after having typed this, I realise it's probably not smart of me to commit myself to such an ambitious project, I'm probably not knowledged enough to even start. But still... what's the worst that could happen?

If you need a UI for C++, the safest option is probably Qt. I haven't used it myself, but it's really the only fully cross-platform full-featured UI framework for C++ that I know of.

If you're feeling a bit more adventurous, you can try Mono, which is fully compatible with Windows Forms and .NET 3.0.

Yeah, all of the other UI libraries are awful. Using QT means using their IDE though.

If visual basic is the only language you know, you'll have to get used to C syntax. Beyond that, pointers are the only 'real' new trick. Maybe templates, which are basically the same thing as .NET generics.

Actually I do know c++ amongst others. I did the mockup on VB just because it's what I had at hand at the time. I suppose I could give this QT framework a try.

I suppose I also could very well use Java, but I'm not too versed in it and its interaction with network ports. On second thought, neither on c++.

Thanks for the suggestions. If this project ever sees the light of day, I'll be sure to let you know about it

When writing cross-platform C++ there are a few things you might want to think of.

First of all, the size of most types varies. A notable exception is char, which is always one byte. There is no integral type that must be larger than 1 byte. A char, short int, int, long int and a long long int can all have the same size. You can however, be sure that long long int is of the same or larger size than a long int, that a long int is of the same or larger size than an int, and so on.

The (u|)int(8|16|32|64)_t types are optional (they aren't necessarily defined).

A byte is not always 8 bits (in C++ and computer systems in general). If sizeof(int) is equal to 4, you can store 4 * CHAR_BIT (found in <climits>) bits in an int variable. Most computer systems use a word size (byte size) of 8, 16 or 32, but this isn't always the case. In C++ the size of a byte is always 8 or more. There is no type that's bound to be have a specific bit size and isn't optional. The majority of computers have a word size of 8 so you may want to ignore this issue. An octet is a byte of 8 bits. So instead of saying kilobyte or kibibyte when you mean 8192 bits it'd be better if you say kibioctet. Of course, this would never catch on.

Computers use different byte orders, this is referred to as endianness. x86 processors are little endian, meaning an integer with the value 1 with a byte size of 2 is stored in this order in the processor and in memory: 00000001 00000000. In a big endian system with the same word size (8) as x86, the same integer would be stored in reverse order: 00000000 00000001. Then there's middle-endian, which is simply messed up. Middle-endian processors are very uncommon so you can probably ignore them safely. Endianness is a problem when you write data to a file and then transfer that file to a computer with other endianness. To counter this, you should swap bytes when reading and writing files in either big endian systems or little endian systems. Big endian is also known as network order, as many network protocols use it.

C++ does not enforce a certain text encoding. When doing I/O make sure your text is in the right encoding. win32 by default uses an encoding derived from the language of the operating system (Swedish or English = CP-1252, Polish = Windows-1250, etc.) or set manually by the user, but there are special functions which use UTF-16 instead.

Perhaps I should just be a manager instead. I'll write the specs and you guys get to do the work.



I've never dealt with little/big endian differences. Where would I find a big endian processor?

PlayStation 3, old Macs and some or most IBM systems are big endian I believe.

The points I have presented are mostly issues when doing I/O. You could let libraries do the I/O. There's no need to reinvent the wheel, right?

PlayStation 3: It's not a game, so I don't need to care.
Old Macs: Well, they're old anyway, right?
IBM systems: Oh, FUCK IBM. They don't deserve my hax.

Maybe I'll let the libraries do it, like you say. After all I don't intend to program assembly. I could, but... too low-level for this kind of app.

Kinda silly, potatis. You spent ages explaining a non-issue on platforms he's never going to be targeting. Any high-level language abstracts that stuff away to the point that you don't have to care about them at all if you don't want to. C++ is high-level enough for this. Only time you need to worry about it is when you're programming on specialised hardware, the x86 processor is hardly specialised.

I guess I misinterpreted cross-platform as platform-independent. I believe it's good to write platform-independent code. You wouldn't want to have to rewrite it if you decide to support an incompatible platform. Endianness is not a non-issue. When writing network or file storage code you can't ignore it, unless you're targeting inter-compatible platforms.

Any high-level language abstracts that stuff away to the point that you don't have to care about them at all if you don't want to. C++ is high-level enough for this.

No, it is not. It does not abstract this away, as it writes and reads data using the endianness of the platform.

Run the following on an x86 system:

#include <fstream>
int main() {
const int data = 123;
std::ofstream f("example", std::ios_base::out | std::ios_base::binary);
f.write(&data, sizeof(data));
f.close();
return 0;
}

Copy the file "example" to a PowerPC system. Then run this first on the x86 system and then on the PowerPC system:

#include <iostream>
#include <fstream>
int main() {
int data = 0;
std::ifstream f("example", std::ios_base::in | std::ios_base::binary);
f.read(&data, sizeof(data));
f.close();
std::cout << "data=" << data;
return 0;
}

On the x86 system you'll get "data=123". You won't on the PowerPC system (assuming it's running in the default big endian mode and sizeof(int) > 1).

I just want an app that caters to the needs of users of different operating systems. So basically I'm thinking that it should be compatible with Windows, Mac and *nix. Perhaps some smartphone also, but I suppose that would require completely specialised code.

I also intend it to render HTML to some extent, so I've been considering the use of Gecko or WebKit - any recommendation?