Articles & Books

Comparison of C++ Format and C library’s printf—Victor Zverovich

The C printf family is still the gold standard of performance for formatted I/O, but woefully fragile and inextensible. C++'s iostreams offers important advantages in type safety, but struggles with performance and internationalization.

A number of projects, such as Boost.Format, try to the advantages of both. Here's further discussion about one such library we linked to recently:

Comparison of C++ Format and C library's printf

by Victor Zverovich

From the article:

I was recently asked on GitHub why would someone use fmt::printf, which is a part of the C++ Format library, over the standard C library printf. This is a fair question and so I decided to write this blog post comparing the two.

Disclaimer: I’m the author of C++ Format, so this is all very biased =).

Operator Overloading – Introduction to Boost.Operators—Arne Metz

Arne Mertz goes into the details of using boost operators.

Operator Overloading – Introduction to Boost.Operators, Part 1

Operator Overloading – Introduction to Boost.Operators, Part 2

by Arne Mertz

From the articles:

In my first two posts about operator overloading I have written about the basics and common practice. This post shows some lessons from the common practice post on a concrete example and then introduces to Boost.Operators, a library that conveniently reduces the boilerplate involved when overloading multiple operators for a class.

Operators Travel in Packs

If we look at the list of operators, we see that there are about 50 of them, and many of them can be overloaded in different ways. Even if we restrict ourselves to a few operations that make sense for a given class, then one of those operations often brings two or more operators.


SFINAE std::result_of? Yeah, right!—Scott Prager

On the matter of having a useful error message:

SFINAE std::result_of? Yeah, right!

by Scott Prager

From the article:

Return type deduction pre-decltype and auto could really make one mad. Back then, if you wanted a function object, you had to make it "adaptable", meaning it had to inherit from std::unary_ or binary_function and define its first_argument_type, second_argument_type, and result_type. There had been no concept of "transparent functors" allowing us to pass polymorphic functions to higher order functions (like std::plus<> to std::accumulate). For an example of programming in these dark ages, check out the FC++ FAQ.


Type Deduction and Braced Initializers—Arne Mertz

If you are confused about the topic, read this article:

Type Deduction and Braced Initializers

by Arne Mertz

From the article:

I just finished watching a talk from CppCon 2014 by Scott Meyers: Type Deduction and Why You Care. All in all it was a very interesting and entertaining talk, and I learned a thing or two, especially about the combination of type deduction and braced initializers. Since this blog is about simplifying the use of C++, I want to have a short look at that special combination and derive a rule of thumb from it...

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