CppCon 2016: Implementing `static` control flow in C++14--Vittorio Romeo

Have you registered for CppCon 2017 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 2016 for you to enjoy. Here is today’s feature:

Implementing `static` control flow in C++14

by Vittorio Romeo

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

There has always been great interest in imperative compile-time control flow: as an example, consider all the existing `static_if` proposals and the recently accepted `constexpr_if` construct for C++17.

What if you were told that it is actually possible to implement imperative control flow in C++14?

In this tutorial, the implementation and design of a compile-time `static_if` branching construct and of a compile-time `static_for` iteration construct will be shown and analyzed. These constructs will then be compared to traditional solutions and upcoming C++17 features, examining advantages and drawbacks.

Italian C++ Conference 2017: Videos published--Marco Arena

I am very happy to announce we published all the videos of the Italian C++ Conference 2017:

C++ executors to enable heterogeneous computing in tomorrow's C++ today (Michael Wong)

Quicker Sorting (Dietmar Kühl)

Boost vs Qt: What Could They Learn From Each Other? (Jens Weller)

Monads for C++ (Bartosz Milewski)

Functional C++ for Fun and Profit (Phil Nash)

 

The second track is in Italian:

An overly simple C++ idiomatic pattern language for message-based product families (Carlo Pescio)

Lambda out: a simple pattern for generic output (Davide Di Gennaro)

Diversity and Inclusion in Microsoft (Paola Presutto)

Costruire un bridge C++ tra NodeJS e C# (Raffaele Rialdi)

Una libreria di rete asincrona scritta in C++ ispirata a Node.js (Stefano Cristiano)

 

The Italian C++ Conference 2017 videos are powered by Bloomberg.

CppCon 2016: Examining applications that do not terminate on std::bad_alloc--Sergey Zubkov

Have you registered for CppCon 2017 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 2016 for you to enjoy. Here is today’s feature:

Examining applications that do not terminate on std::bad_alloc

by Sergey Zubkov

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

System memory holds a special place in the hierarchy of program resources; its availability is the implied precondition for many innocuous lines of code, from std::string::substr() to passing std::function<> by value. The ability to always create another object is ingrained in the OOP mindset so much that it is often said that immediate termination is the cleanest way to handle memory allocation failures in most situations. Nevertheless, C++, when consistently applying RAII, makes it possible to treat memory allocation exactly as any other resource acquisition.

To what degree do actual applications take advantage of that possibility and what responses to allocation failures are there in the wild? This presentation will examine over 300 open source projects that incorporate explicit handling for std::bad_alloc, examine the causes (it’s not always “out of memory”), response strategies (it’s more than just rollback), and related practical considerations.

(Not Really So) New Niche for C++: Browser!? -- No Bugs Hare

In this article "No Bugs" Hare outlines the possibility to run C++ code in the major four web browsers.

(Not Really So) New Niche for C++: Browser!?

by "No Bugs" Hare

From the article:

For quite a long while, C++ had been losing popularity; for example, as reported in [Widman16], in 2016 it got 7% less of the listings on Dice.com compared with a year earlier; and according to [TIOBE17], from the C++ Golden Age in 2004 till 2017, the C++ share fell from ~17% to a measly 6%.

As all of us (as in, ‘hardcore C++ fans’) know , this has nothing to do with the deficiencies of C++; rather it is related to an observation that the time of downloadable clients (which was one of the main C++ strongholds) has changed into the time of browser-based clients – and all the attempts to get C++ onto browsers were sooo ugly (ActiveX, anyone?) that this didn’t really leave a chance to use C++ there.

Well, it seems that this tendency is already in the process of being reverted:

C++ can already run on all four major browsers – and moreover, it has several all-important advantages over JavaScript, too.
And this – not too surprisingly – is what this article is all about.

Trip report: Evolution Working Group at the Summer ISO C++ standards meeting Toronto--Andrew Pardoe

The evolution does not stop.

Trip report: Evolution Working Group at the Summer ISO C++ standards meeting (Toronto)

by Andrew Pardoe

From the article:

