Platform Independent C++ OS Library?
quench writes "Hello! I have been away from Windows and Linux application software for 5 years or so, doing mainly C-like embedded C++ programming. Now, I am about to start a project emulating embedded hardware on Windows. Been there, doing #ifdef WIN32 and #ifdef LINUX stuff, don't really want to go there any more. What I actually need is a platform independent lib covering Windows and Linux variants to handle sockets, IPC and threads abstractions. And a rock solid but simple embedded database to emulate flash memory. My reflex said, go for ACE and Berkeley-DB. Tell me, am I out of time? Am I missing something new and trendy, easier to use and better? Did time stand still?"
Intel Thread Building Blocks (http://www.threadingbuildingblocks.org/ is (are?) fantastic. Open source (GPL), works on any ISO-compliant C++ compiler and is fairly intuitive. It allows both high-level (parallel_for) and low level (task-based) parallelism. Particularly useful are the concurrent containers, since it saves you from reimplementing these basic structures.
Qt has been modular since ver 4, so you don't have to include the GUI components if you don't want to. The API is clean, elegant and consistent, plus the documentation is great. I don't have anything bad to say about ACE or Boost - they're both high quality toolkits - but if I had to choose just one toolkit to use for the rest of my life, it'd be Qt, hands down.
"Good people drink good beer"
If you want "close to the metal" POSIX API compatibility then there's Cygwin which is easier to use IMO and more actively developed but doesn't support the *full* POSIX spec or there is UWIN which supports most of the POSIX spec.
;) or IMNSHO preferably wxWindows/wxWidgets and you've got yourself a full cross-platform programming toolkit that can do just about anything.
Combine this with OpenGL, OpenAL, the SDL and Cygwin/X, QT, a Java layer using the SWT from Eclipse, *shudder* GLUT *shudder*
jdb2
That's not really a bad suggestion. Ruby, Python, even some dialects of Basic would work.
Also consider Pascal. There are dialects of Pascal that have strongly attempted to be identical across platform boundaries.
Additionally, anything that's running on a virtual machine would be a reasonable consideration. That includes qemu and xen, not just Java, Python, etc.
What's at question are "What are the requirements??". Without knowing that, there's no way to know which, if any, of these suggestions are reasonable. Given that the initial language is C++, I'd expect that Pascal is the best replacement, with Java a close second. But if speed isn't a limiting factor than the other suggestions should be given consideration.
Of course, what he's asking it probably more readily answered by something like FLTK, but it's hard to know, since we don't know exactly which features he needs to be handled by his library. FLTK is platform independent, and callable from C++, but pretty much only handles the graphic interface. If that's all he needs, then it's a good answer, but we don't know what his needs are.
I think we've pushed this "anyone can grow up to be president" thing too far.
I've once attempted to use Gtkmm for a new project. While the API is generally well designed, I found that the documentation for many features was totally inexistant. Even more annoying was the fact that some components were either buggy or not wrapped (from C Gtk) at all. Combined with the fact that components get created and deprecated at a huge rate, you don't even know what you should be using. Overall, I've had a really bad experience with Gtk (and especially gnome) development. I've only tried using Qt a little bit and so far I like it a lot. I've never done GUI with it though. I've used the "platform independent system library" part for things like threads, sockets and the like. The only thing I found a bit annoying was that it didn't integrate well with the STL.
Opus: the Swiss army knife of audio codec
For most cross-platform stuff, boost will do what you need. boost::thread will handle all of your threading needs.
boost::filesystem for manipulating pathnames; boost::datetime for date and time operations; boost::format for typesafe printf style I/O.
It also has boost::asio for sockets and boost::interprocess for IPC. I know nothing about them, but to judge from the quality of the rest of the boost library, they are probably very good.
For database, use Sqlite. It's a solid relational database stored in a single file, and you can even access the database from the command line for ad-hoc queries/debugging/whatever.