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?"
This platform independent lib you are looking for is called JAVA.
Nokia QT rocks...
I know Boost has threading support, but I'm not sure how much. Have you looked at that? (It also has a bunch of other useful libraries, perhaps Filesystem being pretty useful for cross-platform work.)
A cat can't teach a dog to bark.
NSPR, APR, boost system, threads
Use Qt. It's LGPL (So it's free for commercial projects as well), is well documented and offers a ton of abstractions (including sqlite).
http://qt.nokia.com/
And tool support is excellent as well (Visual Studio Add-In, Eclipse Plugin and a standalone IDE called QtCreator).
I've used Pthreads successfully as a cross-platform threading library. http://sourceware.org/pthreads-win32 is a quite good implementation for Windows, and it's built into Linux (and all other POSIX compatible OS's, such as OS X, as well).
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
Qt's "Core" library is a pretty solid platform shim. Plain GLib is also (somewhat easier to port due to no C++ ABI differences, but no native C++ api makes it less attractive to you).
Either one is an exceptional choice.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
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.
Boost has libraries for each of these three: sockets through the ASIO library, IPC through the Interprocess library, and threads through the threads library.
http://www.boost.org
The only thing that Boost is lacking for which you asked is a database library.
APR:
http://apr.apache.org/ http://en.wikipedia.org/wiki/Apache_Portable_Runtime
wxWidgets (aka wxWindows) does windowing, sockets, thread. I am not sure about DB, but I think it does. I haven't used it for DB yet.
---- aut viam inveniam aut faciam
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
Zoolib at Source Force under the MIT open source license. It has a flat file database format, exists for multiple platforms, has platform-independent thread and mutex classes, graphical user interface toolbox, thread-safe reference counted smart pointers, file access, TCP networking. You can ask the main developers Andy Green or Michael Crawford to port it to a new platform that isn't supported yet, but it supports all of the platforms listed on the source forge page.
The Zoolib Cookbook can help you get started.
The flat file database support is designed in Zoolib so that you can email someone the database file and they can click on it and open it up as an email attachment.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Unfortunately all the trendy cool kids are using Java these days, and only web-based applications are worth working on if you want to keep up with the times. The days of small, simple client-server apps are over, old hat, out of date, archaic. Nowadays you need to implement a web application using AJAX, web services, Struts and Spring and Hibernate, and you have to do it using Agile methodology. If you aren't linking in at least 100 Java class libraries, you don't have a "real" application.
C++? Too simple.
By the taping of my glasses, something geeky this way passes
#ifdef __BSD__
BSD and linux are different in some aspects when it comes to sockets. Made it a real PITA to code on linux, runs perfectly, then won't compile on BSD without a few more includes and some extra code.
It's mostly because they aren't answering the OP's question, and aren't contributing any useful information to the discussion. Compare the posts above with the following:
From what I've heard, one of the best cross-platform libraries for C++ is QT, (originally developed by Trolltech, now by Nokia). It's available either open source (LGPL) or commercially, and while best known for its UI toolkit also provides an extensive library of other functions. Wikipedia has a long list of things it has been used for, and other information.
On the other hand, if you're not too wedded to C++ specifically, Java, C#, or Python might be good alternatives. Syntax-wise, C# and Java are extremely similar to C++, and all three have extensive libraries (built in) that provide the functionality you're looking for. They're also cross-platform (with C# you'd need to stick with stuff Mono can do, but that's still pretty extensive) and you don't even need to re-compile. Speed-wise, both Java and C# are nearly as fast as native code for most applications today, as are certain Python run-time environments. If you need explicit memory management for something, you can even do that with C# (although at that point it may be better to stick with C++).
There's no place I could be, since I've found Serenity...
That handles all the things you mentioned, and you can compile pretty much all the same code natively on Linux or using Cygwin on Windows without having to bother with #ifdeffery at all.
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.
You say that you're writing a lot of "C-like" embedded C++. Are you doing fully OOP style coding and using 'new' and 'delete'? Or are you mostly taking advantage of conveniences like namespaces, scoped variable declarations, etc?
If your code is really more C-ish, you could take a look at the Apache Portable Runtime (http://apr.apache.org/). The APR is the library that Apache httpd is based on; they cover most system-level utilities (sockets, files, etc) you could need in a portable way. The APR is more 'C-like' in that a file descriptor is an opaque handle which you pass in to functions like apr_file_puts(), etc., rather than doing the C++ thing of file->puts()..
But if you're ok with the syntax, it's Apache licensed (corporation friendly), well tested (httpd is pretty ubiquitous after all) and actively maintained.
Yes, QT is really excellent, but it's worth it to look at Boost as well.
Want a database? Why use Berkeley when there's SQLite?
Portable sockets? QT and Boost both have them.
Portable file ops? QT and Boost both have them.
Data structures? QT has a bunch, but STL is what you should learn.
Windowing lib? QT works on both Windows and Linux. You may be tempted to use WXWidgets, but don't. Despite the fan boyz, you'll find that library to be buggy as shit, and impossible to debug. Sorry, that'll probably get me marked as a troll, but it's true.
And QT on Windows comes WITH the MinGW compiler for Windows package. You don't need to use any other tool than gcc on Linux, Mac, or Windows.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
No, POCO is not very good. The documentation is poor, and it's buggy.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
SQLite dominates discussions of embedded databases these days, but Berkeley DB still has fans who don't need SQL. There are a lot of comparisons on the web.
Duh, Qt!
The sole reason for POSIX subsystem in WIndows was to satisfy formal criteria in some US government specs. No one is using it to actually _code_, AFAIK.
There's always wxWidgets, which you can compile into your program if you feel like it. Quite liberal.
It's not a mere library, but a full framework, like Qt. I find the wx runtime to be smaller than an equivalent Qt program most of the time, and the Mac version of Qt's dylib bundler sometimes makes some stupid decisions which bloat the app by 50MB. wxWidgets (statically linked) gives me a 1.7MB executable for a Hello World-ish program.
The Java repliers are right on the mark. Trying to use app-independent portability layers ensures apps of any complexity will suck. By "suck", I mean "compromised at every turn by lowest-common denominator design decisions". Your app will end up using threads on an O/S designed to make multi-processing beautiful (Linux), or end up using multiple processes on an O/S designed to make multi-threading beautiful (Windows). It'll be clueless about the nifty GUI features that exist on a Mac but not Windows, and vice versa. Knowing up front that your app is going to suck allows you to, in all good conscience, choose a language that highly adapted for creating apps that suck in this manner. When I fire up a Java app on Windows (and I ALWAYS know it's a Java app the minute it finally manages to lumber onto the screen), I know I'm going to get the same sucky behavior if I fire that app up on a totally different platform (well, assuming I can manage to figure out whatever obscure infinite-megabyte downloads are needed to get the right "runtime engine" for the given app). Really, the only way you can make your app suck even more and be even more portable is to just go ahead and make it a web "service". That has the added advantage that nobody really expects anything but poor performance and clunky UI design from the get-go. But if for some reason you can't have your app suck as bad as a web service, then Java is definitely the next-suckiest way to achieve that portability that your end users don't give a crap about, but you hope will make your life easier.
agreed, I used POCO for its email classes, and while it worked its documentation was somewhat out of date or incomplete. Still, I could figure out what was needed. what I didn't like was their adherence to the 'one true OO way' of developing libraries, too much of an exception hierarchy just isn't good.
I didn't try the other parts and am probably not likely to. If boost had some general purpose classes (instead of mostly algorithms and general purpose classes) then I wouldn't have even looked at Poco.
...are ones with which I have the most experience. WxWidgets IMHO is the best 'close-to-the-metal' API, with the most available constructs to allow me to implement in C/C++ the Perl prototypes I develop. But most recently I've been noodling with Java to develop a high-availability platform, and I regularly run multiple jvms in Windows command shells to build stuff out, and then take the classes unchanged to a ttylinux-SunJRE-based cluster I run with VirtualBox.
I'm not a Java advocate by any means, but you can't ignore the portability...
I have long given up using the threading module in python itself, and have actually been using the Parallel Python module written by Vitalii Vanovschi extensively for my parallel processing needs. If you need multi-core / cluster processing and want to stick with python, this library is quite excellent. http://www.parallelpython.com
Obviously there are not a lot experienced embed heads reading slash. Java:( If you don't like ifdef this or that try Java. Instead of ifdef, Java programmers us xml in what I call program by configuration file. It adds an entirely new dimension to programming that most skilled programmers would never have thought of. It is even more delightful when they use multiple overrides on their configurations files and you have to hunt through multiple files to to see how things are configured. Not only that, they can actually change the way code executes with configuration files. So not only do you have to look at code to see execution paths, you have to dig through multiple configuration files. It is truly the strangest methodology I have ever encountered. Stick with a C or C++ library. QT works well. For key value searchers Berkeley has no peer but SQLite works ell if you are into SQL.
Definatly take a look at poco project http://pocoproject.org/ It seems to covera lot of what you want
I think modding people Troll is the /. equivalent of smacking dogs on the nose with a rolled up newspaper when they defecate in the apartment. I.e. it's just a way to stop them doing it again. Clearly no one wants to read "Why not use Java?!" in these sorts of discussions. Now you can't explain to a dog why indoor defecation is bad, just like you can't explain to Java programmers why Java is just a bad idea. Still shit in the apartment and posts advocating Java is not something which you need to tolerate.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I also come from an embedded background and I didn't find a C++ platform abstraction library to my liking (i.e. fun to use and giving the programmer maximum power and control), so I went off and wrote my own: http://www.nedprod.com/TnFOX/ (docs are at http://tnfox.sourceforge.net/TnFOX-svn/html/). You can build a noGUI version which leaves out all the GUI stuff which should provide what you want: it also has a type reflecting metaprogramming database adapter with a copy of SQLite3 thrown in for good measure, and it is very seriously fast and efficient unlike most GUI toolkits e.g. all the bottlenecks use assembler or intrinsics and there is ample stream computing support which uses metaprogramming to assemble vector instructions. One major difference from libraries such as ACE is that I deliberately made TnFOX as fun to program in as possible - I have made zero attempt to make it academically "proper" or "pure".
Hence it does come with an unusual programming paradigm - I make heavy use of C++ metaprogramming constructs and C++ exception handling and pervasive multithreading. And almost no one else uses it which I take it to mean that its learning curve simply isn't worth it for most people which is fair enough. In the end, if you ever want someone else to be able to work on your project then you need to use a well established toolkit which has a significant programmer pool attached to it. And ease of finding programmers is vastly more important than a "right" or "proper" or even "good" programming paradigm - as the designers of Plan 9, BeOS and NeXT found out.
If your project is something recreational, do give TnFOX a look. If it's for something ever destined for outside your personal fun time, go with Qt or wxWindows or any big free portability library.
HTH,
Niall