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?"

Comments

JAVA

[Anonymous Coward]

This platform independent lib you are looking for is called JAVA.

Re:JAVA

[HiThere]

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

[AmberBlackCat]

One thing that appears to be a requirement is this must be a library for C++.

Re:JAVA

[buchner.johannes]

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

[Jeremy Visser]

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

[Anonymous Coward]

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!

Re:JAVA

[Pseudonym]

Ruby, Python, even some dialects of Basic would work.

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

[Simon80]

C++ is actually cross-platform, if you only use portable libraries - which brings us to the original poster's question. It sounds to me like he might want to use Qt - since 4.5 it's been LGPLed, and it has socket and threading abstractions, though I don't know if it has IPC functionality. If ACE has a sane API, then there's no need to look for something newer, but if you want to have a GUI for your software, you'll want to use Qt anyway.

Re:JAVA

[vurian]

Yes, Qt has IPC capabilities

Re:JAVA

[sg_oneill]

He's doing hardware emulation. Something as harsh as 3d gameing for CPU abuse. Java is not really a good suggestion here at all.

Re:JAVA

[ByOhTek]

He said he wanted portable. Admittedly you have to recompile for each OS, but that's better than Java's solution (write their own goofy SSL implementation, though it's available on all platforms as OpenSSL, use the platform's Regex library, though it is not consistent in all platforms).

> sockets
Use the MinGW compiler (or cygwin) in windows, alternatively LibSDL has a socket library. I think there are other Berkley Socket libs for Windows.
> IPC
Probably would work with MinGW. Not sure what this is to be honest, though.
> threads
Uise the MinGW compiler (or cygwin) in windows, alternatively LibSDL has a thread library. Also, there is a pthreads implementation in Windows.

Re:JAVA

[bugnuts]

Toys like cellphones can run java, but critical applications need a little more certainty and horsepower.

You can always throw more cpu horsepower at it, but the parent is right about Java having issues with timing. The thing is, it's difficult to schedule garbage collection, and the OP said he was looking at embedded devices.

If any sort of real-time system is needed, you could be hosed. Java is not deterministic, and might not do what you want it to do within the time constraints that many embedded devices have. Imagine your front bumper's accelerometer goes crazy, crush sensors determine you're in a major crash, and Java is doing garbage collection instead of deploying the airbag.

Re:JAVA

[HiThere]

Yeah, after posting I realized I should have remembered more carefully. I remembered the portable, but ...

Still, it *does* depend on what's being embedded into what. An elevator controller using a 386 chip could run basic or python and still meet the speed requirements. This clearly isn't being what it considered, as his prior language was C++ and he's talking about "emulating embedded hardware on Windows. " I can read that in a couple of different ways. It could be (most probable) that he's writing a program to run on MSWind and emulate the action of hardware. If that's the correct reading, then Python wouldn't be a totally inappropriate choice. Of course, that raises the question of why the library needs to be portable, but he might be looking to port the code in the future.

So my answer wasn't totally inappropriate even with fuller consideration.

If, on the other hand, he meant to emulate running hardware connected to, or, perhaps, running a MSWind OS ... then the only answer that occurs is Qt...and I don't know if that handles what he needs.

Re:JAVA

[khellendros1984]

IPC is "inter-process communication". Passing information between different processes and/or threads, for instance.

Re:JAVA

[ByOhTek]

Thanks. All I could think of was "instructions per second", and I knew that wasn't what the submitter was talking about.

Re:JAVA

[badkarmadayaccount]

There are real time JVMs, if only someonewould check the frigin' Wikipedia entry...

Re:JAVA

[domKing]

Actually, "this platform independent lib you are looking for is called" the Java API.

Lately, it's increasingly being made available for languages besides the Java language. And, yes, native C++ is one of them. The core Java APIs (java::lang, java::io, java::util) can be used directly from C++ without requiring a JRE or VM for development or deployment.
NewJ for C++: Java API for Native C++

Positives: The library is small in size and light in resource usage. Objects are managed deterministically much like C++ smart pointers and not at the whim of the GC, which may be very important for embedded systems. Applications can be deployed as a single .EXE to a flash drive and run directly.

Negatives: Presently, java::net API classes are a work in progress, and there's no Linux version. Presently, it's only for Win32 and Windows Mobile.
NewJ: FAQ

Qt

[Anonymous Coward]

Nokia QT rocks...

Re:Qt

[Anonymous Coward]

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.

Re:Qt

[KirstuNael]

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

[Anonymous Coward]

Remember one thing about LGPL. It requires that that user can replace the LGPL binary. So Qt released under LGPL must be a separate dll, no static linking.

Although, I cannot understand how iPhone and its apps get by this license requirement.

Re:Qt

[d235j]

Simple: They post source code at opensource.apple.com and since they keep away from LGPL 3, they can use signing to, in effect, do "tivoization." And the iPhone and apps have dynamically linked libraries.

Re:Qt

[noidentity]

Remember one thing about LGPL. It requires that that user can replace the LGPL binary. So Qt released under LGPL must be a separate dll, no static linking.

Or you could provide the source code for your program, or perhaps the .o files (if you like angering your users).

Re:Qt

[Anonymous Coward]

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:Qt

[ultrabot]

Use Qt.

Seconded.

Note: you can also use just QtCore, without QtGui, if you don't need the gui parts.

Re:Qt

[HeronBlademaster]

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

[Anonymous Coward]

Point for point:

- sockets
- IPC
- threads abstractions
- Database. Well, not quite so simple, but Sqlite3 as backend is available.

Re:Qt

[morgan_greywolf]

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

