Home » Blog » Categories »

Breaking Changes in Visual C++

By Marco Arena | May 5, 2015 02:01 PM | Tags: None

From the Visual C++ Porting and Upgrading Guide (referring to Visual Studio 2015 RC):

Breaking Changes in Visual C++

by Microsoft

From the article:

When you upgrade to a new version of the Visual C++ compiler, you might encounter compilation and/or runtime errors in code that previously compiled and ran correctly...

C++ Today: The Beast Is Back -- Jon Kalb and Gašper Ažman

By Blog Staff | May 5, 2015 06:59 AM | Tags: None

A new O'Reilly book from two well-known C++ community experts, freely available courtesy of the makers of CLion:

C++ Today: The Beast Is Back

by Jon Kalb and Gašper Ažman

From the announcement:

Now that software development is shifting primarily toward mobile and cloud computing, the venerable C++ programming language is returning to the dominant position it held during the object-oriented boom of the 1990s. In this O′Reilly report, you′ll learn why C++ is once again the preferred choice across several diverse industries...

Table of contents:

Preface

1. The Nature of the Beast

C++: What’s It Good For?
 

2. The Origin Story

C: Portable Assembler
C with High-Level Abstractions
The ’90s: The OOP Boom, and a Beast Is Born
The 2000s: Java, the Web, and the Beast Nods Off
 

3. The Beast Wakes

Technology Evolution: Performance Still Matters
Language Evolution: Modernizing C++
Tools Evolution: The Clang Toolkit
Library Evolution: The Open Source Advantage
 

4. The Beast Roars Back

WG21
Tools
Standard C++ Foundation
Boost: A Library and Organization
Q&A
Conferences and Groups
Videos
CppCast
Books
 

5. Digging Deep on Modern C++

Type Inference: Auto and Decltype
How Move Semantics Support Value-Semantic and Functional Programming
No More Output Parameters
Inner Functions with Lambdas
Lambdas as a Scope with a Return Value
 

6. The Future of C++

Setting the Standard
Never Make Predictions, Especially About the Future
 

Bibliography

Announcing a financial assistance policy for ISO C++ meetings

By Herb Sutter | May 4, 2015 08:06 PM | Tags: None

Most of the following announcement will not immediately affect those who are not C++ standards committee members, but I hope everyone reading this blog who uses and relies on C++ will benefit from this new program.

 

I’m pleased to share that today at the ISO C++ meeting in Lenexa, Kansas, USA, the Standard C++ Foundation launched a new financial assistance policy intended to facilitate the work of WG21. You can find the policy here.

Thank you!

Before I mention details, let me thank two important groups without whose support this would not be possible:

  • Thank you to the members of the Standard C++ Foundation whose logos you see at right. Their financial investment in the Foundation has provided the core funding to support the Foundation’s work since its creation in November 2012.
  • Thank you to you, if you’re one of the hundreds who attended CppCon last September and/or one of the scores of volunteers who organized CppCon as a community C++ festival. The primary goal of CppCon was to deliver important information to the community, and so we kept ticket prices low to encourage attendance, we invested in recording all sessions to make them freely available to everyone... and thanks to the strong attendance response and all the volunteering help we got, we still managed to run at a modest profit that we can use both to run CppCon again (registration opens soon, watch this space!) and to invest back into the C++ community including through this new policy.

Overview

Remember that the Foundation is not the committee, even though many people and companies participate in both. Rather, the Foundation exists to support the community and the work of the committee while leaving standardization strictly under the C++ committee leadership’s direction. For that reason, this policy leaves it up to the C++ committee leadership as to how the financial support should best be applied. Also, please note that this policy is experimental and subject to revision or withdrawal, but we hope it will be successful in facilitating the work of the committee as we develop the TSes, C++17, and beyond.

The basic idea is that the Foundation will set aside a chunk of money for each meeting, that the convener and main subgroup chairs can draw on to facilitate WG21 work, notably in three areas:

  1. Meeting hosting, when not enough financial support is available.
  2. Travel to a meeting, for authors of important proposals who are not employed by a company and not able to fund it on their own.
  3. Further development of proposals, again when the authors are not employed by a company and not able to self-fund the work fully.

Note that both #2 and #3 are intended to directly help and foster community involvement beyond the big commercial corporations and academic/research institutions.

Recall: For much of the history of the C++ committee, we have had key participants who have made an enormous difference to C++ who have not been funded by a company, university, research lab, or other organization. Today, that hasn't changed: We continue to have some of our major proposals, including at least three large proposed libraries including Ranges (range-based STL using concepts), Networking (based on Boost.ASIO), and 2D Graphics (based on Cairo), that rely partly or entirely on the efforts of such individual world-class experts, and that have been developed to their current state by those experts’ unpaid volunteer efforts.

