experimental

The Variant Saga: A happy ending?

Variant is like a union, only it tells you what it currently contains, and it will barf if you try to get something out of it that is does not currently contain. It's the type safe sibling of the union:

variant<double, string> v = 42.;
double d = get<double>(v);

I had proposed a variant many moons ago (N4218). After many discussions it seemed that the committee cannot agree on what the ideal C++ variant would look like. I will resolve this cliffhanger -- but before doing that let me introduce you to some of the key discussion points.

An ideal variant will always contain one of its alternative types. But look at this code snippet:

variant<string, MyClass> v = "ABC";
v = MyClass();

The second line will destroy the old value contained in the variant and construct the new value of a different type. Now suppose that the MyClass construction threw: what will the variant contain? What happens when you call get<1>(v)? What happens when the variant gets destroyed?

We either provide the strong exception guarantee (the variant would still contain the string) -- but this requires double buffering, as for instance boost::variant does. Or we could restrict the alternative types to only those that are nothrow_move_constructible. Or we make this a new state -- "invalid, because the variant has been derailed due to an exception thrown during type changing assignment". Or we say "you shouldn't write code that behaves like this; if you do you're on your own", i.e. undefined behavior. The committee was discussing what to do, and so was The Internet. There are other design decisions -- default construction, visitation etc -- but they are all insignificant compared to how to deal with the throwing, type-changing assignment.

I have tried to present the options and their pros and cons in P0086. In short: it's incredibly difficult and fragile to predict whether a type is_nothrow_move_constructible. And double buffering -- required for a strong exception guarantee -- kills the quest for an efficient variant. But efficiency is one of the main motivations for using a discriminated union.

After the second Library Evolution Working Group (LEWG) review in Lenexa, we got P0088R0: a design that was making this invalid state extremely rare. But if it happened, access to the value would result in undefined behavior. This caused a vivid reaction from the committee members. And from The Internet. Hundreds of emails on the committee email lists. Many many smart and convincing blog posts.

In the end, different parts of the committee strongly supported different designs -- and vetoing other designs. Massive disagreement. So when we came to our C++ Standards Meeting in Kona, it was immediately clear that we needed to expose this to the full committee (and not just LEWG). The expectation was that we would declare variant dead, and keep it locked away for the next five years. At least. (An I would have time to water my fishes again.)

So back to the cliffhanger. On the full committee, Monday evening stage in Kona were David Sankel and I. We presented (and represented) the different design options. While we were discussing with the committee members, live and uncut and on stage, David and I realized that we could make it happen. "The Kona Kompromise": similar to P0088R0, but instead of undefined behavior when extracting the value of such a zombie variant it would just throw!

The Kona Kompromise means that we don't pay any efficiency for the extremely rare case of a throwing move. The interface stays nice and clean. A variant of n alternatives is a "mostly" an n-state type. It offers the basic exception guarantee at no relevant performance loss. It is a safe vocabulary type for every-day use, also for novices. The vast majority of the committee was convinced by this idea. Almost everyone in the room was happy!

Do we have a std::variant now? Not yet. But we are a giant leap closer: variant is now under wording review with the Library Working Group (LWG); I will publish a new revision in the Kona post-mailing (P0088R1). This will get re-reviewed in Jacksonville, first week of March. Once LWG gives the green light, the full committee can vote variant into a Technical Specification (TS) as std::experimental::variant. Now that a large fraction of the committee has expressed its consent (happiness, even!), I expect that this will be in the TS called Library Fundamentals, v3. It might or might not make it into C++17 -- that depends mostly on how quickly I manage to bring P0088 into an acceptable state, and how quickly we will gain use experience with variant.

So there is one thing I'd really appreciate your help with: std::experimental::variant will show up in library implementations near you, likely in their first releases next year. It would be fantastic if you could try it out, and as importantly: give feedback, on the public forums or by contacting me directly ([email protected]). Your feedback will tell us whether the design decisions we took are the right ones, for instance regarding default construction, visitation, performance, and especially converting construction and assignment. As they say here: Mahalo!

Axel Naumann, CERN ([email protected])

 

Announcing Visual C++ Build Tools 2015 – standalone C++ tools for build environments--Marian Luparu

You can now compile using Visual C++ without Visual Studio:

Announcing Visual C++ Build Tools 2015 – standalone C++ tools for build environments

by Marian Luparu

From the article:

Together with the availability of Visual Studio 2015 Update 1 RC, we’re also announcing a new way of acquiring the C++ tools: as a standalone installer that only lays down the tools required to build C++ projects without installing the Visual Studio IDE. This new installer is meant to streamline the delivery of the C++ build tools in your build environments and continuous-integration systems.

Integrating an HTML Editor into Qt using Javascript and QWebView

Part 8 of my series about writing applications in C++ using Qt and boost:

Integrating an HTML Editor into Qt using Javascript and QWebView

by Jens Weller

From the article:

This time its about integrating an HTML Editor into Qt using QWebView and Javascript! I'll start with text editors in general, and then continue to the integration, based on QWebkit and TinyMCE3. The end result is a little bit of hackery, but it is a working solution...

C++ concepts support merged into gcc trunk

An evolution of gcc occured:

C++ concepts support merged into gcc trunk

From the article:

I've been banging on the concepts branch for the past month after Andrew told me it was about ready to merge, fixing bugs and streamlining things there to get familiar with the code while I could still look at it as a whole rather than mixed in with the rest of the compiler. But I think I've reached diminishing returns and so I'm going to go ahead and merge it into the trunk...

CppCon 2014 Costless Software Abstractions for Parallel Architectures--Joel Falcou

Have you registered for CppCon 2015 in September? Don’t delay – Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2014 for you to enjoy. Here is today’s feature:

Costless Software Abstractions for Parallel Architectures

by Joel Falcou

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Performing large, intensive or non-trivial computing on array like data structures is one of the most common task in scientific computing, video game development and other fields. This matter of fact is backed up by the large number of tools, languages and libraries to perform such tasks. If we restrict ourselves to C++ based solutions, more than a dozen such libraries exists from BLAS/LAPACK C++ binding to template meta-programming based Blitz++ or Eigen. If all of these libraries provide good performance or good abstraction, none of them seems to fit the need of so many different user types.

Moreover, as parallel system complexity grows, the need to maintain all those components quickly become unwieldy. This talk explores various software design techniques - like Generative Programming, MetaProgramming and Generic Programming - and their application to the implementation of a parallel computing librariy in such a way that:

- abstraction and expressiveness are maximized - cost over efficiency is minimized

We'll skim over various applications and see how they can benefit from such tools. We will conclude by discussing what lessons were learnt from this kind of implementation and how those lessons can translate into new directions for the language itself.

CppCon 2014 Making Allocators Work, Part II—Alisdair Meredith

Have you registered for CppCon 2015 in September? Don’t delay – Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2014 for you to enjoy. Here is today’s feature:

Making Allocators Work, Part II

by Alisdair Meredith

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Memory is an important property for every object, as whatever resources it manages, it must occupy some memory. THe ability to customize memory allocation is important for every C++ program that cares about performance, debug ability and support.

The original C++ standard supported an allocator parameter for every container, yet this feature was widely derided or ignored, as it was underspecified to the point it could not portably be used. C++11 makes significant changes to the allocator model, that simply its use while making it more powerful.

The Library Fundamentals TS goes further, allowing allocators’ type to be supplied at runtime, rather than compile type, using classic object oriented polymorphism - yet building on the infrastructure laid down in C++11.

This material should be of interest to both library authors and consumers, although clearly there are more details for the implementers to absorb. It also includes an interesting case study in C++11 compile time reflection, as required to implement the new ‘allocator_traits’ facility.

CppCon 2014 Making Allocators Work, Part I--Alisdair Meredith

Have you registered for CppCon 2015 in September? Don’t delay – Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2014 for you to enjoy. Here is today’s feature:

Making Allocators Work, Part I

by Alisdair Meredith

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Memory is an important property for every object, as whatever resources it manages, it must occupy some memory. THe ability to customize memory allocation is important for every C++ program that cares about performance, debug ability and support.

The original C++ standard supported an allocator parameter for every container, yet this feature was widely derided or ignored, as it was underspecified to the point it could not portably be used. C++11 makes significant changes to the allocator model, that simply its use while making it more powerful.

The Library Fundamentals TS goes further, allowing allocators' type to be supplied at runtime, rather than compile type, using classic object oriented polymorphism - yet building on the infrastructure laid down in C++11.

This material should be of interest to both library authors and consumers, although clearly there are more details for the implementers to absorb. It also includes an interesting case study in C++11 compile time reflection, as required to implement the new 'allocator_traits' facility.

CppCon 2014 What the committee did next!--Alisdair Meredith

Have you registered for CppCon 2015 in September? Don’t delay – Early Bird registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2014 for you to enjoy. Here is today’s feature:

What the committee did next!

by Alisdair Meredith

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Now that C++14 is done, what is the standard committee working on next?

After inking 8 years to produce the C++11 standard (arguably 13) there was a feeling we should be able to produce new work faster, more incrementally. With the renewed interest in C++, we have more participation on the committee, and have looked to harness that enthusiasm in new ways. In the last 3 years we have spun up at least a dozen new study groups, and have 8 or mode Technical Specifications in various stages of development that we hope to ship over the next 12-24 months. So what are all these new groups and specifications about? Come to this session and get a vision of where C++ is headed in the immediate and short-term future.

CppCon 2014 Parallelizing the Standard Algorithms Library--Jared Hoberock

Have you registered for CppCon 2015 in September? Don’t delay – Early Bird registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2014 for you to enjoy. Here is today’s feature:

Parallelizing the Standard Algorithms Library

by Jared Hoberock

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Until recently, C++ programmers building parallel programs found little support for parallelism in the standard toolbox. That's changing with the technical specification on Extensions for Parallelism in C++. This talk will explore how programmers can build portable parallel programs from high-level parallel algorithms which can execute on CPU threads, vector units, and even GPUs.

Folding Expressions -- Marco Alesiani

A new blog post containing runnable code from the Italian C++ Community:

Folding Expressions

by Marco Alesiani

From the article:

C++17, scheduled by 2017 at the time of writing, will introduce fold expressions into play and significantly broaden parameter packs scopes of use [...]

template<typename F, typename... T>
void for_each(F fun, T&&... args)
{
    (fun (std::forward<T>(args)), ...);
}

The sample above uses fold expressions together with the comma operator to create a simple function that calls the provided lambda per each one of the supplied arguments with perfect forwarding. [...]