[rtfa-troll]

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

[zach_the_lizard]

I was about to recommend this, too. It has SQL plugins. The framework can handle networking, graphics, GUIs, scripting, and even threading. And if you write your application well enough, it is possible to compile it for multiple platforms with no or little changes. I've got a cross-compiler set up on my Linux box, and I use it to compile the Windows versions of some of my apps. WINE can also be used for basic testing, though I would always test in on a real Windows machine (or several).

Re:Qt

[Lord Kano]

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

[zach_the_lizard]

Qt is a framework, not just a GUI library. The QtCore classes can be used without any dependencies on the QtGui classes. And yes, Boost does have a threading class or two. I think it is even being adopted for the next C++ standard.

Re:Qt

[Tacvek]

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

[NoYob]

GTK doesn't have the well written documentation that Qt has.
The build environment is overly complicated. It took me a few hours hunting down dependencies to get a damn hello world gui program to work.. They have the includes all over the place. And there was a bunch more. Glade isn't intuitive at all. A gui is loaded real time from an xml file - I'm not so sure I like that implementation.
I gave up on Gtk.
And, isn't it really a C framework with a C++ front end?

Re:Qt

[jmv]

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

[FreezeS]

How did you get the list of network adapters ?

Re:Qt

[morgan_greywolf]

GTK didn't used to have the well written documentation that Qt has.

TFTY. See the GtkMM Documentation as well as the mainline GTK documentation. The newer documentation, including that for the PyGTK Python bindings, is some of the best-written API documentation I've ever seen.

Re:Qt

[Xtravar]

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

[Anonymous Coward]

LGPL allows you do use code in proprietary projects.

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:Qt

[ari_j]

I like that it's still called C++0x. Are they going to publish the final standard in the next 80 days?

Re:Qt

[Lord Kano]

You are correct. I didn't properly explain the difference.

LK

Re:Qt

[digitalunity]

Mono on windows isn't there yet.

Re:Qt

[zach_the_lizard]

What about it doesn't integrate well with the STL? I've encountered a few strange things, but I'd like to here about what sorts of issues you've encountered.

Re:Qt

[Doppler00]

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

[Anonymous Coward]

Because, I mean, why would you go for a totally free and unencumbered platform that natively supports the language you want to use, when you could get a patent-heavy proprietary platform, controlled by a corporation with a history of making patent threats towards open source products, that only supports a proprietary and non-standard version of your language, and for which the open source implementation is immature and incomplete?

Oh, wait, I think I answered my own question.

Re:Qt

[KirstuNael]

I didn't.
It was not required for my app to know about network adapters. Is that possible to do in cross-platform way using Qt -- I have no idea.

Re:Qt

[odourpreventer]

> 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

[quantumphaze]

FTFY. See the GtkMM Documentation as well as the mainline GTK documentation.

FTFY :p

Re:Qt

[dcollins117]

To which the trolls will respond: but you can use Boost as a layer under cute.

That's not so much a troll as an astute and rather helpful suggestion.

Re:Qt

[jmv]

There's no issue in particular, just the fact that it uses QString instead of std::string, QMap instead of std::map, and so on. That's annoying, but you learn to live with it.

Re:Qt

[Simon80]

You don't. When you tell your network stream instance to interpret the next four bytes as integers (as in stream >> myInt32), the function responsible for that is perfectly capable of swapping the bytes for you. If you have to deal with endianness directly, you're definitely not using enough abstraction.

Re:Qt

[mrwolf007]

Whats the problem?
The x in C++0x isnt decimal, its hexadecimal.

Re:Qt

[mehemiah]

he probibly ran into missing documentation on the stuff he wants. Among Open Source projects, this is often what seperates Django from Rails ... click on the links to see which one I think is better, or make your own judgment call. http://library.gnome.org/devel/gtkmm/unstable/

Re:Qt

[TemporalBeing]

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

[iSeal]

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

*ahem*

And if you bothered to read what Qt was about, then you'd realize that Qt is in fact a platform independent lib covering Windows and Linux variants to handle sockets, IPC and threads abstractions (as well as a whole lotta other things.)

Classes that Qt offers:
http://qt.nokia.com/doc/4.5/classes.html

Re:Qt

[HeronBlademaster]

My response was based on my parent post's emphasis on UI and cross-platform UI tools :P

Re:Qt

[Draykwing]

GP using the word 'troll' could have been a cleverly constructed joke, seeing as prior to being bought by Nokia, the employees at TrollTech were known as 'the trolls'. Not sure I believe it is a joke, though.

Re:Qt

[quantumphaze]

I was aiming for Funny by pointing out that he spelt FTFY (TFTY) wrong. Being a FTFY post it should count for some level of irony.

Anyway, many of these projects could be so much more useful and even get outside contributions if the docs were in better shape.

Re:Qt

[mehemiah]

Ok, I should have replied to parent. (I forgot what that stood for, now that I remember, it was indeed funny)

Re:Qt

[mehemiah]

he probibly ran into missing documentation on the stuff he wants. Among Open Source projects, this is often what seperates Django from Rails ... click on the links to see which one I think is better, or make your own judgment call. http://library.gnome.org/devel/gtkmm/unstable/

Re:Qt

[agbinfo]

I realize that we're way past '07 but shouldn't the x be octal since the number starts with a 0 (zero). Then again, 4000 octal is 2048 decimal so maybe they're still early.

Boost?

[piojo]

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?

[Homburg]

Boost has pretty strong threading support, which is the basis for the threading capabilities in the forthcoming revision of the C++ standard. Boost also has cross-platform IPC and socket libraries. It would be a good choice for the OP, I think.

