Standardization on libraries

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