portability

Let's say I want to create FPS game, let's say clone Crysis so everybody understand what type of graphics & performance I'm after. What's the best code to write this game with so it's as easy as possible to port it to all the common platforms? Of course I want the application to feel and be native to the platform. This also means that it should be easy to take advantage of Snow Leopard's new features like OpenCL and Windows 7's new features. I realize that GUI has the written separately for different platforms and that's not a problem. So my question is that what's the best language for the

Unix has \n, Mac was \r but is now \n and DOS/Win32 is \r\n. When creating a text file with C, how to ensure whichever end of line character(s) is appropriate to the OS gets used? fprintf(your_file, "\n"); This will be converted to an appropriate EOL by the stdio library on your operating system provided that you opened the file in text mode. In binary mode no conversion takes place. From Wikipedia: When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one character. (Note that a C implementation is

I want to create a temporary file in POSIX shell ( /bin/sh ). I found out that mktemp(1) doens't exist on my AIX box, and according to How portable is mktemp(1)? , it isn't that portable and/or secure anyway. So, what should I use instead ? billhill00 Why not use /dev/random ? It could be neater with perl but od and awk will do, something like: tempfile=XXX-$(od -N4 -tu /dev/random | awk 'NR==1 {print $2} {}') ghoti You didn't exactly define "secure", but one element of it is probably to clean up after yourself. trap "rm -f \"$tmpfile\"" 0 1 2 3 15 You can probably man 3 signal to see if there

Unlike Java or C#, primitive data types in C++ can vary in size depending on the platform. For example, int is not guaranteed to be a 32-bit integer. Various compiler environments define data types such as uint32 or dword for this purpose, but there seems to be no standard include file for fixed-size data types. What is the recommended method to achieve maximum portability? I found this header particularly useful: BOOST cstdint Usually better than inventing own wheel (which incurs the maintenance and testing). Create a header file called types.h, and define all the fixed-size primitive types

As far as I know, the C library provides no help in serializing numeric values into a non-text byte stream. Correct me if I'm wrong. The most standard tool in use is htonl et al from POSIX. These functions have shortcomings: There is no 64-bit support. There is no floating-point support. There are no versions for signed types. When deserializing, the unsigned-to-signed conversion relies on signed integral overflow which is UB. Their names do not state the size of the datatype. They depend on 8-bit bytes and the presence of exact-size uint_ N _t. The input types are the same as the output types

Porting code from 32bit to 64bit. Lots of places with int len = strlen(pstr); These all generate warnings now because strlen() returns size_t which is 64bit and int is still 32bit. So I've been replacing them with size_t len = strlen(pstr); But I just realized that this is not safe, as size_t is unsigned and it can be treated as signed by the code (I actually ran into one case where it caused a problem, thank you, unit tests!). Blindly casting strlen return to (int) feels dirty. Or maybe it shouldn't? So the question is: is there an elegant solution for this? I probably have a thousand lines

I occasionally use 64 bit arithmetic in an open source C++ library of mine. I discovered that long long serves my purpose quite nicely. Even some 10 year old solaris box could compile it. And it works without messing around with #defines on Windows too. Now the issue is I get complaints from my users because they compile with GCC -pedantic settings, and GCC insists on issuing warnings that long long is not part of the C++ standard. This is probably right, but I am not too interested in the C++ standard per se, I just want my code to work on as many compilers as reasonably possible. So my