Re:Boost?

[QuoteMstr]

[citation needed]

Re:Boost?

[Profane MuthaFucka]

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?

[mwvdlee]

I was under the impression that Boost didn't even accept libraries that weren't coded according to Boost's style?

Re:Boost?

[incripshin]

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. 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?

[alexmin]

Boost rocks. Using it on win & lin for few years already. Currently planning to replace ACE with it. Take a look at AIO and Thread libraries, that what you need. As a bonus you get to know all other juicy libs like bind, lambda, format, date_time etc.
There are a lot of new stuff added to boost in past couple of years so it's definitely worth a look.

Have only one issue with it - jam.Why, why did they decide to stick with homegrown, badly documented, convoluted python-based build system????

Re:Boost?

[i.of.the.storm]

Err, isn't that how you normally do it? Eg. to link in the math lib you add -lm.

Re:Boost?

[Pseudonym]

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?

[oxygen_deprived]

I second that.While I am not on embedded, my product does linux, osx, hpux, aix, solaris and windows. We started shifting to boost ( threads, serialization ,filesystem ) about 3 years ago in bits and pieces. The code is so much cleaner, easier to understand, and reliable. You may have some work to do to move to your platform (embedded is a different animal AFAIU ). The downside would be the app footprint and maybe a bit of performance hit (may be noticeable on low spec devices )

many choices

[Anonymous Coward]

NSPR, APR, boost system, threads

Qt

[Anonymous Coward]

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

[SoftwareArtist]

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).

Re:Pthreads

[QuoteMstr]

pthreads-win32 is excellent, but regrettably, LGPL licensed. It's interesting to note how complex it has to be to give you POSIX semantics --- pre-Vista win32 threading primitives are fundamentally flawed.

Vista, on the other hand, gives us brand-new innovative 21st-century Microsoft technologies like condition variables.

Re:Pthreads

[bcmm]

pthreads-win32 is excellent, but regrettably, LGPL licensed.

What is wrong with LGPL?

Re:Pthreads

[digitalunity]

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.

Re:Pthreads

[Svartalf]

..and if you're not statically linking and not restricting reverse engineering or laying claim to patent coverage in a way that you prevent downstream use of the stuff you supply- along with providing any mods to the library...there's no other issues to speak of.

There's no "subtle" about LGPL any more than there is to GPL, really. GPL's just slightly more restrictive.

Re:Pthreads

[gauauu]

What is wrong with LGPL?

For a statically-linked proprietary C++ application? Everything. You have to allow the user to re-link against a different version of the library, which basically means distributing object files for each of your source files. It's terrible.

For things like java that always link libraries dynamically, it's fine. If the library you are linking against is a dll or shared object, it's fine. Otherwise, it's terribly annoying.

My example: I was developing a homebrew game for Gameboy Advance. In that case, everything gets linked into one single rom image. The music library I considered using was LGPL. If I had used it, I would have had to distribute object files for my whole game, instead of simply distributing the rom image. So that library got disqualified because of the LGPL license.

Re:Pthreads

[TheSunborn]

Can you not just distribute the static linked version, and then include an offer for a version that is dynamic linked with QT?. In most cases, nobody will want the dynamic linked version so you don't really have to do anything. And if somebody really contact you and want a dynamic linked version of your program, you should just need to change a single parameter and do a make, and send them the dynamic linked version.

Qt or GLib

[ciroknight]

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.

TBB works wonders for threading

[Wrath0fb0b]

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.

Re:TBB works wonders for threading

[non-e-moose]

"You Lie!" They are NOT GPL-ed. The License is explicitly ANTI-GPL. Read it.

Re:TBB works wonders for threading

[Wrath0fb0b]

From the FAQ - http://www.threadingbuildingblocks.org/wiki/index.php?title=Licensing:

TBB is available under the common OSS license GPL v2 with the libstdC++ Runtime Exception. This is the same license used for a variety of well-known OSS applications including MySQL, NetBeans, and the Linux kernel.

Re:TBB works wonders for threading

[non-e-moose]

RTF License, not the FAQ. Explicitly: An "Excluded License" is one that requires, as a condition of use, modification, or distribution, that (a) the code be disclosed or distributed in source code form; or (b) others have the right to modify it; or (xi) include the Redistributables in malicious, deceptive, or unlawful programs.

Re:TBB works wonders for threading

[PCM2]

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:TBB works wonders for threading

[BhaKi]

works on any ISO-compliant C++ compiler

Does the generated code run on AMD processors perfectly? Intel has done many anti-competitive things and I'd be surprised if code generated by TBB works perfectly on non-Intel processors.

Re:TBB works wonders for threading

[Dog-Cow]

I understand where you are coming from on this, but either the CPU is Intel-compatible or its not. Unless TBB includes assembly code, it's rather unlikely they could write C++ that is intentionally crippled on AMD CPUs.

Boost

[aePrime]

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

[mls]

SQLite databases are small, powerful and platform independent and might be a good choice to fit your database needs. The code is public domain.

ACE is great!

[Arakageeta]

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!

[mallan]

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!

[Anonymous Coward]

Avoid ACE, it is really poor. Have you every tried to compile and build it on modern systems? It just does not build. It looks like the project has been abandoned to me.
I tried to build it on 5 modern UNIX OSs recently and they all failed. The main reason is that the C++ code is poor written and C++ is not very portable because the C++ compilers only implement parts of the standard.

Re:ACE is great!

[cbhacking]

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!

[TrancePhreak]

Skype is on PSP, is QT?

Re:ACE is great!

[Arakageeta]

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.

