And a good preview on the new C++0x standard, in German:
Code: Select all
for(std::tr1::unordered_map<std::string, Element::Ptr>::iterator it = m_Children.begin();
it != m_Children.end(); it++)
which would be
Code: Select all
for(Element::Ptr e : m_Children)
(Even though for a project like the Cafu engine that aims to be highly portable and "compile and run" on many architectures, compilers and operating systems, it can sometimes be difficult or even prohibitive to use the latest language and compiler features, at least in large scale.)
Well, I've become intrigued with parallel programming as well, and will soon start my first experiments - either using the Pthreads library, and/or the multithreading support classes in wxWidgets.
Carsten wrote:Well, I've become intrigued with parallel programming as well, and will soon start my first experiments - either using the Pthreads library, and/or the multithreading support classes in wxWidgets.
From what I've read about pthreads, apparently the windows version is not as efficient as Windows threads. Does wxWidgets use windows threads on Windows and pthreads on other systems? That would be the way to go until C++0x threading gets well supported (could be a few years yet ), which I hope is well optimised for all systems.
Stephen wrote:From what I've read about pthreads, apparently the windows version is not as efficient as Windows threads. Does wxWidgets use windows threads on Windows and pthreads on other systems?
Yes, I think so: The Multithreading Overview seems to indicate that. So just as Pthreads, the wxWidgets threads classes are just a wrapper around the Win32 API, where however the wxThreads are not limited by compatibility constraints (the "fixed" API interface) like Pthreads.
I generally like wxWidgets a lot, and their "wxBase" library contains everything that is not GUI related, such as the Unicode-supporting wxString class and the threading classes. As such, its thread classes can also be used in pure console applications, as is great for early tests; and CaBSP, CaPVS and CaLight are console programs anyway.
(And my plan is to try multithreading in CaPVS and/or CaLight first, as these two very much suggest themselves for good use of parallelism. CaLight will likely eat a bit more memory for each additional thread that it uses, but it is a prime example for converting a serial task into a parallel one.)
However, I usually prefer to avoid any "extra layer" of code, and thus try to use APIs directly whenever reasonably possible. Pthreads seems to be well documented and its less abstracted/encapsulated API (compared to wxThreads) seems to yield a more thorough learning experience.
Then, Pthreads is just a wrapper around the Win32 API, just like the wxThreads, but it is (quasi) native under the Unix platforms. As both are wrappers under Windows, you just work "through" them in order to setup the OS and hardware threads, and so I'd expect both to have little impact on performance (as opposite to the application code, the OS and the hardware, which do the real management (e.g. the scheduling) and the work).
That is, I'm also very much in favor of using Pthreads, also under Windows.
In summary, I'm still undecided and thus I'll just try both.
Users browsing this forum: No registered users and 1 guest