N3836-38, Evolution Issues Lists -- Ville Voutilainen

By Blog Staff | Jan 16, 2014 12:57 PM | Tags: None

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document numbers: N3836-38

Date: 2014-01-16

C++ Standard Evolution Active Issues List (Revision R05)

C++ Standard Evolution Completed Issues List (Revision R05)

C++ Standard Evolution Closed Issues List (Revision R05)

by Ville Voutilainen

Excerpt:

The purpose of this document is to record the status of issues which have come before the Evolution Working Group (EWG) of the INCITS PL22.16 and ISO WG21 C++ Standards Committee. Issues represent potential defects in the ISO/IEC IS 14882:2003(E) document, and proposed extensions to it.

GotW #95 Solution: Thread Safety and Synchronization -- Herb Sutter

By Blog Staff | Jan 15, 2014 10:26 AM | Tags: intermediate

The solution to the latest GotW problem is now available:

GotW #95 Solution: Thread Safety and Synchronization

by Herb Sutter

From the article:

This GotW was written to answer a set of related frequently asked questions. So here’s a mini-FAQ on "thread safety and synchronization in a nutshell," and the points we’ll cover apply to thread safety and synchronization in pretty much any mainstream language.

ACCU 2014 conference schedule posted (April 8-12)

By Blog Staff | Jan 15, 2014 09:08 AM | Tags: None

Conference chair Jon Jagger has published the conference schedule and session abstracts for ACCU 2014.

ACCU 2014 Conference Schedule

Follow conference news via @accu2014 on Twitter.

Some highlights of this year's schedule include a number of C++ talks. Most of the following speakers are ISO C++ committee members:

Switching to C++11 and C++14 in One Day (Nico Josuttis)

C++14 -- An Overview of the New Standard for C++(11) Programmers (Peter Sommerlad)

There Ain't No Such Thing As a Universal Reference (Jonathan Wakely)

The C++14 Standard Library (Jonathan Wakely)

C++ Dynamic Performance (Aleksandar Fabijanic)

C++ Undefined Behavior -- What Is It, and Why Should I Care? (Marshall Clow)

Large-Scale C++ -- Advanced Levelization Techniques (John Lakos)

C++ Pub Quiz (Olve Maudal)

Creating Safe Multi-Threaded Applications in C++11 (Jos van Eijndhoven)

Random Number Generation in C++ -- Present and Potential Future (Pattabi Raman)

Range and Elevation -- C++ In a Modern World (Steve Love)

Generic Programming with Concepts Lite (Andrew Sutton)

Where Is C++ Headed? (Hubert Matthews)

Complementary Visions: Integrating C++ and Python with Boost.Python (Austin Bingham)

The Continuing Future of C++ Concurrency (Anthony Williams)

Polymorphic Allocators for Fundamental Libraries (Alisdair Meredith)

Executors for C++ (Detlef Vollmann)

Endnote: Everything You Ever Wanted To Know About Move Semantics (and then some) (Howard Hinnant)

Using Regular Expressions with Modern C++ -- Kenny Kerr

By Blog Staff | Jan 14, 2014 08:49 AM | Tags: intermediate

In the current MSDN Magazine:

Using Regular Expressions with Modern C++

by Kenny Kerr

From the article:

C++11 introduced a long list of features that are in themselves quite exciting, but if all you see is a list of isolated features, then you’re missing out. The combination of these features makes C++ into the powerhouse that many have grown to appreciate. I’m going to illustrate this point by showing you how to use regular expressions with modern C++... the combination of C++ language and library features really turns C++ into a productive programming language.

Quick Q: How can I avoid writing ::value and ::type when using std::enable_if? -- StackOverflow

By Blog Staff | Jan 14, 2014 06:54 AM | Tags: None

Quick A: Use a template alias. Several standard ones are coming in C++14.

Recently on SO:

How can I avoid writing ::value and ::type when using std::enable_if? [cppx]

In some of my code, namely the header rfc/cppx/text/String.h, I found the following mysterious snippet:

template< class S, class enable = CPPX_IF_( Is_a_< String, S > ) >
void operator!  ( S const& )
{ string_detail::Meaningless::operation(); }

