Standardization on libraries

[brcain]

With Boost libraries likely making their way into the new C++ Standard Library (not sure which ones) … will Qt take advantage of these libraries … for example
- switching from QThreads to Boost.Threads
- switching from Qt Signals/Slots to Boost.Signals

Perhaps it’s too early to speculate … just wishful thinking.

Not trying to flame. It just gets a little crazy having to marry so many library implementations. For example, in one of our applications, we have had to deal with several different threading libraries … QThreads, Boost.Threads, OSG OpenThreads, and ICE threads. Then there’s PThreads, Windows threads, … !!!

My main interests for threading libraries are:
- standardization / broad industry usage
- support/enforcement of correctness (e.g. RAII scoped-lock mutex)
- objected-oriented API
- reasonable performance tuning

Thanks for your time.

Cheers,
Ben

[Brandybuck]

The Qthreads exist because Qt is a cross-platform cross-compiler library. It needs to work on all platforms and all compilers, and they need to be usable by those with only moderate C++ knowledge. Boost takes a much different approach, and uses many of the more advanced and esoteric corners of C++. It was written for advanced C++ users and targets a 100% conforming compiler.

[brcain]

I understand Qthreads existence ... just hope to eventually see convergence to one threading library.

BTW, Boost.Threads are very easy to use and enforce correct usage with RAII scope-locked mutexes. The API isn't likely as rich as it should be yet.

Not knocking Qthreads here ... just musing

[Brandybuck]

I understand Qthreads existence ... just hope to eventually see convergence to one threading library.

BTW, Boost.Threads are very easy to use and enforce correct usage with RAII scope-locked mutexes. The API isn't likely as rich as it should be yet.

Not knocking Qthreads here ... just musing

Boost.Threads uses functors to specify the thread of execution. That's an advanced C++ concept that relatively few developers are familiar with. For that reason alone I would avoid it. I was at a class recently with ten professional C++ developers, and only one new what a functor was. C++ is a BIG language, and we cannot expect developers to know all of it.

You don't need functors, function pointers, or any other callback method to specify the thread of execution. Do it the OO way, and subclass thread and write your own run() method. This is what both Qt and Java do. I seem to recall that's what ACE does. It's what I did when I wrote my own pthread wrapper.

p.s. QMutexLockers are the equivalent of "RAII scope-locked mutexes".

[brcain]

I was at a class recently with ten professional C++ developers, and only one new what a functor was.

Not sure why the tangent. Nonetheless ...

Anyone claiming to be a professional C++ developer should know what a functor is. Functors are used extensively in the STL (by design). See the algorithm chapters of "The C++ Standard Library" by Josuttis. Also note numerous references from Stroupstrup in "The C++ Programming Language". BTW, this also goes for design and architectural patterns.

All this said, there's no reason C++ can't standardize on a threading library. That's the primary weakness of the language IMHO -- albeit, there's no perfect language ... yet.

Again, I have nothing against QThreads. I do dislike having to deal with multiple threading libraries in one application. It can be quite error prone.

[Brandybuck]

Anyone claiming to be a professional C++ developer should know what a functor is. Functors are used extensively in the STL (by design). See the algorithm chapters of "The C++ Standard Library" by Josuttis. Also note numerous references from Stroupstrup in "The C++ Programming Language". BTW, this also goes for design and architectural patterns.

Thus we see the difference between commercial and academic/research C++ programmers. (There is considerable overlap between the two groups). And why Boost isn't seen much in commercial setting, but is de rigeur in academic/research settings. Academic C++ developers tend to know a lot about GP whereas commercial developers do not.

This isn't because commercial programmers are stupid, it's because there's a greater tendency to change languages, to use older compilers, to do things the simple way instead of the clever way, etc. Commercial firms are also more conservative and less likely to explore the more advanced features of a language.

In short, commercial developers are less likely to know what a function object is, or if they do, have little to no experience actually using them. It is a concept that is outside of the "core" language. If I could only hire people who knew what a functor was, I would have trouble filling the position. They are not bad people just because they don't know what you think they "should".

