Anybody have an idea of best CrossPlatform Multiprocessing and Multithreading Library for C++. The one i can find by google is OPEN MP. is that the only one and standard library for multiprocessing in C++?
OpenThreads is a good option.
Boost.Thread is an cross platform, multithreading library and it will be an part of upcoming C++11 standard. Boost.Process exists, but is not yet part of the official boost library.
Also, QThread/QProcess from Qt is another good option. It is available on platforms: Linux, Mac OS X, Windows, Embedded Linux, Windows CE, Symbian, Maemo.
SFML has it's sf::Thread class(also has synchronization classes).http://www.sfml-dev.org/tutorials/1.2/system-threads.php to compile this link -lsfml-system with gcc and sfml-system.lib with vs.
POCO library. Has a lot of things including thread and thread synchronization classes, thread pool, work queues, active objects and activities, task management, and timers. Well written code, well integrated with other library classes.
Well worth a look.
Related
Let's put like this: We are going to create a library that needs to be cross platform and we choose GCC as compiler, it works awesomely on Linux and we need to compile it on Windows and we have the MinGW to do the work.
MinGW tries to implement a native way to compile C++ on Windows but it doesn't support some features like mutex and threads.
We have the MinGW-W64 that is a fork of MinGW that supports those features and I was wondering, which one to use? Knowing that GCC is one of the most used C++ compilers. Or it's better to use the MSVC (VC++) on Windows and GCC on Linux and use CMake to handle with the independent compiler?
Thanks in advance.
Personally, I prefer a MinGW based solution that cross compiles on Linux, because there are lots of platform independent libraries that are nearly impossible (or a huge PITA) to build on Windows. (For example, those that use ./configure scripts to setup their build environment.) But cross compiling all those libraries and their dependencies is also annoying even on Linux, if you have to ./configure and make each of them yourself. That's where MXE comes in.
From the comments, you seem to worry about dependencies. They are costly in terms of build environment setup when cross compiling, if you have to cross compile each library individually. But there is MXE. It builds a cross compiler and a large selection of platform independent libraries (like boost, QT, and lots of less notable libraries). With MXE, boost becomes a lot more attractive as a solution. I've used MXE to build a project that depends on Qt, boost, and libexiv2 with nearly no trouble.
Boost threads with MXE
To do this, first install mxe:
git clone -b master https://github.com/mxe/mxe.git
Then build the packages you want (gcc and boost):
make gcc boost
C++11 threads with MXE
If you would still prefer C++11 threads, then that too is possible with MXE, but it requires a two stage compilation of gcc.
First, checkout the master (development) branch of mxe (this is the normal way to install it):
git clone -b master https://github.com/mxe/mxe.git
Then build gcc and winpthreads without modification:
make gcc winpthreads
Now, edit mxe/src/gcc.mk. Find the line that starts with $(PKG)_DEPS := and add winpthreads to the end of the line. And find --enable-threads=win32 and replace it with --enable-threads=posix.
Now, recompile gcc and enjoy your C++11 threads.
make gcc
Note: You have to do this because the default configuration supports Win32 threads using the WINAPI instead of posix pthreads. But GCC's libstdc++, the library that implements std::thread and std::mutex, doesn't have code to use WINAPI threads, so they add a preprocessor block that strips std::thread and std::mutex from the library when Win32 threads are enabled. By using --enable-threads=posix and the winpthreads library, instead of having GCC try to interface with Win32 in it's libraries, which it doesn't fully support, we let the winpthreads act as glue code that presents a normal pthreads interface for GCC to use and uses the WINAPI functions to implement the pthreads library.
Final note
You can speed these compilations up by adding -jm and JOBS=n to the make command. -jm, where m is a number that means to build m packages concurrently. JOBS=n, where n is a number that means to use n processes building each package. So, in effect, they multiply, so only pick m and n so that m*n is at most not much more than the number of processor cores you have. E.g. if you have 8 cores, then m=3, n=4 would be about right.
Citations
http://blog.worldofcoding.com/2014_05_01_archive.html#windows
If you want portability, Use standard ways - <thread> library of C++11.
If you can't use C++11, pthread can be solution, although VC++ could not compile it.
Do you want not to use both of these? Then, just write your abstract layer of threading. For example, you can write class Thread, like this.
class Thread
{
public:
explicit Thread(int (*pf)(void *arg));
void run(void *arg);
int join();
void detach();
...
Then, write implementation of each platform you want to support. For example,
+src
|---thread.h
|--+win
|--|---thread.cpp
|--+linux
|--|---thread.cpp
After that, configure you build script to compile win/thread.cpp on windows, and linux/thread.cpp on linux.
You should definitely use Boost. It's really great and does all things.
Seriously, if you don't want to use some synchronization primitives that Boost.Thread doesn't support (such as std::async) take a look on the Boost library. Of course it's an extra dependency, but if you aren't scared of this, you will enjoy all advantages of Boost such as cross-compiling.
Learn about differences between Boost.Thread and the C++11 threads here.
I think this is a fairly generic list of considerations when you need to choose multi-platform tools or sets of tools, for a lot of these you probably already have an answer;
Tool support, who and how are you going to get support from if something doesn't work; how strong is the community and the vendor?
Native target support, how well does the tool understand the target platform?
Optimization potential?
Library support (now and in the intermediate future)?
Platform SDK support, if needed?
Build tools (although not directly asked here, do they work on both platforms; most of the popular ones do).
One thing I see that seems to not really have been dealt with is;
What is the target application expecting?
You mention you are building a library, so what application is going to use it and what does that application expect.
The constraint here being the target application dictates the most fundamental aspect of the system, the very tool used to built it. How is the application going to use the library;
What API and what kind of API is needed by or for that application?
What kind of API do you want to offer (C-style, vs. C++ classes, or a combination)?
What runtime is it using, will it be the same, or will there be conflicts?
Given these, and possible fact that the target application may still be unknown; maintain as much flexibility as possible. In this case, endeavour to maintain compatibility with gcc, mingw-w64 and msvc. They all offer a broad spectrum of C++11 language support (true, some more than others) and generally supported by other popular libraries (even if these other libraries are not needed right now).
I thought the comment by Hans Passant...
Do what works first
... really does apply here.
Since you mentioned it; the mingw-builds for mingw-w64 supports thread etc. with the posix build on Windows, both 64 bit and 32 bit.
I have a codebase that makes extensive use of pthread.h. On a windows visual studio project, this obviously doesn't work since pthreads is a unix utility.
I know there exists pthread-win32 or something of the sort, but is there a way to have a codebase use this, without replacing all of the pthread code?
edit: I'd prefer to not have to go through and replace all the pthread calls. This is my question
Try http://sourceware.org/pthreads-win32/. While I've never used that particular library, I've had luck using some windows ports/abstraction layers of POSIX APIs.
I would recommend boost as a library that contains a platform-independent thread abstraction. I don't think you'll find any attempt to call the pthread functions themselves to be satisfying. It's also not very hard to map pthread to Win32 for yourself.
If the code is very heavily *nix-based, you'll probably have the best luck compiling it with Cygwin+GCC. If pthreads is the only *nix dependency and you'd like to avoid the Cygwin dependency, then you should go with Pthreads-win32.
I want to learn C++ to work on various platform (primarily, Linux and Windows). I have come across few solutions like the Boost C++ library, Qt toolkit, etc that can be used to write programs which will compile on both the platforms.
I want to know from the community, what type of library would you refer to use and if any of you had experience with this type of multi-platform programming before.
Use Qt and the BOOST C++ Libraries. They are both free and very high quality. Also, at least for me personally, I found Qt to be much more straightforward, easy to learn, and simpler than wxWidgets.
It depends on what you're going to do. If you need to write a strictly command-line utility to process text, Qt or wxWidgets might be inappropriate. What exactly is your application field?
Scientific computing is my field of expertise. in which these are great multi-platform APIs:
Parallel Programming
MPI
OpenMP
Numerical Algorithms
BLAS (via Boost's C++ wrappers for BLAS)
LAPACK
LINPACK
PETSc
High-performance file I/O
HDF
NetCDF
Visualization
Visualization Toolkit
If you're doing viz work, a GUI can be great. Try one of the following multi-platform APIs:
Qt
wxWidgets
GTK
The plugin framework for the parallel viz apps:
Paraview
VisIt
You didn't specify any partuclar type of library, but if you just want a general recommendation I have to say wxWidgets is an excellent cross platform GUI library.
It has some great features like rendering the GUI in the native look and feel of the operating system it's running on, and is not particularly hard to learn. It offers a single API for GUI writing across Win/Mac/Linux, plus others like WinCE.
I highly recommend it for cross platform GUI work.
Check it out at http://www.wxwidgets.org/
I highly recommend Qt if you are doing any sort of GUI work; it's even quite useful if you aren't, since it has well-thought out networking/database/container/etc APIs also. It's a very well designed API and very easy to use.
The core C++ standard and the STL are pretty much cross platform already. Its usually only the GUI and hardware access stuff that requires libraries.
I have used GTK+ as a GUI toolkit and it's pretty good too, although you need to install glib and some other stuff on windows.
RtAudio is nice for cross-platform audio I/O.
The low level networking/sockets stuff is largely the same between windows and linux, you could write a very lightweight layer yourself to handle any differences. I don't have any experience with higher-level networking libraries.
I also like the SFML (simple fast media library) for cross-platform 2d graphics type stuff. It's very nice indeed.
I would suggest, however, that if you are just learning c++ then you're probably better off not looking at Boost (or indeed any of these toolkits) until you've got your head around the basics - by writing a couple of basic console applications, for example.
If you want to learn c++ only so you can do multi-platform dev, be aware that there are many other languages and associated toolkits that may be more suitable, depending on the app you're writing.
Without knowing the type of app you're planning on developing, its hard to say whether C++ (or C or Python or whatever) is the best idea. Personally, I generally turn to Python + PyGTK for crossplatform GUI apps and C# for windows-only apps. You can always plug C/C++ in to replace any components that are running too slowly.
Like other posters have mentioned, I would recommend Qt and Boost for cross-platform development. I had tried gtkmm which is a thin C++ wrapper around GTK+, but was not satisfied with it partly because it's not a native C++ library and documentation is poor compared to Qt. Besides that, Qt comes with very nice development environment including a easy-to-write make alternative qmake and a gui designer.
I for are going to do some cross platform development in C++ an you don't want to maintain different build systems (Makefiles, Visual Studio Projects, etc) there are several tools out there that can help you.
The one I personally use is CMake. It supports Linux and Unix Flavours, Windows and Mac/OS. Actually several open source projects, like KDE, use it. But there are others options like for instance Scons.
Standard C++ programs will compile and be portable, i.e. work across a large range of platforms. To be sure that you are keeping code clean, your best bet is to get a few different compiler and check your code with all of them, while enforcing full standard conformance (with options like -std= for g++, for example) and writing warning-free code (with options such as -W -Wall -Werror for g++, which emits errors instead of warnings). The exact choice of compilers is up to you, but if you're mostly learning, I advice using:
g++ (free, open source)
the Intel compiler (free for noncommercial use on Linux)
maybe MSVC++
Also, if you really have to use compiler- or target-specific code in your projects, be sure to abstract it so it's all gathered in one place, and hidden from the rest of your code.
Now, if you want to use more than the STL, then you need to choose your libraries by considering the range of compilers and platforms they're tested against (and, if the documentaiton doesn't state it, it's a bad omen). The detailled choice depends on what exactly you want to do, but Boost (as a robust, wide-ranging library for many common issues) and Qt (a recent version; for GUI programming) are good choices. For numerical, scientific programming, BLAS/LAPACK (and/or their parallel versions, BLACS and Scalapack) are very widely used, directly or through wrapper C++ classes as can be found in Boost (for BLAS); a good FFT library is also often needed (FFTW is good if its GPL licence is not a burden for you).
Is it possible to create a multithreading application in VC6 with boost library?
If it is possible, what are some relevant tutorials.
Yes, I have done this successfully, but with Boost v1.30.0. So if you have trouble with the latest versions of the Boost libraries, you might want to go back a year or five. I recall I started getting all sorts of internal compiler errors, et al., when trying to upgrade Boost -- so I didn't, but rather went on using v1.30.0 until I was able to upgrade Visual C++ as well. Even the old versions of Boost are very stable and useful, they just have less features.
http://www.boost.org/doc/libs/1_37_0/doc/html/thread.html
A quick google for "boost thread example" turns up lots of good hits.
The Boost.Thread library provides thead creation and manipulation facilities. Read the boost documentation (link was provided in litb's answer). It also provides synchronization bojects (mutexs). Boost is cross platform and is compatible with VS6.
As for the rest of the boost libraries - they are usually thread safe, but read the documentation of each particular library of details.
Does anyone have any experience with running C++ applications that use the boost libraries on uclibc-based systems? Is it even possible? Which C++ standard library would you use? Is uclibc++ usable with boost?
We use Boost together with GCC 2.95.3, libstdc++ and STLport on an ARMv4 platform running uClinux. Some parts of Boost are not compatible with GCC 2.x but the ones that are works well in our particular case. The libraries that we use the most are date_time, bind, function, tuple and thread.
Some of the libraries we had issues with were lambda, shared_pointer and format. These issues were most likely caused by our version of GCC since it has problems when you have too many includes or deep levels of template structures.
If possible I would recommend you to run the boost test suite with your particular toolchain to ensure compatibility. At the very least you could compile a native toolchain in order to ensure that your library versions are compatible.
We have not used uClibc++ because that is not what our toolchain provider recommends so I cannot comment on that particular combination.
We are using many of the Boost libraries (thread, filesystem, signals, function, bind, any, asio, smart_ptr, tuple) on an Arcom Vulcan which is admittedly pretty powerful for an embedded device (64M RAM, 533MHz XScale). Everything works beautifully.
GCC 3.4 but we're not using uclib++ (Arcom provides a toolchain which includes libstd++).
Many embedded devices will happily run many of the Boost libraries, assuming decent compiler support. Just take care with usage. The Boost libraries raise the level of abstraction and it can be easy to use more resources than you think.
I googled "uclibc stlport". It seems there are at least a few versions of uclibc for which stlport can be compiled (see this).
Given that, i'd say Boost is just a few compilation steps away. I have read a message by David Abrahams (who is an active member of the boost community) that says that Boost does not depend directly on the used libc. But some libraries may still cause problems, Boost.Python for instance, since it depends on something else (Python in my example) that might be difficult to compile with uclibc.
Hope this helps
I have not tried but I don't know anything about uclibc that would prevent Boost from working.
Try it and see what happens, I would say.
Yes you can use boost with uclibc.
I tried this with boost 1.45 & uclibc on ARM9260
Use fresh OpenEmbedded
Configure it to use Angstrom
Configure Angstrom to use uclibc
make boost - bitbake boost