Re:ACE is great!

[old cob]

ACE is nowhere near abandoned. It is widely used on major RT systems such as weapons, telecom and finance. It is now being used in medical systems (MRIs). It runs on all standard platforms and includes exotic RTOS which are tough to support. It is commercially supported by several organizations including the one I work for, OCI in St Louis. Malcolm Spence

Apache Portable Runtime

[boilednut]

APR

Re:Apache Portable Runtime

[boilednut]

APR:

http://apr.apache.org/ http://en.wikipedia.org/wiki/Apache_Portable_Runtime

Re:Apache Portable Runtime

[boilednut]

From the wikipedia articel:

APR was originally a part of Apache HTTP Server, but has now been spun off into a separate project of the Apache Software Foundation, and is used by other applications to achieve platform independence. The range of platform-independent functionality provided by APR includes:
* Memory allocation and memory pool functionality
* Atomic operations
* Dynamic library handling
* File I/O
* Command argument parsing
* Locking
* Hash tables and arrays
* Mmap functionality
* Network sockets and protocols
* Thread, process and mutex functionality
* Shared memory functionality
* Time routines
* User and group ID services

Re:Apache Portable Runtime

[quench]

thanks for the hint, but a function call with a handle as 1st arg ist really too c-ish even for me, I'll stick to Qt, ACE and Boost.
thanks anyhow for clearing up the technology!!!

Re:Apache Portable Runtime

[Boj]

APR is a noble effort, but it isn't even widely adopted in Apache projects - for example Harmony. A particular weakness of APR is that it assumes a UNIX environment with all the toys that brings with it. For example, the APR interfaces for signal handling are a poor match to those of some operating systems and people using them could find their code distinctly unportable.

As someone working on a massive project...

[QuoteMstr]

I'm working on a rather large cross-platform C++ project at the moment. Here are a few tips:

1. Use Boost. It's a very liberally-licensed, high-quality library from the people who created the C++ language itself. It contains a ton of cross-platform libraries that do lots of useful things, from threads to regular expressions to writing testsuites and parsing command-line options. If Boost provides a piece of functionality, there's very little reason not to use its version.
2. See rule #1.
3. If you need cross-platform code that isn't in Boost, at least use the following approach:
   • Create a common interface definition
   • In separate files, implement the interface in terms of various platforms' primitives
   • Keep platform-specific code out of the rest of your program; if you can help it, don't even include platform headers in most of your program
4. Use autoconf to handle platform idiosyncrasies. There are a ton of available macros to help detect things about a build platform.
5. Write testcases. You should write tests for all your programs, but it's especially important to do it for cross-platform code because it's easy to break something and not notice.

Re:As someone working on a massive project...

[Anonymous Coward]

Use autoconf to handle platform idiosyncrasies.

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...

[Anonymous Coward]

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...

[Pseudonym]

Use Boost. It's a very liberally-licensed, high-quality library from the people who created the C++ language itself. It contains a ton of cross-platform libraries that do lots of useful things, from threads to regular expressions to writing testsuites and parsing command-line options. If Boost provides a piece of functionality, there's very little reason not to use its version.

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.

Use autoconf [...]

I'd like to agree here, but IME autoconf and Boost.Build don't work so nicely together.

Re:As someone working on a massive project...

[Sneezer]

i agree with the parent's other points but i strongly disagree with this one:

Use autoconf to handle platform idiosyncrasies.

autoconf is gross and difficult to use on Windows.

i use CMake at work and like it well enough. it works well enough with Qt that KDE uses it for their build system.

Re:As someone working on a massive project...

[larytet]

Emlib is a thin wrapper. No sockets though. http://larytet.sourceforge.net/

Re:As someone working on a massive project...

[larytet]

VLC (videoLAN) uses wxWidgest Multi-thread application which is fairly close to what embedded application looks like

Re:As someone working on a massive project...

[aminorex]

> 4. Use autoconf...

OMFG.

Re:As someone working on a massive project...

[QuoteMstr]

What's wrong with autoconf?

No, seriously --- people like to complain about the syntax, but using a shell script makes it flexible. What's so bad about it? Autoconf has been used for decades by thousands of software projects. It can't be all that bad, can it?

Re:As someone working on a massive project...

[DiegoBravo]

> chances that your code won't need very much porting to work with the C++ standard library of tomorrow.

Don't worry. For the C++ standards committee people, "tomorrow" means what ten years is for the rest of us.

Re:As someone working on a massive project...

[b4dc0d3r]

I bought the wxWidgets book and read it, hoping to be enlightened beyond all measure to discover a wonderful new paradigm of cross-platform application writing. I have been looking at this since I read a seemingly homebrew "XP: Cross Platform Programming" or something like that, during the days of Windows 98/ME.

I was sorely disappointed. It's basically MFC ported to Linux. I can't even remember what I hated it at this point, it's been so long, but I look at that book with disappointment and derision when I sort through my library from time to time. I'd give or throw it away, but I take the risk that someone might accidentally read it, so I've taken on the burden of keeping that copy at least safe from prying eyes.

GTK was too much casting for my tastes, and Qt had licensing issues. Now that Qt is open, I see no reason not to use it.

Re:As someone working on a massive project...

[b4dc0d3r]

I personally don't believe it's portable at all. I've been told it is, but maybe I have my environment all wrong. When I download something that uses it, I usually end up building my own makefile, having it not work, and moving on to another project.

Maybe it's running Windows that's my problem, but I've never had success without basically re-installing Cygwin from scratch before each use. Then I have hundreds of MB of stuff, just to compile a few hundred kB into a 40k app. No thanks. If I were doing Unices only, maybe it might be better.