The committee has expressed strong interest in pursuing all of the three proposals I've just named, as well as others. However, nothing gets done unless someone can contribute sustained heavy work -- and because these key efforts are not funded by companies, some of these efforts likely cannot continue, and cannot be completed, without at least some assistance of the financial variety. We hope that the Foundation can help by starting to offer tactical travel assistance and grant funding for some of the costs of some of these kinds of contributors, so that we can help foster the work that the committee has declared an interest in, but that cannot progress without requiring some level of actual financial development assistance that would not happen if we relied on companies and other institutions alone.

Why a policy?

Since the last November’s standards meeting in particular, the Foundation directors have been working on putting together this policy because the Foundation had already become involved in supporting all three of these categories of standards-related work, but it has been in ad-hoc and on-demand ways as situations have arisen.

For example, even before there was a policy, the Foundation funded work from which the standardization effort is already benefiting at this week's meeting: Without the first grant issued as an initial one-off grant over the winter even before this regular policy became official, we would not now have a 170-page document before us containing near-complete working draft text for applying concepts and ranges to the entire STL iterators and algorithms libraries, along with an open source reference implementation on GitHub – and we do have that and are considering it at this week’s standards meeting.

Since this has worked very well in the form of ad-hoc one-off support, the Foundation directors decided it was time to establish a structure to formalize and regularize this support, and test how well it works more broadly.

So now that we have a policy, what’s different? The answer is, not too much -- the Foundation still wants to support those same things, and this policy mainly gives a regular and consistent structure for doing that. One major difference is that going forward it will be, not just the Foundation’s CEO and directors, but the committee leadership -- the convener and the four main subgroup chairs -- who will decide and approve where the support should be allocated. The Foundation directors will set a budget of what we can contribute toward each meeting, and the committee leadership will decide how they want to use it to promote the work of that meeting. (Note that there is overlap between the Foundation directors and the WG21 leadership, and some of us wear two hats, but the policy is written to distinguish those roles and designed for the long term as the people in particular roles evolve over time.)

Again, this is experimental and subject to review based on how it goes. As we try this out together with the committee subgroup chairs between now and our next meeting in October, we’ll get a better feel together for how it will all work in practice.

Finally, thank you again

Thank you again to the Standard C++ Foundation members at right who directly financially support the work of the Foundation including this initiative.

Thank you again to the CppCon attendees, and to the CppCon volunteers who contribute so much to the running of that conference to disseminate information and support the C++ community, because your support for CppCon feeds back into enabling things like this initiative.

Thank you again to the C++ committee members and leadership who work hard year after year to bring us modern Standard C++ at high quality.

Thank you all, dear readers, for all you do for Standard C++. The Foundation is glad to be able to try to provide some financial support for the good work of C++ standardization in key areas to promote the development of our Technical Specifications, C++17, and beyond, and we look forward with intense interest to see what future results these and other efforts may bring.

Herb

The Annihilation of Conceptual Integrity by Tony DaSilva

By Blog Staff | May 4, 2015 12:00 PM | Tags: None

A commentary on the C++17 directions being discussed today at the ISO C++ meeting in Kansas, USA:

The Annihilation of Conceptual Integrity

by Tony DaSilva

From the article:

When a large group or committee is tasked with designing a complex system from scratch, or evolving an existing one, I always think of these timeless quotes from Fred Brooks: ... “Who advocates ... for the product itself -- its conceptual integrity, its efficiency, its economy, its robustness? Often, no one.” – Fred Brooks

... Like all the other C++ committee members, Bjarne is a really, really, smart guy. For the decades that I’ve followed his efforts to evolve and improve the language, Bjarne has always expressed empathy for "the little people"; the 99% (of which I am a card-carrying member).
In a world in which the top 1% doesn’t seem to [care] about the remaining 99%, it’s always refreshing to encounter a 1 percenter who cares deeply about the other 99 percenters. And THAT, my dear reader, is what has always endeared Mr. Bjarne Stroustrup to me....

Binary literals and digit separators--Marius Bancila

By Adrien Hamelin | May 4, 2015 08:02 AM | Tags: c++14 basics

The title says it all:

Binary literals and digit separators

by Marius Bancila

From the article:

The C++14 standard provides two new small features to the language: binary literals and digit separators. They are already available in Clang 3.4 and GCC 4.9 and now Visual Studio 2015 RC has implemented them. They may not be something you can’t leave without, but sometimes it’s convenient to have them. Let’s have a look...

5 awesome C++ libraries we use--Edouard

By Adrien Hamelin | May 4, 2015 08:00 AM | Tags: intermediate community

An interesting post on interesting librairies:

5 awesome C++ libraries we use

by Edouard

From the article:

This is an opinionated post about five libraries we use in the production code of quasardb.

