Platform Independent C++ OS Library? 310
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?"
Boost? (Score:3, Informative)
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.)
Qt (Score:5, Informative)
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).
Pthreads (Score:3, Informative)
Re:Qt (Score:1, Informative)
I agree. I was responsible for maintaining a cross platform application (Windows, Linux, and MacOS) and it was built on Qt. Why the OP did not simply do a google search on the subject confounds me. Cross platform UI tools have been around for as long as there have been 2 or more UI platforms.
Qt or GLib (Score:3, Informative)
Either one is an exceptional choice.
Boost (Score:5, Informative)
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.
Re:Boost? (Score:5, Informative)
Boost has pretty strong threading support [boost.org], which is the basis for the threading capabilities in the forthcoming revision of the C++ standard. Boost also has cross-platform IPC [boost.org] and socket [boost.org] libraries. It would be a good choice for the OP, I think.
Re:Qt (Score:5, Informative)
I concur. My Qt-powered multithreaded and networked (TCP&UDP) application is compiling and working nicely in linux, osx and win32 without any os-specifc #ifdefs.
Re:Qt (Score:2, Informative)
As someone working on a massive project... (Score:5, Informative)
Re:Qt (Score:1, Informative)
I hate replying to myself, but forgot one thing:
If you want to know what Qt has to offer without downloading it, you can check out their documentation online:
http://doc.trolltech.com/4.5/
Take a look at the list of classes as well.
Don't worry, you can disable the modules you don't need (including the GUI) to reduce the overhead.
Re:Apache Portable Runtime (Score:3, Informative)
APR:
http://apr.apache.org/ [apache.org] http://en.wikipedia.org/wiki/Apache_Portable_Runtime [wikipedia.org]
Re:Qt (Score:2, Informative)
OP didn't say anything about UI, as you'd surely know if you had bothered to read the summary:
What I actually need is a platform independent lib covering Windows and Linux variants to handle sockets, IPC and threads abstractions
I wrote my own little socket class in C++ that does the Windows/Linux abstraction for me; they're mostly the same anyway, unless you want to get into epoll and such. I had planned to write a similar class for threads, but the idea is not exactly appetizing. I'm told boost has a thread class that might do the trick.
Re:Qt (Score:4, Informative)
Point for point:
- sockets [nokia.com]
- IPC [nokia.com]
- threads abstractions [nokia.com]
- Database [nokia.com]. Well, not quite so simple, but Sqlite3 as backend is available.
Re:Qt (Score:2, Informative)
Or GTK. Or specifically, gtkmm. Recent builds of GTKmm and Glibmm include stuff for handling sockets (Gtk::Socket). threads (Gtk::Thread, Gtk::Mutex, etc.) and IPC (GTK::Plug). Don't forget the GIO stuff, too.
Re:Boost (Score:5, Informative)
SQLite databases are small, powerful and platform independent and might be a good choice to fit your database needs. The code is public domain.
Re:Qt (Score:5, Informative)
OP didn't say anything about UI, as you'd surely know if you had bothered to read the summary:
QtCore has more or less nothing to do with UI.
Re:Apache Portable Runtime (Score:5, Informative)
Re:Qt (Score:3, Informative)
It's LGPL (So it's free for commercial projects as well)
I'm sorry to nitpick, but this is an important distinction. You can use GPL code in a commercial project. I don't think that there's any dispute that RHEL is a commercial product. LGPL allows you do use code in proprietary projects.
LK
wxWidgets might work (Score:3, Informative)
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.
You might want to look at Zoolib (Score:3, Informative)
Zoolib at Source Force [sourceforge.net] 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. [goingware.com]
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.
Re:TBB works wonders for threading (Score:4, Informative)
From the FAQ - http://www.threadingbuildingblocks.org/wiki/index.php?title=Licensing [threadingb...blocks.org]:
Re:C++ is so old school... (Score:4, Informative)
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 [wikipedia.org] 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 [hhtp] 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++).
Apache Portable Runtime (Score:4, Informative)
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.
Re:C++ is so old school... (Score:5, Informative)
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.
Re:Boost and POCO (Score:2, Informative)
No, POCO is not very good. The documentation is poor, and it's buggy.
Re:TBB works wonders for threading (Score:4, Informative)
You're quoting from the commercial license. TBB is quite explicitly dual-licensed. If you don't like the terms of the commercial license, you have the option to use it under the terms of the GPL v2.
Re:Microsoft POSIX Subsystem (Score:2, Informative)
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.
UGH (Score:1, Informative)
Re:Qt (Score:1, Informative)
No it doesn't, but it does allow you to link against it. There's a difference. If you wan't to use open source in a proprietary project then you'd have to go with something like the BSD license.
Re:Boost and POCO (Score:3, Informative)
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.
Poco is your answer (Score:1, Informative)
Re:Cygwin or UWIN (Score:4, Informative)
If you want "close to the metal" POSIX API compatibility then there's Cygwin
Ok, but this is borderline 1990s thinking or a bit insane...
You would be better off telling the person to just use the SUA of NT and develop a full *nix OSS solution and ignore Win32. As this is effectively what you are getting with Cygwin, except the SUA of NT is a full BSD subsystem that DOES RUN AT METAL 'so to speak' and doesn't have all the horrible 'kludges' of Cygwin.
I mean seriously, I think people forget that NT does a very good V5 and BSD Unix already, that is far beyond POSIX compliance and yes even beyond Cygwin crap.
----
To give a good answer to the OP, it would help to know what they are doing a bit more, as just knowing if they ware writing GUI or non-GUI code makes a BIG difference in picking a common or easily portable library. Also performance, what kind of performance do they need? Depending on what they are doing I could recommended truly using the SUA or Java or *gasp* .NET via Mono or QT or a ton of other solutions that do work and work well. Hell they might be doing an application can should be shoved into something like Silverlight.
Re:As someone working on a massive project... (Score:3, Informative)
Agreed, but you left out one crucial reason: If you use Boost today, this maximises your chances that your code won't need very much porting to work with the C++ standard library of tomorrow.
I'd like to agree here, but IME autoconf and Boost.Build don't work so nicely together.
POCO project (Score:2, Informative)
Re:Qt (Score:3, Informative)
Qt is okay for networking applications, but in my experience Boost has much, much better performance, not to mention better support for things like multicast without creating some hacks. Qt ends up using a lot of Qt specific classes internally to create buffers and network functions, so it ends up being slower than Boost which seems to act more as a wrapper than anything.
But does Boost provide behind the scenes threading?
One of the things I've noticed with Qt is that they went out of their way to make the best possible performance. There's a lot of Qt classes (such as QTcpSocket) that implement threading behind the scenes so the performance is really hard to impact your application with (not impossible but a lot harder).
Additionally, while there are a lot of things you do need to use the Qt classes for, it's typically very easy to convert many of those classes to and from C++ STL. Nearly all classes that have an STL equivalent have a function to convert the class to that STL equivalent or to to be initialized by an STL equivalent.
Furthermore, you can easily intermix Qt Signals/Slots with other Signal/Slots implementations - such as the version provided by Boost. If you use the standard terminology then Qt will gladly use the third party Signals/Slots mechanisms itself; otherwise, you can use a couple macros (Q_SLOTS, Q_SIGNALS) to specify that you always want these signals/slots to be run via the Qt Signals/Slots.
Honestly, I can't say that any other API platform has so much provided and so many methods for working with language native and third party mechanisms.
The only thing that took a little getting use to was: (i) using a lot of pointers without having to keep track of quite all of them since the Qt Object Meta-systems does a lot of the cleanup for you (so long as the QObject has been parented), and (ii) Signals/Slots across threads requires a special QThread class implementation that only has signals with an internal class instance that has the signals/slots you would normally expect. Otherwise, Qt is the most intuitive, well documented, platform agnostic, and high performing framework out there.
Try TnFOX (Score:2, Informative)
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