Here are some good articles by Bjarne Stroustrup, who designed and implemented the C++ programming language, on C++0x, the next ISO C++ standard:
And a good preview on the new C++0x standard, in German:
Bjarne Stroustrup on C++0x
Best regards,
Carsten
Carsten
Re: Bjarne Stroustrup on C++0x
That's a great FAQ - I'm already using a lot of the things in TR1 like shared_ptr and unordered_map, and I'm really looking forward to some of the other features - especially the concurrency (it will be nice not to have to use platform specific threading libraries) and the range for statement - it looks so much easier than using iterators, which can be ridiculous when you use containers like the unordered_map:
which would be
Code: Select all
for(std::tr1::unordered_map<std::string, Element::Ptr>::iterator it = m_Children.begin();
it != m_Children.end(); it++)
{
it->second->Draw();
}
Code: Select all
for(Element::Ptr e : m_Children)
{
e->Draw();
}
Re: Bjarne Stroustrup on C++0x
Yes, there are many new features in C++0x I'm looking forward to as well!
(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.![Cheesy Grin :cheesy:](./images/smilies/icon_cheesygrin.gif)
(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.
![Cheesy Grin :cheesy:](./images/smilies/icon_cheesygrin.gif)
Best regards,
Carsten
Carsten
Re: Bjarne Stroustrup on C++0x
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 yetCarsten 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.
![Sad :(](./images/smilies/icon_sad.gif)
Re: Bjarne Stroustrup on C++0x
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.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?
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.
![Wink ;-)](./images/smilies/icon_wink.gif)
In summary, I'm still undecided and thus I'll just try both.
![Cheesy Grin :cheesy:](./images/smilies/icon_cheesygrin.gif)
Best regards,
Carsten
Carsten
Who is online
Users browsing this forum: No registered users and 68 guests