We of course use many more great libraries (for example Boost.ASIO which is not listed here). Maybe those five libraries are not the most important, but I felt they deserved some special highlight as they are not so well-known or understood...

CppCon 2014 Lock-Free Programming (or, Juggling Razor Blades), Part II--Herb Sutter

By Adrien Hamelin | May 4, 2015 07:59 AM | Tags: performance efficiency

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Lock-Free Programming (or, Juggling Razor Blades), Part II

by Herb Sutter

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Example-driven talk on how to design and write lock-free algorithms and data structures using C++ atomic -- something that can look deceptively simple, but contains very deep topics. (Important note: This is not the same as my "atomic Weapons" talk; that talk was about the "what they are and why" of the C++ memory model and atomics, and did not cover how to actually use atomics to implement highly concurrent algorithms and data structures.)

C++ User Group Meetings in May

By Meeting C++ | May 4, 2015 03:54 AM | Tags: community

The monthly overview on the current user group meetings:

C++ User Group Meetings in May

by Jens Weller

From the article:

    6.5 C++ UG Saint Louis - DD Part 5 - "Atomic" weapons OR ??
    6.5 C++ UG Munich - What is new in VS2015 for C++ Developers
    6.5 C++ UG Saint Louis - "Atomic weapons" part II
    6.5 C++ UG Austin - Charming Python with C++
    7.5 C++ UG NRW/Aachen - C++ User Gruppe (Mai)
    7.5 C++ UG Dresden - Coding Dojo
    11.5 C++ UG Zentralschweiz - Compile-time computation in C++14" mit Prof. Peter Sommerlad
    13.5 C++ UG Utah - Test-Driven Development in C++
    13.5 C++ UG San Francisco/ Bay area - Presentation and Q&A
    15.5 C++ UG Taipei - monthly meetup
    16.5 C++ UG Pune, India - Mastering C++14
    18.5 C++ UG Austin - North Austin Monthly C/C++ Pub Social
    20.5 C++ UG Düsseldorf - Cooking with C++
    20.5 C++ UG Arhus - Kickoff Meeting
    20.5 C++ UG Northwest/Seattle - STL Concepts and Ranges
    21.5 C++ UG Bristol - Lightning Talks
    27.5 C++ UG San Francisco/ Bay area - Workshop and Discussion Group
    27.5 C++ UG Hamburg - C++ Expression Templates
    27.5 C++ UG Udine (Italy)
    28.5 C++ UG Rhein-Neckar - (C++) build system olympics.

N4494: Multidimensional bounds, offset and array_view, rev. 6 -- Łukasz Mendakiewicz, Herb Sutter

By Blog Staff | May 2, 2015 03:50 PM | Tags: None

New WG21 papers are available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4494

Date: 2015-05-01

Multidimensional bounds, offset and array_view, revision 6

by Łukasz Mendakiewicz and Herb Sutter

Excerpt:

Revision 6 (N4494) incorporates the changes requested by LWG in Cologne meeting, marked as deletions and insertions.

The following suggestions were implemented fully:

  1. Rephrased coord.general avoid references to mathematical entites.
  2. Renamed index to offset.
  3. Changed int Rank template parameter to size_t Rank throughout the document.
  4. Made offset, bounds and bounds_iterator binary operators (apart from @= forms) free functions.
  5. Replaced term "component" with "element" when referring to the individual constituents of offset or bounds.
  6. In coord.bounds.require replaced prose with an equivalent mathematical expression.
  7. In coord.bounds.iterator and coord.bounds.iterator.require removed the requirement on bounds_iterator to represent a random access iterator, replacing with "as-if" phrasing.
  8. In the description of bounds_iterator& operator++() replaced the code snippet with equivalent prose.
  9. In views.general changed the font back to non-monospace.
  10. Removed views.require, duplicating it as arrayview.require and stridedarrayview.require.
  11. Removed redundant assignment operators on array_view and strided_array_view.
  12. Employed "exposition only" data members is the descriptions of array_view and strided_array_view semantics.
  13. Rephrased the first paragraph in arrayview.cons to avoid ambiguity in binding of the token "type".
  14. In constexpr array_view(Viewable&& vw) rephrased the third bullet point.
The following suggestion was implemented partially:
  1. Instead of the array_view(ArrayType& arr) constructor being completely removed, it has been constrained to 1-D case as the Committee indicated that such case does not exhibit the undefined behavior. We believe that the request to remove it completely was a misstatment.

The following suggestion was not implemented:

  1. The semantics of the proposed types were not extended to allow rank-0 cases. We feel that we lack sufficient practical experience in using such cases and we are afraid of some contention points when it comes to defining their detailed semantics. We observe that such an extension can be introduced in future without conflicting with the proposal in the current form.