p.s. The vast majority of functors are used as callbacks. Because most callbacks are used in GUIs, and nearly all C++ GUIs avoid callbacks (at least direct callbacks), commercial developers simply don't have much opportunity to use functors, even if they wanted to. If you don't use it, you lose it. Thus, a lot of the developers who don't know what functors are, will exclaim after you tell them what it is, "Oh yeah! I learned that way back in college!"

p.p.s. a company I once worked for hired one of the developers of SGI's STL. He quit two weeks later because the company refused to uprade its compiler. But the company couldn't upgrade because it would mean revalidating a few million lines of code for no commercial benefit. They were planning to update the compiler during the next product upgrade cycle the next year, but this was too slow for the developer who couldn't stomach the notion of using an "obsolete" compiler.

[brcain]

Again, functors are used extensively with STL algorithms (by design). Are you suggesting commercial developers don't use STL algorithms?

If you don't like functors or Boost ... that's fine. But, I wouldn't suggest that they are not used for commercial development. That's a bit naive.

[Brandybuck]

Again, functors are used extensively with STL algorithms (by design). Are you suggesting commercial developers don't use STL algorithms?

Yes, I am indeed suggesting that. Not all commercial C++ developers though, just a significant number of them. Perhaps even a majority. A coworker of mine uses STL algorithms all the time, because he does image processing. Another coworker has never used them because he writes device drivers.

[wysota]

A simple vote against using a standarised approach is that, for example, STL implementations don't exist on some platform Qt supports. So if you want to start standarising Qt, first standarise libraries which have a "standard" word in their name. Before you do that, don't mess with others, or you'll end up with a non-crossplatform code. Qt uses own implementations on purpose and thanks to that they are faster, more efficient, integrate well with the API and are not burdened by some licence legacy. If you really need advanced concepts which are beyond what Qt currently offers, you are free to use Boost along it, Qt4 was designed so that you can (and many Qt developers use Boost themselves). But don't try to force people which lack advanced knowledge/needs to dig into another pile of docs to understand the new horror. Just look at the Newbie section on this forum. If Qt was more difficult, those people would be long gone...

The trouble with standards is that there are many different standards for same things or that one standard is incompatible with another, etc. Using Windows is currently considered "standard" too, but many of us don't intend to follow it and there is a reason for that.

[brcain]

don't try to force people which lack advanced knowledge/needs to dig into another pile of docs to understand the new horror.

If you read the entire thread you'll note that I was addressing the complexities of insuring multiple threading libraries cooperate correctly. It was never my intent or desire to force anyone to use Boost.Threads.

The thread (as often do) digressed into how bad Boost .Threads and functors were (according to Brandybuck). I was merely indicating their utility ... and expressing my desire to not deal with multiple threading implementations.

Have a nice day,
Ben

[wysota]

So which threads implementation would you choose and why? I'm perfectly happy with QThread... It integrates very well with the rest of the toolkit. I guess that even if you used Boost implementation of threads instead, it would have to be changed significantly to fit all the demands it has to meet and it would not look like Boost threads anymore.

[brcain]

My immediate problem is having to integrate existing code that uses different threading libraries. So, choosing "one" isn't an option.

But, to answer your question ...

Boost.Threads are very easy to use (IMHO) ... although the library doesn't have a rich enough API yet. I do like the RAII scope-locked mutexes in Boost.Threads. With this, it's very difficult to leave a mutex accidentally locked. Someone was saying QThreads has a similar feature ... good to hear. For me correctness is the big issue ... as anyone doing threading has discovered. On this note, does QThreads provide message queues to talk between different threads? I think I'll post this as another topic.

But, I don't know enough of QThreads yet to make a judgment that I'd feel good about. I am just beginning to use them.

The Boost folks are certainly very savvy ... consisting of many of industry's top C++ gurus, sit on the standards committee, etc. Who knows what will evolve. I guess it's really too soon (for me) to choose any one solution. Their libraries are very powerful (e.g. StateCharts, Template Metaprogramming, etc.) ... albeit not all of them are appropriate for all types of development.

My guess is that QThreads are much more stable and with a richer API. So, I'll likely use them where I am able.

[Brandybuck]

On this note, does QThreads provide message queues to talk between different threads?

Yes it does.

[brcain]

Outstanding! Looking forward to it.