Articles & Books

John Lakos interviews Alexander Stepanov and Daniel Rose on their new Book

Published on InformIT in which John Lakos interviews Alexander Stepanov and Daniel Rose about various aspects of generic programming and modern C++.

From Mathematics to Generic Programming: An Interview with Alexander Stepanov and Daniel RoseFrom Mathematics to Generic Programming

 

John Lakos interviews Alexander Stepanov and Daniel Rose, authors of From Mathematics to Generic Programming, on their new book, why it applies to everyday programmers, and their positions on some closely related technical issues — including value semantics, concepts, contracts, and polymorphic memory resources — facing the C++ Standards Committee today.

Fighting off memory leaks and errors (C++11) -- Kacper KoƂodziej

This article talks about how modern C++ idioms could be used to avoid memory leak and errors.

Fighting off memory leaks and errors (C++11)

by Kacper Kolodziej

From the article:

Modern tools provided with C++11's standard library make fight with memory leaks and errors easier and more effective. Sometimes problems which are seemingly not dangerous might put an end to your application. We are going to learn how to find and avoid them.
 

Counting bits -- Jens Weller

How to generate random bytes and how generic programming allow/support reuse code for different types.

   Counting bits

   by Jens Weller

From the article:

I did a bit of fun coding. I'm currently thinking on how to generate random bytes, for example the 16 random bytes for the initialization vector of AES. The mersenne twister RNG is known to give very good randomness, so it would be a possible an easy source. An std::array<uint32_t,4> would be a good container, filled with generate. But first, I wanted to know, how random is the mersenne twister really? So, when counting the bits in the result of a few thousand calls to a rng, the distribution should be even. So, today I wrote code that counts bits, and tested it on the mersenne twister.

 

Common Algorithm Patterns -- Scott Prager

An interesting article concerning ranges, and how to make the ever useful algorithm header even more effective:

Common algorithm patterns

by Scott Prager

From the article:

Of the STL, <algorithm> may be the most well-used non-container library, but often requires a level of verbosity that requires just as much typing as the hand-written loop, making it not always feel so convenient. It benefits code that uses it with increased clarity and mathematical soundness, so reducing the syntactic overhead should be a goal of those using it. Today I will talk about these problems and demonstrate ways of making it more terse and sound.

C++17 Library Papers for Cologne - Part II

The second and last part in my miniseries about the library papers for next weeks LWG Meeting:

C++17 Library Papers for Cologne - Part II

by Jens WEller

From the article:

This is the second part about the papers for the Library Working Group Meeting in Cologne next week. The last part already covered some interesting papers, and gives an impression on what will be included into the Standard Library for C++17...

Convenient Constructs For Stepping Through a Range of Values -- Mikhail Semenov

A timely article, as there has been an extensive flurry of discussion within the committee over the past weekend about defaults for the ranged for:

Convenient Constructs For Stepping Through a Range of Values

by Mikhail Semenov

From the article:

In this article, the following loops are proposed:

for (auto x : step(start, count, step-width)) { ... }

for (auto x : step(count)) {...}

for (auto x : step_backward(count)) {...}

for (auto x : step_to(start, finish, step-width)) {...}

for (auto x : step_until(start, finish, step-width)) {...}

They are based on the C++11 for-range loop. In order to write such loops, the appropriate functions step, step_backward, step_to and step_until have to be implemented.  The article shows their implementation, discusses advantages of such loops and includes the benchmark results.

Null Pointer Dereferencing Causes Undefined Behavior

I have unintentionally raised a large debate recently concerning the question if it is legal in C/C++ to use the &P->m_foo expression with P being a null pointer. The programmers' community divided into two camps. The first claimed with confidence that it wasn't legal while the others were as sure saying that it was. Both parties gave various arguments and links, and it occurred to me at some point that I had to make things clear.

Null Pointer Dereferencing Causes Undefined Behavior

by Andrey Karpov

From the article:

This code is incorrect in both C and C++ when the podhd pointer equals 0. If the pointer equals 0, undefined behavior occurs.

 

JSON Voorhees - Killer JSON for C++--Travis Gockel

Yet another JSON library for C++:

JSON Voorhees, GitHub link

by Travis Gockel

From the article:

JSON Voorhees is a JSON library written for the C++ programmer who wants to be productive in this modern world. What does that mean? There are a ton of JSON libraries floating around touting how they are "modern" C++ and so on. But who really cares? JSON Voorhees puts the focus more on the resulting C++ than any "modern" feature set. This means the library does not skip on string encoding details like having full support for UTF-8. Are there "modern" features? Sure, but this library is not meant to be a gallery of them – a good API should get out of your way and let you work. It is hosted on GitHub and sports an Apache License, so use it anywhere you need...

Iterators++, Part 2 -- Eric Niebler

Eric Niebler goes deeper into Iterator details in his new blog post

 

Iterators++, Pat 2

by Eric Niebler

From the article:

This is the third in a series about proxy iterators, the limitations of the existing STL iterator concept hierarchy, and what could be done about it. In the first post I explained what proxy iterators are (an iterator like vector<bool>‘s that, when dereferenced, returns a proxy object rather than a real reference) and three specific difficulties they cause in today’s STL:

  1. What, if anything, can we say in general about the relationship between an iterator’s value type and its reference type?
  2. How do we constrain higher-order algorithms like for_each and find_if that take functions that operate on a sequence’s elements?
  3. How do we implement algorithms that must swap and move elements around, like sort and reverse?