Core C++ #10 -- Stephan T. Lavavej

By Blog Staff | Nov 18, 2013 04:41 PM | Tags: intermediate basics advanced

Accompanying today's release of the VC++ CTP, there is a new talk by Stephan T. Lavavej available covering several major C++11 and draft C++14 features that are of likely interest to C++ developers using any compiler.

Core C++, 10 of n (Nov 2013 CTP)

by Stephan T. Lavavej

From the summary:

In part 10, STL explores the new features in the Visual C++ Compiler November 2013 CTP (Community Technology Preview), in addition to the features that were added between VC 2013 Preview and RTM.

Features included in the November CTP ( generic lambdas!!! Smiley ):

C++11, C++14, and C++/CX features:

• Implicit move special member function generation (thus also completing =default)
• Reference qualifiers on member functions (a.k.a. "& and && for *this")
• Thread-safe function local static initialization (a.k.a. "magic statics")
• Inheriting constructors
• alignof/alignas
• __func__
• Extended sizeof
• constexpr (except for member functions)
• noexcept (unconditional)
• C++14 decltype(auto)
• C++14 auto function return type deduction
• C++14 generic lambdas (with explicit lambda capture list)
• (Proposed for C++17) Resumable functions and await

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.

Meeting C++ 2013

By Meeting C++ | Nov 14, 2013 07:16 AM | Tags: intermediate conferences concurrency community c++14 c++11 boost basics advanced

The recent Meeting C++ 2013 was a blast, the 2nd Meeting C++ conference was with over 200 guests a full success!

Meeting C++ 2013

by Jens Weller

Additional Online Resources:

Stephen Kelly about CMake for Qt and Boost

The talks from Peter Sommerlad

Sven Johannsens HTML based talk about STL11 is online.

Available slides are linked in the talk descriptions.

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)
                ^

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.

Exception safety: The strong guarantee and move semantics

By Blog Staff | Nov 4, 2013 01:27 AM | Tags: intermediate

An interesting question was asked recently on StackOverflow that nicely ties in with Scott Meyers' "Effective C++11/14 Sampler" talk two months ago at GoingNative 2013 and the interestingly named feature std::move_if_noexcept, both referenced in the answers.

Since the gorier details of the answer lie in "watch Scott's talk," we merrily abuse a snapshot of Dr. Meyers during said talk as the highlight graphic for this post.

Exception safe code and move semantics

I want to write container class. This container has insert method that have two specializations -- first uses copy constructors to copy data from one container to another container element wise. If copy constructor throws exception I just undo all changes to the container like nothing happens.

The second specialization uses move constructor and thats the place where things got complicated. When I move items from one container to another container element by element, move constructor can throw exception. If this happens -- I've got really messy state when some elements are moved and other elements stays in it's original places. If I try to move elements back -- I can get another exception.

Is it possible to write something like this in exception safe manner or exception safety and move semantics are mutually exclusive?

C++ User Group Meetings November

By Meeting C++ | Nov 2, 2013 04:58 PM | Tags: intermediate community basics

An overview of C++ User Groups which meet in November:

C++ User Group Meetings in November

by Jens Weller

From the Article:

November has come, Meeting C++ Conference is soon...
... and also 12 C++ User Groups are meeting...

New Adventures in C++ with Cinder and More -- Ale Contenti

By NoSenseEtAl | Oct 31, 2013 08:15 AM | Tags: intermediate

The Cinder C++ library for graphics got a shout-out from Herb Sutter at GoingNative'13, and now we get a full hour-long talk about Cinder from Visual Studio's own Ale Contenti.

New Adventures in C++ with Cinder and More

Play and be productive with modern C++, graphics, on-the-fly projects and more! Starting from the latest Going Native 2013 talks as an inspiration, we will explore how easy is to mold ideas into graphics apps with C++ and Cinder, and how simple tools and techniques can help us be more productive in Visual Studio!

Watch the video, or download the slides.