March 23-28, London, UK
By Blog Staff | Dec 8, 2014 12:47 AM | Tags: None
Speaking of Python-C++ convergence:
A Slice of Python in C++
by Eric Niebler
From the article:
This post describes a fun piece of hackery that went into my Range-v3 library recently: a Python-like range slicing facility with cute, short syntax. It’s nothing earth-shattering from a functionality point of view, but it’s a fun little case study in library design, and it nicely illustrates my philosophy of library design...
By Blog Staff | Dec 4, 2014 09:34 PM | Tags: None
This week on SO:
Is a constexpr more “constant” than const?
The C++ Programming Language Fourth Edition - Bjarne Stroustrup: (emphasis mine)
2.2.3. Constants
In a few places, constant expressions are required by language rules (e.g., array bounds (§2.2.5, §7.3), case labels (§2.2.4, §9.4.2), some template arguments (§25.2), and constants declared using constexpr). In other cases, compile-time evaluation is important for performance. Independently of performance issues, the notion of immutability (of an object with an unchangeable state) is an important design concern (§10.4).
It seems that Stroustrup is suggesting here that
constexprensures immutability of an object better than a traditionalconstdeclaration. Is this correct? Are there ways in whichconstexprcan be more secure/less volatile thanconst, or does Stroustrup simply mean that since there are ways to useconstexprthat are not supported withconst(see Is constexpr really needed?), in those cases immutability can be ensured usingconstexpr?
By Blog Staff | Dec 4, 2014 09:20 PM | Tags: None
In the "better C than C" department:
Memory management of C libraries in C++
by Kevin Dungs
From the article:
Today I had some time to play around with libgit2, an excellent C-library for Git. But since I was thinking about using it together with the freshly released Proxygen, the fast HTTP-framework from Facebook, I wanted to use the library functions from C++ from the start.
This was a perfect opportunity to play around with C++ memory management objects in the context of a C-library...
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 Marcin Hoppe | Dec 4, 2014 03:20 AM | Tags: basics
CoderGears team draws some conclusions on how namespaces are used in C++ projects:
Common reasons of using namespaces in C++ projects
by CodeGears Team
From the article:
Namespaces in C++ are most often used to avoid naming collisions. Although namespaces are used extensively in recent C++ code, most older code does not use this facility. After exploring the source code of many C++ projects, here are some common reasons of using the namespaces in these projects...
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
mutexto keep only onethreadaccess 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...
By Razvan Pascalau | Dec 3, 2014 11:50 AM | Tags: boost basics
Have you used the Boost.Optional library? There is one thing you might need to keep an eye on as explained by Andrzej.
by Andrzej Krzemieński
From the article:
This post is about one gotcha in Boost.Optional library. When starting to use it, you might get the impression that when you try to put
optional<T>whereTis expected, you will get a compile-time error. In most of the cases it is exactly so, but sometimes you may get really surprised...
By Jared Mulconry | Dec 2, 2014 11:25 PM | Tags: c++11 advanced
Quick A: No, because acq_rel doesn't prevent reordering a store to x followed by a load from y... seq_cst does.
Recently on SO:
Why isn't a C++11 acquire_release fence enough for Dekker synchronization?
The failure of Dekker-style synchronization is typically explained with reordering of instructions. I.e., if we write
atomic_int X; atomic_int Y; int r1, r2; static void t1() { X.store(1, std::memory_order_relaxed) r1 = Y.load(std::memory_order_relaxed); } static void t2() { Y.store(1, std::memory_order_relaxed) r2 = X.load(std::memory_order_relaxed); }Then the loads can be reordered with the stores, leading to
r1==r2==0.I was expecting an acquire_release fence to prevent this kind of reordering:
static void t1() { X.store(1, std::memory_order_relaxed); atomic_thread_fence(std::memory_order_acq_rel); r1 = Y.load(std::memory_order_relaxed); } static void t2() { Y.store(1, std::memory_order_relaxed); atomic_thread_fence(std::memory_order_acq_rel); r2 = X.load(std::memory_order_relaxed); }The load cannot be moved above the fence and the store cannot be moved below the fence, and so the bad result should be prevented.
However, experiments show
r1==r2==0can still occur. Is there a reordering-based explanation for this? Where's the flaw in my reasoning?
By Daniel França | Dec 2, 2014 09:39 AM | Tags: python c++14 c++11
A nice article pointing out similarities between modern C++ and Python:
C++ Has Become More Pythonic
by Jeff Preshing
From the article:
C++ has changed a lot in recent years. The last two revisions, C++11 and C++14, introduce so many new features that, in the words of Bjarne Stroustrup, “It feels like a new language.”
It’s true. Modern C++ lends itself to a whole new style of programming – and you can’t help but feel Python’s influence on this new style. Ranged-based for loops, type deduction, vector and map initializers, lambda expressions. The more you explore modern C++, the more you find Python’s fingerprints all over it.
Was Python a direct influence on modern C++? Or did Python simply adopt a few common idioms before C++ got around to it? You be the judge...