Re:As someone working on a massive project...

[Pseudonym]

Or to put it another way, next Debian release.

Boost and POCO

[Adam Hazzlebank]

Boost ( http://www.boost.org/ ) is good I also hear nice things about POCO http://pocoproject.org/

Re:Boost and POCO

[Profane MuthaFucka]

No, POCO is not very good. The documentation is poor, and it's buggy.

Re:Boost and POCO

[gbjbaanb]

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.

Re:Boost and POCO

[vanye]

I agree on the documentation - Poco has good reference docs, but its lacking a tutorial and other HOWTOs, so it can take a while ot get upto speed on its style.

Disagree on the bugs - we've been using it as the core library in our enterprise software product for several years with no issues.

Poco's clean, it gives me everything I need and it just works, what more do you want?

richard.

Re:Boost and POCO

[Profane MuthaFucka]

example: The PocoZip library looks really good at first. Easy to read a zip file from the disk.

BUT, what happens when you've got a zip file in memory that you're reading?

You try to use a string stream to read memory instead of an istream to read from disk. The thing makes moves like it's going to work, but soon face intractable bugs caused by the brain-damaged nature of what PocoZip uses for a zip input stream.

This situation is a bit beyond what a normal user might run into, but it's a sign that their implementation isn't robust enough to adapt to perfectly ordinary usage situations.

Re:Boost and POCO

[FatFreddie]

Documentation can always be better but I think it's quite good and I find the libraries pretty solid. My heating system uses POCO and that's not something I'd trust to buggy software :-) Generally I'm very pleased with it and particularly pleased with the cross platform support - no #ifdef's required.

Re:Boost and POCO

[Profane MuthaFucka]

Read the response to the other guy re: the zip library.

wxWidgets might work

[Beached]

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

[Profane MuthaFucka]

It also does infuriating bugs. Programs that work fine with small amounts of data explode when you get them into production. Doom!

Re:wxWidgets might work

[Thundersnatch]

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.

Re:wxWidgets might work

[Thundersnatch]

I don't know, I don't use WX at all, so I'm not dodging anything.

My point is that it is your fault that code made it into production. Everything has bugs, which is why you must test with realistic data sets, at all levels.

Clean up your own yard before knocking on your neighbor's door.

Re:wxWidgets might work

[Mafia$oft]

wxWidgets sockets: Linux: broken. Mac: broken. Windows: works (talking about multi-threading race conditions within the 3 layers of socket classes).

Morale of the story: use wx for GUI parts, but consider using something else for those non-GUI parts which it has trouble with or which are less likely to be properly served by a _GUI_ framework. For networking stuff, libcurl is VERY hard to beat (binaries for perhaps up to 50 (FIFTY) platforms, used by "all fortune 500", ...).

Spoken by someone who's been using wx all the time for 5 years now and generally likes it very much, but... well... you wouldn't let a butcher (GUI) take care about your dents (sockets) either, right!?!?

Re:wxWidgets might work

[radtea]

Programs that work fine with small amounts of data explode when you get them into production.

As the OP pointed out, testing is your friend.

I'm using wxPython on a project that has hundreds of items in a tree. No problems, although it's slower than I'd like, mostly due to interface overheads (pushing stuff through SWIG is expensive, and if I were to improve wxPython in any way it would be to add "batch" interfaces that would let me push a whole wack of stuff through to the C++ side with a single call.)

I've used wxWidgets on Windows for years, after years of Qt, and for what I do wx is great: solid, well-documented and extremely functional. Qt lost me with their license shenanigans a few years back, when TrollTech broke the lib up into parts and started charging for every little piece of it instead of selling the bundle. Fortunately, wx was just about ready for prime time about then--if you used wx more than a few years ago I can understand your frustrations, because it was really not ready for production code, but today it is definitely worth checking out unless you're already invested in Qt or really need to ship statically linked (it's my understanding that Qt is now LGPL).

Re:wxWidgets might work

[Profane MuthaFucka]

Hundreds of items? That's it? Put 150,000 in and your trees are going to have diagonal lines going everywhere, and crap all over the page.

Testing was indeed my friend. It said "USE QT."

The last time I touched WX it was about 6 years ago, and there's no reason to go back. Honestly, you say it's working, but they said it was working 6 years ago. And reports from people I trust who have worked with it recently indicate that my bug is fixed, but new bugs just as bad have been substituted.

And now I have 6 years experience with Qt, during which time I've never run across that kind of weirdness.

--BOOST --ACE

[sribe]

As others have said BOOST is good. Also, I really didn't care for ACE and eventually gave up on it.

Re:--BOOST --ACE

[sribe]

Ack phooey, that was supposed to be ++BOOST...

You probably do not want ACE

[Anonymous Coward]

ACE introduced a lot of neat concepts into the mainstream as far as I/O goes (the Reactor pattern came from ACE) but it's really quite crufty and showing its age. It's probably the best thing there is for wrangling heavily-threaded apps, but you'll have to deal with threads more than you'll care for. You'll find the APIs in Boost and QT to be a lot nicer.

As for Berkeley DB, it's very nice, battle-tested, and perfectly suited for the type of task you're looking at.

Re:You probably do not want ACE

[quench]

great summary, thanks!

JNetLib

[darkain]

http://www.nullsoft.com/free/jnetlib/ From the guy who initially made Winamp, he also made a lib called JNetLib which is a piss easy to use cross-platform C++ socket library. It also has pre-made classes for things like HTTP/HTTPS, to help speed things up, or to simply give you an idea of how to use the library. It is licensed under the BSD license, so you are basically free to use it for whatever you would like, commercial or otherwise.

Cygwin or UWIN

[jdb2]

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.

Combine this with OpenGL, OpenAL, the SDL and Cygwin/X, QT, a Java layer using the SWT from Eclipse, *shudder* GLUT *shudder* ;) or IMNSHO preferably wxWindows/wxWidgets and you've got yourself a full cross-platform programming toolkit that can do just about anything.

jdb2

Re:Cygwin or UWIN

[TrancePhreak]

Cygwin does terrible things with its DLL and explodes in certain evironments.

Re:Cygwin or UWIN

[Doppler00]

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

[TheNetAvenger]

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

[Orion Blastar]

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.

Re:You might want to look at Zoolib

[Orion Blastar]

I admit the Cookbook is incomplete but at least it is a start to get a look at Zoolib. Nobody else has tried to write a book or documentation on it yet. But The Zoolib page at Source Forge has more info and a mailing list to ask questions at.

Sorry, C variants aren't trendy...

[CptNerd]

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.

Re:Sorry, C variants aren't trendy...

[quench]

:)))