The operator! is in support of a String class that has an implicit conversion to raw pointer. So I overload (among others) operator! for this class and derived classes, so that inadvertent use of a non-supported operator will give a suitable compilation error, mentioning that it's meaningless and inaccessible. Which I think is much preferable to such usage being silently accepted with an unexpected, incorrect result.

The CPPX_IF_ macro supports Visual C++ 12.0 (2013) and earlier, which finds C++11 using to be mostly beyond its ken. For a more standard-conforming compiler I would have written just ...

template< class S, class enable = If_< Is_a_< String, S > > >
void operator!  ( S const& )
{ string_detail::Meaningless::operation(); }

This looks like std::enable_if,

template< class S, class enabled = typename std::enable_if< Is_a_< String, S >::value, void >::type >
void operator!  ( S const& )
{ string_detail::Meaningless::operation(); }

except that the If_ or CPPX_IF_, and its expression, is much more concise and readable.

How on Earth did I do that?

Type Erasure, Part 4 -- Andrzej Krzemieński

By Blog Staff | Jan 13, 2014 09:40 AM | Tags: intermediate

In part 4, Andrzej wraps up his series on type erasure with a discussion and comparison of facilities in the standard library, Boost, and otherwise.

Type Erasure, Part 4

by Andrzej Krzemieński

From the article:

In this post we will be wrapping up the series on type erasure. We will see an another form of value-semantic type erasure: boost::any, and try to compare the different methods.

Quick Q: Is pass-by-value-and-then-move a bad idiom? -- StackOverflow

By Blog Staff | Jan 13, 2014 01:47 AM | Tags: basics

Quick A: It's a good style by default when you know you'll keep a copy of the parameter anyway. If you have an expensive-to-move type or otherwise want additional control, you can overload on &/&& or else perfect-forward.

Recently on SO:

Is the pass-by-value-and-then-move construct a bad idiom?

Since we have move semantincs in C++, nowadays it is usual to do

void set_a(A a) { _a = std::move(a); }

The reasoning is that if a is an rvalue, the copy will be elided and there will be just one move.

But what happens if a is an lvalue? It seems there will be a copy construction and then a move assignment (assuming A has a proper move assignment operator). Move assignments can be costly if the object has too many member variables.

On the other hand, if we do

void set_a(const A& a) { _a = a; }

There will be just one copy assignment. Can we say this way is preferred over the pass-by-value idiom if we will pass lvalues?

Quick Q: Why prefer making shared_ptrs via make_shared? -- StackOverflow

By Blog Staff | Jan 10, 2014 12:47 PM | Tags: basics

Quick A: Because it's more efficient, since it can eliminate an additional allocation.

Recently on SO:

Difference in make_shared and normal shared_ptr in C++

std::shared_ptr<Object> p1 = std::make_shared<Object>("foo");
std::shared_ptr<Object> p2(new Object("foo"));

Many google and stackoverflow posts are there on this, but I am not able to understand why make_shared is more efficient than directly using shared_ptr. Can someone explain me step by step sequence of objects created and operations done by both so that I will be able to understand how make_shared is efficient. I have given one example above for reference.

Quick Q: Is it possible to have automatically generated destructors in C++? -- StackOverflow

By Blog Staff | Jan 10, 2014 11:37 AM | Tags: basics

Quick A: Yes, and we do!

Recently on SO -- the selected answer is the correct one:

Is it possible to have automatically generated destructors in C++?

It is too big burden to do it by ourselves all the time. Is it so hard for the compiler to generate destructors? Can't it detect what is a "resource" and release it in the destructor?

An overview of smart pointers -- Jens Weller

By Blog Staff | Jan 10, 2014 10:30 AM | Tags: basics

Jens's latest, following up on his pointers post:

An overview on smart pointers

by Jens Weller

From the article:

So, a smart pointer is only needed, when you use new or other means of dynamic memory allocation. In my opinion, you should prefer to allocate variables on the stack, so when refactoring code (to C++11), you should always ask yourself, if this new is needed, or could be replaced with an object on the stack. When you need to use new, you should always use a smart pointer in my opinion. Also some smart pointers offer a custom deleter, which is handy if you have an object that is either not allocated by new and/or needs to be freed by calling a special function.