Home » Blog » Categories »

N3873: Improved insertion interface for unique-key maps -- Thomas Köppe

By Blog Staff | Jan 17, 2014 09:19 AM | 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 number: N3873

Date: 2014-01-20

Improved insertion interface for unique-key maps

by Thomas Köppe

Excerpt:

The existing interface of unique-keyed map containers (std::map, std::unordered_map) is slightly underspecified, which makes certain container mutations more complicated to write than necessary. This proposal is to add new specialized algorithms:

  • emplace_stable(): if the key already exists, does not insert and does not modify the arguments.
  • emplace_or_update(): inserts or updates the mapped element if the key already exists.

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

accu-2014.PNG

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

dn519920.kenny_kerr_headshot(en-us,MSDN.10).jpgIn 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.