Quick Q: Is constexpr more constant than const? -- StackOverflow

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 constexpr ensures immutability of an object better than a traditional const declaration. Is this correct? Are there ways in which constexpr can be more secure/less volatile than const, or does Stroustrup simply mean that since there are ways to use constexpr that are not supported with const (see Is constexpr really needed?), in those cases immutability can be ensured using constexpr?

Memory management of C libraries in C++ -- Kevin Dungs

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...

Overload 124 is now available

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:

Overload 124

Designing Observers in C++11

The observer pattern is over two decades old. Alan Griffiths fits a venerable design pattern into a contemporary context.

Order Notation in Practice

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++.

Monads in C++14 -- C/C++ Meetup, January 15, Madrid, Spain

By Jordi Mon Companys | Dec 4, 2014 08:25 AM | Tags: community c++14

The January C/C++ Madrid Meetup will be about monads.

Note the new location: The Madrid meetup usually takes place in biicode's offices, but the community is growing so much we had to move to Tuenti's offices.

Monads in C++14

by Joaquín Mª López Muñoz

Thursday 15^th January 2015, Madrid, Spain.

Common reasons of using namespaces in C++ projects -- CoderGears Team

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...

Quick Q: Are std::threads run in the order they're created?--StackOverflow

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 8

Even though I used a mutex to keep only one thread access at a time. Why isn't the output in order?

C++ STL for Embedded Developers--John Hinke

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...

Valgrind 3.10.1 released

By Adrien Hamelin | Dec 3, 2014 01:43 PM | Tags: None

Valgrind, a useful tool for any C++ developer released a new version today:

Valgrind 3.10.1 released

From the announcement:

3.10.1 is a bug fix release. It fixes various bugs reported in 3.10.0 and backports fixes for all reported missing AArch64 ARMv8 instructions and syscalls from the trunk. If you package or deliver 3.10.0 for others to use, you might want to consider upgrading to 3.10.1 instead.

A gotcha with Boost.Optional --Andrzej Krzemieński

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.

  A gotcha with Optional

  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> where T is expected, you will get a compile-time error. In most of the cases it is exactly so, but sometimes you may get really surprised...

Quick Q: Is an acquire_release fence enough for Dekker synchronization?--StackOverflow

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==0 can still occur. Is there a reordering-based explanation for this? Where's the flaw in my reasoning?