The Summer 2017 ISO C++ standards meeting was held in July 10-15 at the University of Toronto. Many thanks to Google, Codeplay, and IBM for sponsoring the event, as well to folks from Mozilla, Collège Lionel-Groulx, Christie Digital Systems, and Apple for helping to organize. And, of course, we very much appreciate Waterfront International for sponsoring a banquet at the CN Tower.

C++17: Structured Bindings--Marc Gregoire

It is coming!

C++17: Structured Bindings

by Marc Gregoire

From the article:

This is a first post in a series of short articles on new C++17 features. These articles will not contain all little details of the new features being presented, but they give you an idea about what new functionality has been added to C++17.

CppCon 2016: Iterator Haiku--Casey Carter

Have you registered for CppCon 2017 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 2016 for you to enjoy. Here is today’s feature:

Iterator Haiku

by Casey Carter

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Iterator Haiku: How five iterator categories blossomed into seven, and Sentinels trimmed them back to five again. Recently proposed changes to the ranges TS distill its seven iterator categories back to five without sacrificing any expressive power. Removing operations that are extraneous in the Sentinel world eliminates a potential source of programming errors.

What should the ISO C++ Standards Committee be doing?

What should the ISO C++ Standards Committee be doing?


Bjarne Stroustrup


There is a lot of talk within the committee and outside about how to chose what to work on, what processes will work best for handling proposals, and how to maintain a direction for the language.

In January, a group of heads of national delegations submitted a document entitled Operating principles for evolving C++ and the committee constituted a small group of experienced members to try to develop and maintain direction of the standards effort.

In June, Titus Winters and the members of the direction group submitted a follow-up document: C++ Stability, Velocity, and Deployment starting the process of making the principles real. This document was presented at the Toronto meeting to about 80 members in an evening session. It was very well received.

We are working to make the suggestions from those papers concrete to improve the standards process, and eventually help improve C++ and its ISO standard. Here, I would like to direct attention to one part of that document:

Proposal – “Our Promise To Users” a.k.a

“The C++ Programmers’ Bill of Rights.”

We, the ISO C++ Standards Committee, promise to the best of our ability to deliver the
following, assuming user code adheres to the current standard:

  1. Compile-time stability: Every change in behavior in a new version of the standard is detectable by a compiler for the previous version.
  2. Link-time stability: ABI breakage is avoided except in very rare cases, which will be welldocumented and supported by a written rationale.
  3. Compiler performance stability: Changes will not imply significant added compile-time costs for existing code.
  4. Run-time Performance stability: Changes will not imply added run-time costs to existing code.
  5. Progress: Every revision of the standard will offer improved support for some significant programming activity or community.
  6. Simplicity: Every revision of the standard will offer some simplification of some significant programming activity.
  7. Timeliness: The next revision of the standard will be shipped on time according to a published schedule.

Note “to the best of our abilities”. These are guiding principles, rather than executable statements. For example, if I add a function to a header file, the compilation of code that includes that header will slow down imperceptibly. That’s understood and could be argued not to be “existing code” because of the change. Adding enormous amounts of code to a header so that compilation slowed down noticeably
would be another matter.

These are ideals. They are what we would like to see done. I we succeed, most users will be very happy. However, they are not a recipe we could blindly follow to deliver a new standard. As is typical for ideals, they can conflict: there are tensions among the desired goals. This is common: Ideally, we want quality, on-time delivery, and low cost of products, but we know from vast experience that it is very hard to get all three. We want freedom of speech and absence of verbal intimidation, but balancing those two can be very hard. It is the same for the ideals of the “The C++ Bill of Rights”; we want all, but the committee will have to make hard choices.

These are ideals. They are meant to be rather grand statements, rather than nit-picked long sentences with every statement watered down by adjectives and caveats. It will be up to the committee members to interpret the ideals for real design and scheduling problems.

There are just 7 ideals listed and they are quite general. We could add many more, but a laundry list of specifics, would dull the appeal and be impossible to remember in the heat of discussions about direction, what can be delivered when, and specific technical concerns.

So, what do you think? Should the committee formally commit to this? Can it be improved? How? Obviously, we need a discussion within the committee and in the community in general before deciding on anything.