Re:Sorry, C variants aren't trendy...

[geekgirlandrea]

I'd give anything for mod points right now. :)

Re:Sorry, C variants aren't trendy...

[Trepidity]

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...

[JustNiz]

>> 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...

Re:Sorry, C variants aren't trendy...

[psYchotic87]

An onomatopeia comes to mind: whooooosh!

Re:Sorry, C variants aren't trendy...

[rubycodez]

what are you whining about, you'll see all those layers when when the compiler vomits six screenfuls of an error line. Just put a Bad Thing in the argument for your so-called unresolvable declaration. lazy git.

Re:Sorry, C variants aren't trendy...

[Sun]

Java is a language who's main design criteria was "C++ is used for horrible things, so lets make them impossible". I really don't appreciate a language that does not trust the programmer (me) so much. As you can see, I'm very far from being a Java fan.

Having said that, you have to hand it one thing - it is much simpler than C++. Much much simpler.

Granted, the language being simpler often means that you have to jump through hoops to do what you want (who else misses C, which was both simple and trusted the programmer?) This does not change the core assertion - Java is much simpler than C++.

Shachar

Re:Sorry, C variants aren't trendy...

[cerberusss]

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.

Re:Sorry, C variants aren't trendy...

[mabinogi]

who else misses C, which was both simple and trusted the programmer?

I don't miss it at all - I use it, every single day.
It's not some dead forgotten language, you know. If you want to use it, use it.

However, it's not that it trusts the programmer. It just doesn't care.

Re:Sorry, C variants aren't trendy...

[dgriff]

C++? Too simple.

That's not a statement you see very often.

Re:Sorry, C variants aren't trendy...

[Sun]

However, it's not that it trusts the programmer. It just doesn't care.

It amounts to the same thing.

Don't get me wrong. I use it quite frequently too, but mostly where I have no choice (kernel, embedded). When I do, I prefer the shortcuts offered by C++.

When I have to choose between C++'s overly complex syntax (but which I have already learned) and Java's distrust of the programmer, I choose C++. I do wish it had a better (simpler) syntax, though.

shachar

Yu left out one #ifdef

[tomhudson]

#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.

Re:Yu left out one #ifdef

[alexott]

boost::asio hides many low level details of networking, and provide pretty good high level interface to networking on almost all platforms... P.S. forgot about database and XML - for database you can use soci (from soci.sf.net), and for XML - arabica XML libraries, that supports different XML libraries - expat, libxml2, xerces, etc.

Re:C++ is so old school...

[zebrilo]

yeah, Qt is made for C++ (despite there are plugins for Java and Python)

Re:Cross platform? USE JAVA, duh!

[ultrabot]

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.

try boost...

[alexott]

boost::asio for networking + events, boost::treads for threading, and boost::interprocess for shared memory & other stuff...

Re:C++ is so old school...

[cbhacking]

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++).

Just use POSIX

[Anonymous Coward]

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

[rudedog]

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

[Jester99]

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:Just use JAVA

[Anonymous Coward]

Got yer polarity wrong. He's the oldster, you are the whippersnapper. You should be saying, "I'll get off YOUR lawn". Otherwise, your advice is sound.

Re:C++ is so old school...

[Profane MuthaFucka]

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.

SQLite for database

[PizzaFace]

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.

Re:SQLite for database

[Kjella]

Just don't mention SQLite and threading in the same sentence. Or even concurrently running multiple queries in the same thread, like doing more queries while looping through a result set can cause hangs. It's great for what it does, but if it's anything more than a settings/profiles/log database, get a real one.

MONO

[Vahokif]

*ducks*

Heh, ACE is for old foggies

[solid_liq]

Duh, Qt!

Re:Qt, Wx, pain

[bcmm]

Did you just suggest emulating embedded hardware using python?

Re:Microsoft POSIX Subsystem

[alexmin]

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

[Anonymous Coward]

If you've been write multi-platform code using the preprocessor, you don't know what the hell you are doing. Don't blame the tools, learn how it's support to be done. Hint: define a proper build system that doesn't require any preprocessing.

Re:Unfortunately probably not worth it

[binarylarry]

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:Cross platform? USE JAVA, duh!

[binarylarry]

Considering Eclipse is probably the most widely used IDE in the world, do you have anything to back up your claims?

Another couple of options

[EvilIdler]

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.

Re:Qt, Wx, pain

[jipn4]

"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:wxWidgets

[quench]

hey, I still remember the wxCanvas stuff. this is really oldschool, apart from the fact that I'am GUI-less.
thanks anyhow, wx was cool last time I used it! (1994?)

