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:

1. 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.
2. 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.
3. 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.
4. 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. ...

Automatically Made Weak -- Brett Hall

By Blog Staff | Nov 12, 2013 02:13 PM | Tags: intermediate

A nice nugget about a handy make_weak one-liner:

Automatically Made Weak

by Brett Hall

From the article:

I’ve been experimenting with the new “auto everything” style in C++. I also make regular use of std::weak_ptr... [and wouldn't it be nice if] we can just type

auto weak = make_weak(shared);

Quick Q: May the return value optimization remove side effects of copying? -- StackOverflow

By Blog Staff | Nov 11, 2013 01:26 PM | Tags: intermediate

Quick A: Yes. That's kind of the point, actually.

This weekend on StackOverflow:

Return value optimizations and side-effects

Return value optimization (RVO) is an optimization technique involving copy elision, which eliminates the temporary object created to hold a function's return value in certain situations. I understand the benefit of RVO in general, but I have a couple of questions.

The standard says the following about it in §12.8, paragraph 32 of this working draft (emphasis mine).

When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization.

It then lists a number of criteria when the implementation may perform this optimization.

I have a couple of questions regarding this potential optimization:

1. I am used to optimizations being constrained such that they cannot change observable behaviour. This restriction does not seem to apply to RVO. Do I ever need to worry about the side effects mentioned in the standard? Do corner cases exist where this might cause trouble?
2. What do I as a programmer need to do (or not do) to allow this optimization to be performed? For example, does the following prohibit the use of copy elision (due to the move):

std::vector<double> foo(int bar){
    std::vector<double> quux(bar,0);
    return std::move(quux);
}

Quick Q: Should you overload func(X) and func(X&&)? -- StackOverflow

By Blog Staff | Nov 11, 2013 10:39 AM | Tags: intermediate

Quick A: No. But you can and often should overload func(X&) with func(X&&) (with const on the parameter if appropriate in either or both).

Here is the salient part of the SO question -- ignore the question's original title, because it's perfectly fine to overload pass-by-reference and pass-by-rvalue-reference where the former can be implemented using the normal copy-and-swap idiom:

Move assignment incompatible with standard copy and swap

[...] Here the assignment to a should use the "Move Assignment" operator. But there is a clash with the "Standard Assignment" operator (which is written as your standard copy and swap).

> g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

> g++ -std=c++11 String.cpp
String.cpp:64:9: error: use of overloaded operator '=' is ambiguous (with operand types 'String' and 'String')
    a   = String("Test Move Assignment");
    ~   ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
String.cpp:32:17: note: candidate function
        String& operator=(String rhs)
                ^
String.cpp:54:17: note: candidate function
        String& operator=(String&& rhs)
                ^

Input Iterators vs. Input Ranges -- Eric Niebler

By Blog Staff | Nov 8, 2013 07:50 AM | Tags: None

Trust Eric Niebler to deliver the goods -- when it comes to insightful discussion, cool code, and shameless puns:

Input Iterators vs. Input Ranges

by Eric Niebler

From the article:

The solution to istream_iterator's woes will be to replace it with istream_range. Put simply, if we’re reading strings from a stream, the string needs to live somewhere. The iterator seemed like the logical place when we were all thinking strictly in terms of iterators. But with ranges, we now have a much better place to put it: in the range object.

Why does C++ not allow multiple types in one auto statement? -- StackOverflow

By Blog Staff | Nov 7, 2013 12:20 PM | Tags: basics

Recently on SO:

Why does C++ not allow multiple types in one auto statement?

The 2011 C++ standard introduced the new keyword auto, which can be used for defining variables instead of a type, i.e.

auto p=make_pair(1,2.5);                   // pair<int,double>
auto i=std::begin(c), end=std::end(c);     // decltype(std::begin(c))

In the second line, i and end are of the same type, referred to as auto. The standard does not allow

auto i=std::begin(container), e=std::end(container), x=*i;

when x would be of different type. My question: why does the standard not allow this last line? ...

Ode To a Flat Set -- Jon Kalb

By Blog Staff | Nov 7, 2013 11:16 AM | Tags: performance intermediate efficiency boost

A nice short overview of when you might want your associative container to use a contiguous implementation instead of a tree under the covers:

Ode to a Flat Set

by Jon Kalb

From the article:

The Boost Container library has a family of flat_* containers that have associative container interfaces and semantics, but are implemented as sorted vectors.

In addition to faster lookup, the flat_* containers have much faster iteration, less memory overhead, fewer allocations, and improved cache performance.

However, as with all things, there are trade-offs.