Plain threads are the GOTO of todays computing
I'd like to share with you Hartmut Kaisers Keynote from Meeting C++ 2014:
Plain Threads are the GOTO of todays Computing
by Hartmut Kaiser
Video:
June 16-21, Sofia, Bulgaria
September 13-19, Aurora, CO, USA
October 25, Pavia, Italy
November 6-8, Berlin, Germany
November 16-21, Kona, HI, USA
By Meeting C++ | Dec 19, 2014 03:57 AM | Tags: threading performance parallelism keynote intermediate experimental efficiency advanced
I'd like to share with you Hartmut Kaisers Keynote from Meeting C++ 2014:
Plain Threads are the GOTO of todays Computing
by Hartmut Kaiser
Video:
By Adrien Hamelin | Dec 15, 2014 08:00 AM | Tags: intermediate c++14
Some thoughts about how to visit nodes of a graph:
A function to visit nodes of a graph with C++14
by Adrien Hamelin
From the article:
Visiting a graph is something useful. [...] A classical way to do that is to implement the visitor pattern. [...] it requires to create a Visitor class and to modify each of the possibly visited class to add a virtual accept function. [...] It works well, but surely we can do better...
By Felix Petriconi | Dec 10, 2014 08:34 AM | Tags: intermediate boost
Do you know Boost.Pointer Container? Andrzej gives some useful information in his recent blog entry:
A gotcha with ptr_vector
He gives answers to these questions:
What would you use
boost::ptr_vector
for? Why would you need to have a vector of pointers, which you want to delete yourself? Is it because:
- You want the objects to remain at the same address even if you re-allocate the array under the vector?
- You want to inter-operate with a library that already deals with owing pointers?
- You want it to be faster than if you were storing values in
std::vector
?- You want the “polymorphic behavior” of your objects?
By Aurelia-Doina Popa | Dec 10, 2014 08:32 AM | Tags: visual studio intermediate
An article about a security feature in Visual Studio 2015, called Control Flow Guard.
Visual Studio 2015 Preview: Work-in-Progress Security Feature
by Jim Hogg
From the article:
By simply adding a new option to your Project, the Visual C++ compiler will inject extra security checks into your binaries. These will detect attempts to hijack your code. The check will stop execution of your code, before the hijacker can do damage to your data or PC...
By Razvan Pascalau | Dec 8, 2014 05:33 PM | Tags: openmp intermediate compiler clang
A status update for the work done on OpenMP for Clang/LLVM and future directions presented at the 2014 LLVM Developers' Meeting. The slides are also available here.
OpenMP* Support in Clang/LLVM: Status Update and Future Directions
OpenMP is a well-known and widely used API for shared-memory parallelism. Support for OpenMP in Clang/LLVM compiler is currently under development. In this talk, we will present current status of OpenMP support, what is done and what remains to be done, technical details behind OpenMP implementation. Also, we will elaborate on accelerators and pragma-assisted SIMD vectorization, introduced in the latest 4.0 edition of the OpenMP standard.
By Patrick Niedzielski | Dec 8, 2014 12:34 PM | Tags: intermediate
Quick A: By exposing wrapped iterators in your interface.
From Programmers StackExchange, StackOverflow's sister site:
Allow iteration of an internal vector without leaking the implementation
I have a class that represents a list of people.
class AddressBook { public: AddressBook(); private: std::vector<People> people; }I want to allow clients to iterate over the vector of people. The first thought I had was simply:std::vector<People> & getPeople { return people; }However, I do not want to leak the implementation details to the client. I may want to maintain certain invariants when the vector is modified, and I lose control over these invariants when I leak the implementation.
What's the best way to allow iteration without leaking the internals?
By Adrien Hamelin | Dec 8, 2014 01:58 AM | Tags: intermediate
Bartlomiej Filipek shares with us five algorithms using the C++ STD:
Top 5 Beautiful C++ STD Algorithms Examples
by Bartlomiej Filipek
From the article:
Some time ago I've seen an inspiring talk from CppCon 2013: "C++ Seasoning" by Sean Parent. One of the main points of this presentation was not to use raw loops. Instead, prefer to use existing algorithms or write functions that 'wraps' such loops. I was curious about this idea and searched for nice code examples. Here is my short list of usage of algorithms from the C++ std library that might help in writing better code.
Of course. I could not skip two prominent examples from the original "C++ Seasoning" talk: slide and gather...
By Blog Staff | Dec 4, 2014 09:13 PM | Tags: intermediate basics
Overload 124 is now available. It contains the following C++-related articles, and more:
The observer pattern is over two decades old. Alan Griffiths fits a venerable design pattern into a contemporary context.
What does complexity measurement mean? Roger Orr reminds us of the academic definition and looks at some real life situations... std::sort
is faster than qsort
which can come as a surprise to those who assume C is always faster than C++.
By Jared Mulconry | Dec 3, 2014 09:47 PM | Tags: intermediate c++11
Quick A: There is no guarantee that threads
will run in a given order.
Recently on SO:
Why don't these threads run in order?
When I run this code:
#include <iostream> #include <thread> #include <mutex> std::mutex m; int main() { std::vector<std::thread> workers; for (int i = 0; i < 10; ++i) { workers.emplace_back([i] { std::lock_guard<std::mutex> lock(m); std::cout << "Hi from thread " << i << std::endl; }); } std::for_each(workers.begin(), workers.end(), [] (std::thread& t) { t.join(); }); }I get the output:
Hi from thread 7 Hi from thread 1 Hi from thread 4 Hi from thread 6 Hi from thread 0 Hi from thread 5 Hi from thread 2 Hi from thread 3 Hi from thread 9 Hi from thread 8Even though I used a
mutex
to keep only onethread
access at a time. Why isn't the output in order?
By Adrien Hamelin | Dec 3, 2014 02:13 PM | Tags: intermediate embedded
E.S.R. Labs presents its STL library adapted to embedded environments and discusses some of the choices they made for it:
C++ STL for Embedded Developers
by John Hinke
From the article:
C++ embedded programming is very difficult. There are some limitations that are not always present in traditional programming environments such as limited memory, slower processors, and older C++ compilers.
We have developed a set of best-practice processes and frameworks to support writing high-quality embedded applications...