portability

Help me settle a score. I have a piece of software written in C++ that's meant to run on as many linux distributions as possible and I need to figure out a strategy that's effective. I'm trying to ship binaries in this case not source code (might be good to know). It's already a commercial product and I have intellectual property issues that prevent me from open sourcing the product but also means I have to deal with a myriad of GPL issues. The current line of reasoning has been to pick a least common denominator and build everything off that. That has two major implications that I find

Is there a portable Perl along the lines of portable Python? Something I could use (while learning the stuff) from my thumb drive? Oh, and I'm talking about Window XP. I can heartily recommend Strawberry Perl . The Portable version is on Beta (the real meaning of Beta, though), click here to get it. EDIT: The Portable version is already out of beta (for a few months now), check here There's a test version over at PortableApps.com although it appears that long-term it will be replaced by Strawberry Perl (which is what it's based on). I've deployed applications to hostile end user machines (i.e.

I'd like to start learning multithreading in C++. I'm learning it in Java as well. In Java, if I write a program which uses multithreading, it will work anywhere. However in C++, doesn't multithreading rely on platform-specific API's? If so, that would seem to get in the way of portability. How can I do multithreading in C++ without causing portability issues? Is boost's thread library a good solution? As a sidenote - how is it even possible to implement multithreading as a library? Isn't that something that has to be done by the compiler? If you do not have a compiler that supports C++0x yet

I really thought this would be easier to find... I need a portable c++ sockets wrapper. I'm planning to use it for a windows server application and a client that will be running on a embedded device running ulinux (or something similar). I would use Boost but I need it to be lightweight and easy to add to the embedded device project. Also I would like it to be a "higher level" wrapper... so it starts a background thread to read data and informs be over a callback... Any ideas? Just learn to use the socket API directly. You can then easily wrap it yourself. It's not that hard, and you can get

How similar/different are gnu make, microsoft nmake and posix standard make? Obviously there's things like "which OS?", "which compiler?" and "which linker?", but I'm referring specifically to the syntax, semantics and command-line options of the makefiles themselves. If I write makefiles based on manuals for gnu make, what are the most important portability issues that I need to be aware of? GNU Make and POSIX Make share a common core so that GNU Make understands makefiles intended for POSIX Make and interprets them the same way - with very few exceptions. However, many GNU Makefiles use

Currently, to represent a newline in go programs, I use \n . For example: package main import "fmt" func main() { fmt.Printf("%d is %s \n", 'U', string(85)) } ... will yield 85 is U followed by a newline. However, this doesn't seem all that cross-platform. Looking at other languages, PHP represents this with a global constant ( PHP_EOL ). Is \n the right way to represent newlines in a cross-platform specific manner in go / golang? I got curious about this so decided to see what exactly is done by fmt.Println . http://golang.org/src/pkg/fmt/print.go If you scroll to the very bottom, you'll see

How to make sure that my program will be fully portable? Steve Jessop 1. Test This is a necessary but not a sufficient condition for doing anything properly. To test portability, you'll want multiple platforms and compilers. 2. Write to the standard, not to your development platform. This means, only do something if the standard says you can do it. Only expect a particular result if the standard says you can expect it. Only use a library or API if the standard says it exists. The standard is available here (among other places): http://openassist.googlecode.com/files/C%2B%2B%20Standard%20-

Consider: std::tuple<int , const A&> func (const A& a) { return std::make_tuple( 0 , std::ref(a) ); } Is the std::ref required for writing correct and portable code? (It compiles fine without it) Background: If I remove std::ref my code builds fine without any warnings ( g++-4.6 -Wall ), but doesn't run correctly. In case of interest the definition of A : struct A { std::array<int,2> vec; typedef int type_t; template<typename... OPs,typename... VALs> A& operator=(const std::pair< std::tuple<VALs...> , std::tuple<OPs...> >& e) { for( int i = 0 ; i < vec.size() ; ++i ) { vec[i] = eval( extract(i