Articles & Books : Standard C++

While we're waiting for Concepts Lite, Eric shows how we can already do quite a bit in C++11 while planning for a transition to language support when it's available.

Concept Checking in C++11

by Eric Niebler

From the article:

This post describes some utilities I’ve recently developed for doing concept checking in C++11. These utilities are part of an ongoing project to reimplement ranges, also for C++11, but I think the concept checking utilities are useful and interesting in their own right...

Basic Structure of C++ Program -- Prashant Sharma

By prashant0788 | Nov 22, 2013 12:44 PM | Tags: basics

[Ed.: This is a simple short "hello world" overview for someone starting to program in C++, and is basically correct. There are lots of expert-friendly articles, but we like and want to encourage the beginner- and intermediate-level articles as well for the benefit of the many recent newcomers to the language.]

Basic Structure of C++ Program

The easiest way to understand the basic structure of C++ program is by writing a program. The basic C++ program is as follows: ...

Quick Q: Why is std::vector contiguous? -- StackOverflow

By Blog Staff | Nov 20, 2013 02:15 PM | Tags: intermediate

Quick A: Because if you're serious about performance, you'll often (not always) use contiguous arrays.

From SO:

Why is std::vector contiguous?

Besides the fact that the standard defines it to be contiguous, why is std::vector contiguous?

If it runs out of space, it needs to reallocate a new block and copy the old block to the new one before continuing.

What if it wasn't contiguous? When the storage fills up, it would just allocate a new block and keep the old block. When accessing through an iterator, it would do simple >, < checks to see which block the index is in and return it. This way it doesnt need to copy the array every time it runs out of space.

Would this really work/be better? or am i missing something?

C++11 Annoyance Avoiders -- Tony DaSilva

By Blog Staff | Nov 19, 2013 02:57 PM | Tags: None

A useful short nugget: override FTW!

C++11 Annoyance Avoiders

by Tony DaSilva

From the article:

I’ve always been torn as to whether or not to annotate derived class member functions intended to override base class members as virtual...

Type Erasure, Part 1 -- Andrzej Krzemieński

By Blog Staff | Nov 19, 2013 09:47 AM | Tags: intermediate

What is this "type erasure" thing you speak of? It's not something at the other end of a pencil (remember those?) but a way to hold an object without knowing its exact type. Andrzej explains:

Type Erasure, Part 1

by Andrzej Krzemieński

From the article:

Have you ever came across term type erasure in C++? This “pattern” or “technique” is growing more and more popular. In this post I will try to describe what it is. Note that it is something different than a similar term in Java.

What does type encode?

Let’s start with describing the opposite of type erasure. We could call such situation “type-full-ness”. Forget the term though, let me illustrate what I mean with an example. ...

Quick Q: Why is there a nonmember begin(), but no nonmember cbegin()? -- StackOverflow

By Blog Staff | Nov 19, 2013 08:22 AM | Tags: basics

Quick A: There is, in C++14.

From SO:

Is there a way to use standalone std::begin and for a const_iterator?

I like consistency. I recently asked the question of using std::begin vs. e.g. std::vector<int>::begin, and the unanimous decision seemed to be to use the former since it is more general. But I think I found a stick in the mud. Sometimes, you want to convey you will not change a container as you loop through it, hence calling std::vector<int>::cbegin. It would make your code quite asymmetric if you sometimes did iter = v.cbegin() and other times did iter = begin(v). Is there a way around this lack of symmetry, and would you still recommend std::begin given this knowledge? Why does C++ not have std::cbegin?

Quick Q: Can you move out of an initializer_list? -- StackOverflow

By Blog Staff | Nov 18, 2013 03:04 AM | Tags: intermediate

Quick A: No, because the contents are const.

A classic from SO, recommended by a developer team that encountered this situation again in the past week:

initializer_list and move semantics

Am I allowed to move elements out of a std::initializer_list<T>?
#include <initializer_list>
#include <utility>

template<typename T>

void foo(std::initializer_list<T> list)
{
    for (auto it = list.begin(); it != list.end(); ++it)
    {
        bar(std::move(*it));   // kosher?
    }
}
Since std::intializer_list<T> requires special compiler attention and does not have value semantics like normal containers of the C++ standard library, I'd rather be safe than sorry and ask.

The best of Boost, and using Boost the best

By Blog Staff | Nov 14, 2013 03:22 PM | Tags: None

Well timed with the recent release of Boost 1.55, a new Reddit thread just highlighted two useful books about Boost:

The first book is available online, with a second edition released in print in 2011:

The Boost C++ Libraries

by Boris Schäling

Table of Contents

Chapter 1: Introduction

Chapter 2: Smart Pointers

Chapter 3: Function Objects

Chapter 4: Event Handling

Chapter 5: String Handling

Chapter 6: Multithreading

Chapter 7: Asynchronous Input and Output

Chapter 8: Interprocess Communication

Chapter 9: Filesystem

Chapter 10: Date and Time

Chapter 11: Serialization

Chapter 12: Parser

Chapter 13: Containers

Chapter 14: Data Structures

Chapter 15: Error Handling

Chapter 16: Cast Operators

The second, the subject of the Reddit thread, was this new release:

Boost C++ Application Development Cookbook

by Antony Polukhin

Overview

Explores how to write a program once and then use it on Linux, Windows, MacOS, and Android operating systems

Includes everyday use recipes for multithreading, networking, metaprogramming, and generic programming from a Boost library developer

Take advantage of the real power of Boost and C++ to get a good grounding in using it in any project

Table of Contents

Preface

Chapter 1: Starting to Write Your Application

Chapter 2: Converting Data

Chapter 3: Managing Resources

Chapter 4: Compile-time Tricks

Chapter 5: Multithreading

Chapter 6: Manipulating Tasks

Chapter 7: Manipulating Strings

Chapter 8: Metaprogramming

Chapter 9: Containers

Chapter 10: Gathering Platform and Compiler Information

Chapter 11: Working with the System

Chapter 12: Scratching the Tip of the Iceberg

Quick Q: Does using std:: smart pointers mean not using raw pointers? -- StackOverflow

By Blog Staff | Nov 13, 2013 11:56 AM | Tags: None

Quick A: No. Smart pointers are for ownership. Raw pointers are still fine for non-owning pointers to an object that outlives the pointer.

C++11 Smart Pointer Semantics

I've been working with pointers for a few years now, but I only very recently decided to transition over to C++11's smart pointers (namely unique, shared, and weak). I've done a fair bit of research on them and these are the conclusions that I've drawn:

Unique pointers are great. They manage their own memory and are as lightweight as raw pointers. Prefer unique_ptr over raw pointers as much as possible.

Shared pointers are complicated. They have significant overhead due to reference counting. Pass them by const reference or regret the error of your ways. They're not evil, but should be used sparingly.

Shared pointers should own objects; use weak pointers when ownership is not required. Locking a weak_ptr has equivalent overhead to the shared_ptr copy constructor.

Continue to ignore the existence of auto_ptr, which is now deprecated anyhow.

So with these tenets in mind, I set off to revise my code base to utilize our new shiny smart pointers, fully intending to clear to board of as many raw pointers as possible. I've become confused, however, as to how best take advantage of the C++11 smart pointers. ...