Your App Will Suck Anyway: So Use Java

[RonBurk]

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.

Java, Perl, and WxWidgets...

[taoboy]

...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...

Re:Unfortunately probably not worth it

[Anonymous Coward]

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

whoosh?

[reiisi]

GP was being sarcastic?

And maybe a little (more than a little?) critical of AJAX, et. al.?

Maybe?

SQLite

[melstav]

You beat me to the suggestion.

SQLite 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

A more C++ friendly wrapper for SQLite is on CodeProject

mono *ducks*?

[reiisi]

Is that the name of some kind of portable library?

Re:Cross platform? USE JAVA, duh!

[rfreedman]

TFA - Whats the best hack for c++ to let it be cross platform?

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.

Me - Use a language and SDK that is MADE FOR CROSS PLATFORM COMPATIBILITY. JAVA JAVA JAVA

JAVA has cross platform sockets
JAVA has cross platform threads
JAVA has cross platform gui

C++ has header files... F**K HEADER FILES
C++ has pointers to pointers... F**K MEMORY MANAGEMENT
C++ makes you feel smart when you get something to actually work correctly... F**K YOUR EGO

+1

Try LibNUI + SQLite

[MeeLoo]

(disclaimer: I'm the author of this lib). LibNUI supports iPhone, Win32, Win64, MacOSX and Linux. It offers complete OS abstraction for Threads, Windowing, Unicode Strings, OpenGL / GLES / Direct3D GUIs and many widgets. You can use it in any GPL application or buy a commercial license. Check it out: http://libnui.net/

Re:Cross platform? USE JAVA, duh!

[binarylarry]

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:Unfortunately probably not worth it

[binarylarry]

In newer versions of OpenJDK this is not true.

Although in current use (java 6 et al), you're correct.

Poco is your answer

[HedgeBoar]

Boost is a good point to start and a good academic tool for the purists. ACE is trying to be too much for too many platforms. For real world use I ended up with Poco http://pocoproject.org/, very good performance, works flawless on Win/Linux platforms (base on my experience) and has an easy to use interface.

qt4

[Pope Raymond Lama]

dito.

The OS-independence you want..

[slashmais]

There is a very stable C++ IDE in Ultimate++.

Quoting from the site:
"U++ is a C++ cross-platform rapid application development framework focused on programmers productivity. It includes a set of libraries (GUI, SQL, etc..), and an integrated development environment.
...
TheIDE can work with GCC, MinGW and Visual C++ 9.0 as contained in free Windows Vista SDK and contains a full featured debugger. TheIDE can also be used to develop non-U++ applications."

two great portable runtime libraries

[tlacuache]

Apache Portable Runtime
Netscape Portable Runtime

what does a database have to do with flash?

[Dahamma]

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?

Use Modula 3 instead of any variety of C.

[hendrikboom]

How about a platform-independent programming language complete with systems programming features, garbage collection, object-inheritance, type-safety and a way to bypass it when necessary? Have a look at Modula 3 and its libraries: http://en.wikipedia.org/wiki/Modula-3

Has any one here every written an emmulator.

[strangeattraction]

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.

OS wrappers

[larytet]

wxWidgets emLib http://larytet.sourceforge.net/ are two options I used. emLib is available in LGPL - contact the author.

Qt

[jkajala]

If you need a graphical user interface in your application go for Qt. Seriously, you won't regret it. I'm also using several other open source libs like Boost, but those won't help a bit to get your cross-platform GUI running. Qt, in contrast, handles that great, and has IPC, SQLite integration and thread abstractions a bonus. Besides, if you are starting as a "fresh" user , you will have benefit that once you have learned a bit Qt you will be comfortable with the other classes in the library as well. In contrast, if you decide to go for different lib for each purpose, you will have a lot more to learn (and to integrate).

Highly recommend Poco over ACE

[Samarian Hillbilly]

I've used ACE a lot, 10 years ago, even then the code looked like it'd been hacked on by 4 generations of under-grads (which it had). Basic stuff works good, but there are some lurking race conditions in shared memory pools that you don't want to meet. I recommend Poco, industrial, easy-to-use etc.
http://pocoproject.org/

I wouldn't consider boost, yet, they're just starting to put in a full suite of cross-platform stuff and they're still missing some important pieces.

Time (sort of) still stands

[Chuu]

Boost is an absolutely incredible library, and any C++ programmer who doesn't use it is probably missing out. That being said, if you know ACE (i.e. have made it past the pretty steep learning curve) then ACE gives you more options. Boost's thread library is pretty great, but they simply don't have as fine control over primitives. There are also many things that you can do in ACE that you simply can't do in boost easily -- such as non-static pooled allocators.

Unless I am completely missing something, there is also no equivalent to the TAO in Boost.

I work on performance critical C++ code (yes, there really is such a thing) and we pretty much use ACE for anything involving IPC, sockets, or Threading -- and boost for everything else. That being said, the boost ASIO, thread, IPC, and Intrusive libraries are so easy to use compared to their ACE counterparts that unless performance is critical or boost simply isn't enough -- there isn't much use in learning ACE from scratch.

Re:Time (sort of) still stands

[Yosho]

Unless I am completely missing something, there is also no equivalent to the TAO in Boost.

Thank goodness. I've never really understood what the point was to having an ORB bundled with your C++ middleware library. Compared with TAO, I've found standalone ORBs like omniORB or ORBexpress to be equivalent or better in performance and much smaller in size.

Re:Time (sort of) still stands

[old cob]

TAO (The ACE ORB) is not bundled with ACE. ACE is bundled with TAO as it provides the platform abstraction layer. If you want a nice multi language solution, CORBA with its many open source implementations can be the answer. Many people need RT CORBA and having an ORB built on ACE, that can use many RTOSs, is a big deal. Note ACE is also bundled with OpenDDS to offer an open source RT pub sub system that supports C++ and Java. Again an RT pub sub that does not run on RTOS would be a waste. ACE plugs that gap. So ACE has a lot of complimentary products that can give a big help when building large weapons systems, financial systems such as market data and trading, and telecom call switching.

POCO

[TheDefectiveDetectiv]

Try POCO. I've found it to be pretty useful.

PTypes

[dmesg0]

If you are looking for something small, clean and very easy to use - PTypes (http://www.melikyan.com/ptypes/doc/index.html) may do the trick. It has classes for threads, sockets, i/o, shared libraries etc. It's also very easy to extend if some functionality is missing.

And it has zlib license, so you can do anything with it.

Disclaimer: I have nothing to do with the library development, just a user.

Cygwin

[Madsy]

Java, or link to the Cygwin library. The latter gives you a kind of POSIX API wrapper for your windows applications. So you can use POSIX threads and IPC stuff if you want. I'm not sure how efficient that is though, or how stable the general Cygwin API is.

Qt + SQLite

[Per Wigren]

Qt and SQLite. Seriously. LGPL and kick-ass! Also, Qt can be compiled to have SQLite completely built-in. No extra libs/dlls needed. It handles networking, threading, IPC, SQL and much more. No need for platform-specific ifdefs.

C++0x

[Engeekneer]

For really early adopters, C++0x includes built in threading support. You'll still have to use libs for sockets though.

He asked for a C++ toolkit

[OeLeWaPpErKe]

The obvious answer would be QT, imho.

POCO project

[jbb999]

Definatly take a look at poco project http://pocoproject.org/ It seems to covera lot of what you want

Re:C++ is so old school...

[Hal_Porter]

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.

Re:Cross platform? USE JAVA, duh!

[LinuxAndLube]

Have you heard of Hadoop?

Glib and Gtk++

[pkphilip]

Glib + Gtk++ is pretty decent. You also have Gnome Db for database access. A number of people have suggested QT and also WxWidgets. Both are pretty good.

gtkmm

[emanem]

the C++ GTK+ interface is great...deploying GUIs is really easy, swing/awt like...
Plus you have very good STL support and a lot threading/files/io cross platform support.
And it's proper C++!

Cheers,

+1 on Boost and Qt

[krilli]

So yes. Here's just a quick +1 on Boost and Qt.

WT Toolkit

[croftj]

If you want what looks like a promissing web interface you might try http://www.webtoolkit.eu/wt. Life's beautiful when you can do web stuff in just one language

New and trendy

[tuomoks]

Or maybe not, Qt, Boost seem good choices based on your experience, but it really depends. The best hw emulators (and simulators) I have seen / done / supported were written in LISP, yes, not new nor trendy.

And there is of course Erlang, it has all in language, is natively threaded even between nodes if desired, has very good database(s) natively, and so on - but not new nor trendy. Much less coding, configuration, etc effort than in most languages but maybe needs some time to get used.

Re:Unfortunately probably not worth it

[Panaflex]

I've rarely, if ever, seen a clear advantage of using forking. Using private structures per thread easily accomplishes the same task as forking and is highly portable. The one great forking advantage (crash resiliency) can still be accomplished by starting multiple processes from a script.

For most projects I simply use a startup script or threading. Another project I've enjoyed using is OpenMP - which can automate across machines and has great run-time controls and basic messaging.

Re:C++ is so old school...

[Profane MuthaFucka]

I once killed a man right at his keyboard for claiming a segfault in the QT library. This is serious stuff.

Commercial grade

[scout007]

As an addition to the already mentioned, there is also a commercial grade that might be easier to use than Boost. SourcePro C++, you can check it out at http://www.roguewave.com/products/sourcepro/.

Why platform independence?

[jgrahn]

You say you're "emulating embedded hardware on Windows". What will you use the platform independence for? If you don't need it right now but "maybe in the future", I suggest skipping it. Write for Windows, but make sure ask the compiler to accept ISO C++ only, and don't sprinkle Windows-specific crud (UWORD, __declspec and whatever they are called) in the parts of the code which *are* platform-independent.

An unused portability layer only weakens your code.

Personally, I couldn't care less for Windows, so I develop under Linux and target Unix in general (not actively, but I expect it to be easy to port to some other decent Unix if I have reason to in the future). It's great -- I can use select(2), fork(2) and treat file descriptors and sockets alike. And I can learn from good books (e.g. Stevens) and discuss it with people who have been using those interfaces since, well, forever. No portability layers have that much support.

By the way, I don't see why you need a bloody *database* (even a nice one like BerkleyDB) to emulate flash memory. Can't you just mmap() a file?

Try TnFOX

[ned14]

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

This is a FAQ

[shutdown -p now]

In general, you'll be better off asking such questions on StackOverflow - you'll get an answer within minutes without having to wait for it to be posted. In fact, you wouldn't even have to ask - this is one of those question that's asked so frequently that there are plenty answers on various aspects of it.

The short answer is: if you need UI and/or are familiar with Java, use Qt. If you don't need UI or you really like idiomatic C++ (think STL), use Boost.

C++ on .Net?

[GWBasic]

Microsoft Visual Studio's C++ compiler has an option that lets you generate 100% CLR binaries that will run on Mac and Linux with mono. The limitation is that you can only use the .Net API.