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?"
JAVA (Score:3, Insightful)
This platform independent lib you are looking for is called JAVA.
Re:JAVA (Score:4, Interesting)
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.
Re:JAVA (Score:2)
Re:JAVA (Score:2)
There are C->Java converters.
But if you need interoperability and work on multiple platforms, there is nothing like Java.
You can use JNI if you have to rely on C code, but virtually every library you could need has been programmed in Java.
Re:JAVA (Score:3, Insightful)
One thing that appears to be a requirement is this must be a library for C++.
There are C->Java converters.
Let's play spot-the-difference!
Re:JAVA (Score:2)
For emulating embedded hardware on Windows? This is clearly a new definition of the word "work" that I wasn't previously aware of.
Re:JAVA (Score:2, Funny)
I don't think you know what that word actually means. Let me look it up for you:
Main Entry: moron
Pronunciation: \mor-än\
Function: noun
Etymology: irregular from Greek mros foolish, stupid
Date: 1910
1 usually offensive : a person affected with mild mental retardation
2 : a very stupid person
3 : someone who uses a cross-platform language to solve a cross-platform problem
Oh snap. They've gone changed the definition of moron - so I guess you were right!
Qt (Score:5, Insightful)
Nokia QT rocks...
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:3, Interesting)
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.
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.
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:Qt (Score:5, Interesting)
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.
Re:Qt (Score:2)
> The only thing I found a bit annoying was that it didn't integrate well with the STL.
Is there anything that does? Boost has some alternatives to STL classes, and I'm sure Qt has as well.
STL has a nice API, but that's about it.
Re:Qt (Score:2)
A gui is loaded real time from an xml file - I'm not so sure I like that implementation.
You don't have to go that route. You can construct a UI from API calls just like any other toolkit.
FWIW, I prefer using Mono & Gtk# over anything else when I develop in Linux. Though, that's not saying much.
Re:Qt (Score:2)
FTFY. See the GtkMM Documentation [gtkmm.org] as well as the mainline GTK [gtk.org] documentation.
FTFY :p
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: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:Qt (Score:2)
Correct. C++0x will have native support for threads, based largely on Boost threading libraries, but with some differences, and the potential for better support of some features, by adding support to the language core.
Re:Qt (Score:2)
Re:Qt (Score:4, Funny)
Mono on windows isn't there yet.
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.)
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:Boost? (Score:2)
Boost ... is the basis for the threading capabilities in the forthcoming revision of the C++ standard.
It's probably the other way around, see the Boost thread documentation [boost.org]. In any case, it's much easier than using pthreads' C API, and I think the feature set is approximately the same as pthreads.
Re:Boost? (Score:2)
[citation needed]
Re:Boost? (Score:2)
I was under the impression that Boost didn't even accept libraries that weren't coded according to Boost's style?
Re:Boost? (Score:3, Interesting)
That's correct. Boost has the most stringent code review practices of probably any open source project.
This seems like an anti-open-source thing to do, but it's critical considering what Boost has to do. It's partly that library of infrastructure that all serious C++ projects need before they start, and partly the place where additions to the standard library are born. Boost development is slow, but Boost code is bulletproof.
Re:Boost? (Score:2, Funny)
No, USE Boost for exactly those reasons. It's an extremely advanced library, and working with it will quickly make you a much better C++ programmer.
Re:Boost? (Score:2)
many choices (Score:2, Interesting)
NSPR [mozilla.org], APR [apache.org], boost [boost.org] system, threads
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).
Re:Qt (Score:2)
Use Qt.
Seconded.
Note: you can also use just QtCore, without QtGui, if you don't need the gui parts.
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
Re:Qt (Score:2, Informative)
Pthreads (Score:3, Informative)
Re:Pthreads (Score:3, Interesting)
pthreads-win32 is excellent, but regrettably, LGPL licensed. It's interesting to note how complex it has to be to give you POSIX semantics [wustl.edu] --- pre-Vista win32 threading primitives are fundamentally flawed [msdn.com].
Vista, on the other hand, gives us brand-new innovative 21st-century Microsoft technologies like condition variables [microsoft.com].
Re:Pthreads (Score:2)
What is wrong with LGPL?
Re:Pthreads (Score:2)
The license is more complex than the GPL. It's more difficult to understand and is easier to lead to ambiguity.
For software developers writing closed source programs without access to a legal department, it can be daunting to determine if you have complied with the subtle LGPL requirements to keep your source closed.
If you're developing GPL applications with LGPL libraries, you have nothing to worry about.
Qt or GLib (Score:3, Informative)
Either one is an exceptional choice.
TBB works wonders for threading (Score:5, Interesting)
Intel Thread Building Blocks (http://www.threadingbuildingblocks.org/ [threadingb...blocks.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.
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: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.
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)
SQLite databases are small, powerful and platform independent and might be a good choice to fit your database needs. The code is public domain.
SQLite (Score:2)
You beat me to the suggestion.
SQLite [sqlite.org] is a very powerful SQL database engine that is highly powerful and comes in a single < 500K library. No server needed.
Interfaces to it exist for most modern languages.
Documentation for the C/C++ API is here [sqlite.org]
A more C++ friendly wrapper for SQLite is on CodeProject [codeproject.com]
ACE is great! (Score:2)
I've had great experiences with ACE. I found ACE to be dependable and extensive. You don't even have to use the higher level design patterns to get the platform independence.
If you're targeting *only* Windows and Linux, then Qt may also be a good option. I'm not sure if you can strip out the GUI stuff if you don't need it.
Re:ACE is great! (Score:3, Interesting)
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.
Re:ACE is great! (Score:2)
QT allows use of just the core libraries, so that's not a concern. Why do you talk about "only" targeting Windows or Linux, though? QT runs on OS X, WinCE, and other platforms as well. For example, if Skype runs on it, you can bet QT does too.
Re:ACE is great! (Score:2)
Re:ACE is great! (Score:2)
I've had the impression that ACE supports more exotic platforms, but your question prompted me to check what platforms Qt will run on-- how long has Qt supported VxWorks? I guess a lot has changed recently. I suppose an in-depth comparison of ACE and Qt is warranted. Still, I have enjoyed using ACE.
As someone working on a massive project... (Score:5, Informative)
Re:As someone working on a massive project... (Score:3, Insightful)
Ugh. Autoconf & automake are the most horrible things I've tried to use in recent times. These tools are far from simple and what works with newer versions of the tools isn't even compatible with older versions. The syntax is antiquated and there are multiple ways to achieve the same thing each with different pitfalls.
Somewhere there is a meteorite set to strike autoconf. I hope it gets here soon since it's about 20 years late...
Re:As someone working on a massive project... (Score:5, Funny)
it is all well and good, but he cannot even read options 3,4 and 5 because of your recursion!
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.
Boost and POCO (Score:2)
Re:Boost and POCO (Score:2, Informative)
No, POCO is not very good. The documentation is poor, and it's buggy.
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.
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.
Re:wxWidgets might work (Score:3, Insightful)
It also does infuriating bugs. Programs that work fine with small amounts of data explode when you get them into production. Doom!
And why, exactly, are your programs not exposed to realistic data sets until they are in production? I don't think you can blame wxWidgets for that massive failure.
--BOOST --ACE (Score:2)
As others have said BOOST is good. Also, I really didn't care for ACE and eventually gave up on it.
Re:--BOOST --ACE (Score:2)
Ack phooey, that was supposed to be ++BOOST...
JNetLib (Score:2)
Cygwin or UWIN (Score:5, Interesting)
Combine this with OpenGL [opengl.org], OpenAL [creativelabs.com], the SDL [libsdl.org] and Cygwin/X [cygwin.com], QT [nokia.com], a Java layer using the SWT [eclipse.org] from Eclipse, *shudder* GLUT [opengl.org] *shudder*
jdb2
Re:Cygwin or UWIN (Score:2)
Re:Cygwin or UWIN (Score:2)
Cygwin is a huge pain. Yeah, it sort of gives you a POSIX environment, but good luck getting anything to actually compile under it without hours of frustration.
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.
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.
Sorry, C variants aren't trendy... (Score:5, Funny)
C++? Too simple.
Re:Sorry, C variants aren't trendy... (Score:2)
I'd give anything for mod points right now. :)
Re:Sorry, C variants aren't trendy... (Score:2, Interesting)
C++ has a lot of properties, but "simple" is hardly one of them. It's got so much stuff munged into it that the spec contains literally hundreds of pages special-casing bad interactions between features, and it takes a gigantic effort just to determine the type of an expression. Parsing C++ is actually not only not context-free, but undecidable, in general. It takes a heroic effort to determine whether A f(B,C); is a function declaration, or a call to a constructor. Static resolution rules are horrifically complex. The interaction of templates with everything else in the language is riddled with pitfalls. Etc.
Re:Sorry, C variants aren't trendy... (Score:4, Funny)
>> It's got so much stuff munged into it that the spec contains literally hundreds of pages special-casing bad interactions between features, and it takes a gigantic effort just to determine the type of an expression.
Yeah I'm so glad Java came along... oh wait...
whoosh? (Score:2)
GP was being sarcastic?
And maybe a little (more than a little?) critical of AJAX, et. al.?
Maybe?
Re:Sorry, C variants aren't trendy... (Score:3, Interesting)
C++ has a lot of properties, but "simple" is hardly one of them.
We use Qt at my job for creating servers, daemons, interacting with hardware as well as doing GUI stuff. You don't really need to use the fancy C++ stuff, it's OK to just use the Qt classes and be done with it. Our code almost looks like Java, so simple.
Yu left out one #ifdef (Score:3, Insightful)
#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.
Just use POSIX (Score:2, Insightful)
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.
Boost and sqlite (Score:4, Interesting)
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.
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.
SQLite for database (Score:3, Interesting)
MONO (Score:2)
mono *ducks*? (Score:2)
Is that the name of some kind of portable library?
Heh, ACE is for old foggies (Score:2, Insightful)
Another couple of options (Score:3, Interesting)
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.
Your App Will Suck Anyway: So Use Java (Score:2, Funny)
Java, Perl, and WxWidgets... (Score:3, Insightful)
...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...
qt4 (Score:2)
dito.
what does a database have to do with flash? (Score:2)
And a rock solid but simple embedded database to emulate flash memory.
This part I don't understand... flash is a hardware solution to persistant storage. An embedded database is a software solution to structured storage of data. The two are completely orthogonal.
Ignoring the flash part, I have used sqlite on several embedded projects (set top boxes) and it has done the job. Depends on your requirements though - is the priority speed, space, ease of use/API, etc?
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:Apache Portable Runtime (Score:5, Informative)
Re:Cross platform? USE JAVA, duh! (Score:2)
Everyone - Use this mish-mash of open source libraries and/or reinvent the wheel when you have to with interfaces and separate code files for OS specifics.
You don't need "mish mash" if libs if you use Qt.
Get with the program. Java isn't "special" anymore.
Re:Cross platform? USE JAVA, duh! (Score:2)
Considering Eclipse is probably the most widely used IDE in the world, do you have anything to back up your claims?
Re:Cross platform? USE JAVA, duh! (Score:2)
yeah, it's only part of the leading smartphone stack (Android, J2ME, etc), a large number of the top 10-20 most popular apps on sourceforge, runs most of the world's largest enterprise applications and runs most of the big software IDEs.
It's all hype! Yeah, Java!
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++).
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:Qt, Wx, pain (Score:2)
Re:Qt, Wx, pain (Score:2)
"Embedded hardware" can mean anything--Python may be fast enough. And if it isn't, you can still write an emulation library in C and everything else (I/O, parsing, user interface) in Python.
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.
Re:Unfortunately probably not worth it (Score:2, Troll)
Java uses native thread exclusively. Anything you can do in C++ with threads, you can do faster and safer in Java.
Python has no ability to uses threads in a practical sense, due to Python GIL.
Re:Unfortunately probably not worth it (Score:2, Interesting)
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
Re:Unfortunately probably not worth it (Score:2)
In newer versions of OpenJDK this is not true.
Although in current use (java 6 et al), you're correct.