Articles & Books

Enabling forward traversal -- Krzysztof Ostrowski

Krzysztof Ostrowski describes in his article enabling iteration over a sequence of objects of given type without changing the type name itself.

Enabling forward traversal

by Krzysztof Ostrowski

From the article:

Let's consider following example. We have legacy interface that constructs object of type T using information stored in object of type U:

bool build_from(T& into, const U& from);

Such a build_from can be deserialiser function, e.g. from JSON to C++ type, for example:

result_type deserialise(T& into, const json_node_type& from);

Ideally, we should return into rather than taking it as an input argument, i.e. return optional<T> or type that carries information about the errors too, like C++ counterpart of Either. Unfortunately, we have to deal with legacy interafce, so that existing contracts cannot be broken, and our patch sets shall favour composition and extension over the modification.

With deserialise we know how to convert internal JSON representation into object of type T. That works fine for non-structured types. JSON offers associative containers (dictionaries, hashes, structures as defined in YAML) and collections. Dictionaries map easily to product types, struct in C++, and for those we typically need custom deserialisation procedures. Collections may be seen as abstractions over structures, or – more functionally – as sequenced values of type T for collection of type [T]. Since we know how to deserialise objects of type T, we can deserialise [T] by simply mapping deserialise over a sequence of T objects, that is doing forward traversal. Unfortunately we have just one JSON node from, not a sequence of nodes. We need to enable forward traversal for the type json_node_type with minimal number of changes.

Quick Q: Do mutexes guarantee ordering of acquisition?

Quick A: They do not.

Recently on SO:

Do mutexes guarantee ordering of acquisition?

Known problem. C++ mutexes are thin layer on top of OS-provided mutexes, and OS-provided mutexes are often not fair. They do not care for FIFO.

The other side of the same coin is that threads are usually not pre-empted until they run out of their time slice. As a result, thread A in this scenario was likely to continue to be executed, and got the mutex right away because of that.

Overload 133 is now available

ACCU’s Overload journal of April 2016 is out. It contains the following C++ related articles.

Overload 132

From the journal:

Dogen: The Package Management Saga
How do you manage packages in C++? Marco Craveiro eventually discovered Conan after some frustrating experiences. by Marco Craveiro

QM Bites – Order Your Includes (Twice Over)
Header includes can be a shambles. Matthew Wilson encourages us to bring some order to the chaos. by Matthew Wilson

A Lifetime In Python
Resource management is important in any language. Steve Love demonstrates how to use context managers in Python. by Steve Love

Deterministic Components for Distributed Systems
Non-deterministic data leads to unstable tests. Sergey Ignatchenko considers when this happens and how to avoid it. by Sergey Ignatchenko

Programming Your Own Language in C++
Scripting languages allow dynamic features easily. Vassili Kaplan writes his own in C++ allowing keywords in any human language. by Vassili Kaplan

Concepts Lite in Practice
Concepts should make templates easier to use and write. Roger Orr gives a practical example to show this. by Roger Orr

Afterwood
Magazines sometimes use the back page for adverts or summaries. Chris Oldwood has decided to provide us with his afterwords, or ‘afterwood’. by Chris Oldwood

Implementing Queues for Event-Driven Programs--“No Bugs” Hare

An interesting article:

Implementing Queues for Event-Driven Programs

by “No Bugs” Hare

From the article:

We’ve already discussed things related to sockets; now let’s discuss the stuff which is often needed (in particular, it is of Utmost Importance when implementing Reactors), but which is not that common to be universally available as a part of operating system.

I’m speaking about queues. And not only just about “some” queue, but about queues which have certain properties desirable for our Reactors a.k.a. ad-hoc Finite State Machines a.k.a. Event-Driven Programs.

Quick Q: c++ lambda capture by value

Quick A: A capture by value is a copy.

Recently on SO:

c++ lambda capture by value

That's because the variable is captured by value (i.e. copied) only once, when you define the lambda. It's not "updated" as you may believe. The code is roughly equivalent to:

#include <iostream>

int x = 0;
struct Lambda
{
    int _internal_x; // this is used to "capture" x ONLY ONCE
    Lambda(): _internal_x(x) {} // we "capture" it at construction, no updates after
    void operator()() const
    {
        std::cout << _internal_x << std::endl;
    }
} qqq;

int main()
{
    qqq();
    x = 77; // this has no effect on the internal state of the lambda
    qqq();
}