Articles & Books

Know your libraries -- Arne Mertz

Prefer standard library over handcrafted logic/algorithm.

Know your libraries

by Arne Mertz

From the article:

I often see people use handcrafted loops or write weird workarounds for stuff the standard library has already taken care of. This does not only apply for standard library features but also for any other library, like Boost, other third party libraries and the libraries the code belongs to. That is bad for several reasons, and I am going to lay out what I think every developer should be required to do before he writes production code.

Two fundamental implementations for one conceptual object -- Mark Isaacson

From the Modern Maintainable Code blog:

Two fundamental implementations for one conceptual object

by Mark Isaacson

From the article:

This is the third article of a series on code reuse. This article discusses how to select between implementations of an object based on patterns in type information. The article uses std::unique_ptr's deleter as a practical case study.

You can find the previous article of the series here (which discusses the analogous problem as it pertains to functions), and the prelude to the next article, which looks at the same problem with one caveat: designing it so that some, but not all, of the methods will be implemented the same way no matter what types you instantiate the object with, here.

Using Enum Classes as Bitfields -- Anthony Williams

How to use enum classes as as bitfields in modern C++ programs.

Using Enum Classes as Bitfields

by Anthony Williams

From the article:

C++11 introduced a new feature in the form of scoped enumerations, also referred to as enum classes, since they are introduced with the double keyword enum class (though enum struct is also permissible, to identical effect). To a large extent, these are like standard enumerated types: you can declare a list of enumerators, which you may assign explicit values to, or which you may let the compiler assign values to. You can then assign these values to variables of that type. However, they have additional properties which make them ideal for use as bitfields. I recently answered a question on the accu-general mailing list about such a use, so I thought it might be worth writing a blog post about it.

 

Effective Modern C++ eBook Sample Content -- Scott Meyers

Scott Meyers just published on his blog, that one can get a free sample chapter of his EMC++ book.

EMC++ Sample Content

by Scott Meyers

From the article

O'Reilly has decided it's time to turn up the heat on the grand Effective Modern C++ marketing campaign. A key component of that campaign is giving away excerpts of the book, the idea being that if you like the stuff we give away, you're more likely to plunk down some cash for the rest of the book.

Yes, we must replace it++ with ++it--Andrey Karpov

I decided to find out if there is practical sense in writing ++iterator instead of iterator++ when handling iterators.

Is it reasonable to use the prefix increment operator ++it instead of postfix operator it++ for iterators?

by Andrey Karpov

From the article:

I will always write ++it. I did so before but I did it "just in case". Now I can see how useful it is because I regularly launch debug versions. In general, of course, ++it has a very slight influence on the running time. But if I don't make such small optimizations in different places of the code, it will be too late and the profiler won't help me. Bottlenecks will be spread throughout the code.

 

Funny bug #20150127--Marco Foco

Marco Foco spotted a subtle bug in a piece of code that used boost::program_options. Can you find it?

Funny bug #20150127

by Marco Foco

From the article:

Two days ago I’ve been asked to have a look at a nonworking piece of code, based on boost::program_options [...] This syntax is not only unusual, but also dangerous. 

To Be or Not to Be (an Iterator) -- Eric Niebler

Eric Niebler gives in his recent blog post insights about iterators

To Be or Not To Be (an Iterator)

by Eric Niebler

From the article:

Way back in 1999, when the ink on the first C++ standard was still damp, Herb Sutter posed a GoTW puzzler in the still extant C++ Report (RIP): When Is a Container Not a Container? In that article, Herb described the problems of the now-infamous vector<bool>. According to the standard’s own container requirements, vector<bool> is not a container.

In a nutshell, it’s because vector<bool>‘s iterators claim to be random-access, but they’re not. Random-access iterators, when you dereference them, must return a real reference. They can only do that if the thing they point to really exists somewhere. But the bool that a vector<bool>::iterator points to does not exist anywhere. It’s actually a bit in a packed integer, and dereferencing a vector<bool>‘s iterator returns an object of some type that merely acts like a bool& without actually being a bool&.

Experimenting with a Proposed Standard Drawing Library for the C++ language -- Eric Mittelette

Today on MSOT:

Experimenting with a Proposed Standard Drawing Library for the C++ language

by Eric Mittelette

From the article:

Back in July, Michael McLaughlin, Herb Sutter, and Jason Zink submitted to the ISO an updated proposal to standardize a 2D Graphics API for the C++ programming language. The ISO C++ Committee will evaluate the proposal for the possible inclusion of these new features in the next versions of the specification.

Given MS Open Tech’s historical interest in cross-platform graphics development, we took a closer look. In an attempt to familiarize with the API from the perspective of a C++ developer, we developed a sample app that we just contributed to Michael’s github repository. In the sections below, we share some salient aspects of how this new crop of Graphics experiences built with “straight” C++ could be written, only a few years from now!
 

 

The compiler can make up its own calling conventions, within limits--Raymond Chen

A new article from the Old New Thing:

The compiler can make up its own calling conventions, within limits

by Raymond Chen

From the article:

There are three parties to a calling convention. The function doing the calling. The function being called. The operating system. The operating system needs to get involved if something unusual occurs, like an exception, and it needs to go walking up the stack looking for a handler...