October 2015

Bjarne Stroustrup on the 30th anniversary of Cfront (the first C++ compiler) -- A. Regat-Barrel

cpp30.PNGHow time flies -- 30 years ago today, the Cfront 1.0 compiler and the first edition of The C++ Programming Language were officially released. In celebration of the event, here's a new interview with Bjarne Stroustrup.

Bjarne Stroustrup on the 30th anniversary of Cfront (the first C++ compiler)

by Aurélien Regat-Barrel

Candidate for favorite quote: "I did learn a fair bit about C++ by trying to explain it to people." Experienced instructors will all tell you the same thing -- you really grok something after you've taught it to others. Thanks for 30+ years of teaching, Dr. Stroustrup!

30 Years of C++ -- Aurélien Regat-Barrel

Aurélien Regat-Barrel interviewed Bjarne Stroustrup about the first release of CFront (the first C++ compiler), exactly 30 years ago.

30 Years of C++

by Aurélien Regat-Barrel

From the article:

Aurélien Regat-Barrel gives an overview of the evolution of the language and talks with Bjarne Stroustrup about the first publication of "C++ The Programming Language", how he experienced the evolution of the language and they close the interview with an outlook of what is coming in the future.

 

Overload 129 is now available

ACCU’s Overload journal of October 2015 is out. It contains the following C++ related articles.

Overload 129 / PDF

From the journal:

Description : Concepts in C++11 had many false starts. Andrew Sutton show why they are a big deal now they are with us. by Andrew Sutton

Description : Concepts are abstract. Jonathan Coe and Andrew Sutton provide us with a concrete example of their use. by Jonathan Coe

 

 

Improving performance and maintainability through refactoring in C++11 -- Garcia, Stroustrup

garcia-stroustrup.PNGIn the "writing better code" department:

Improving performance and maintainability through refactoring in C++11

by J. Daniel Garcia and Bjarne Stroustrup

Abstract:

Abstraction based programming has been traditionally seen as an approach that improves software quality at the cost of losing performance. In this paper, we explore the cost of abstraction by transforming the PARSEC benchmark fluidanimate application from low-level, hand-optimized C to a higher-level and more general C++ version that is a more direct representation of the algorithms. We eliminate global variables and constants, use vectors of a user-defined particle type rather than vectors of built-in types, and separate the concurrency model from the application model. The result is a C++ program that is smaller, less complex, and measurably faster than the original. The benchmark was chosen to be representative of many applications and our transformations are systematic and based on principles. Consequently, our techniques can be used to improve the performance, flexibility, and maintainability of a large class of programs. The handling of concurrency issues has been collected into a small new library, YAPL.

CppCast Episode 29: Expression Templates with Joel Falcou

Episode 29 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Joel Falcou to discuss Expression Templates.

CppCast Episode 29: Expression Templates with Joel Falcou

by Rob Irving and Jason Turner

About the interviewee:

Joel Falcou is an assistant professor in France where he works on torturing compilers to get the best performance out of modern hardware. He's an active member of the Boost community and CTO of NumScale, a start-up aligned with parallel processing tools.

Bitesize Modern C++ : std::array--Glennan Carnie

Some details about arrays in C++:

Bitesize Modern C++ : std::array

by Glennan Carnie

From the article:

C++98 inherited C’s only built-in container, the array. Arrays of non-class types behave in exactly the same way as they do in C. For class types, when an array is constructed the default constructor is called on each element in the array...

ACCU 2016 Call for Papers

ACCU 2016 is now putting together its program, and they want you to speak on C++. ACCU has long had a strong C++ track, though it is not a C++-only conference. If you have something to share, check out the call for papers.

Call for Papers

ACCU 2016

From the article:

We invite you to propose a session for this leading software development conference.

The Call for Papers lasts 5 weeks and will close at midnight Friday 2015-11-13. Be finished by Friday the 13th...

 

 

 

A brief introduction to C++’s model for type- and resource-safety -- Stroustrup, Sutter, Dos Reis

A new paper has been posted to the CppCoreGuidelines /docs folder:

A brief introduction to C++’s model for type- and resource-safety 

by Bjarne Stroustrup, Herb Sutter, and Gabriel Dos Reis

The goal of the paper is to provide a readable high-level overview of C++'s existing resource handling model and the extension of that for type safety that was announced at CppCon. A more detailed treatment of lifetime safety (avoiding leaks and dangling) can be found in Herb Sutter's CppCon talk (YouTube) (Channel 9) and Lifetime paper.

From the paper:

Abstract

You can write C++ programs that are statically type safe and have no resource leaks. You can do that without loss of performance and without limiting C++’s expressive power. This model for type- and resource-safe C++ has been implemented using a combination of ISO standard C++ language facilities, static analysis, and a tiny support library (written in ISO standard C++). This supports the general thesis that garbage collection is neither necessary nor sufficient for quality software. This paper describes the techniques used to eliminate dangling pointers and to ensure resource safety. Other aspects – also necessary for safe and effective use of C++ – have conventional solutions so they are mentioned only briefly here.

The techniques and facilities presented are supported by the Core C++ Guidelines [Stroustrup,2015] and enforced by a static analysis tool for those [Sutter,2015].

AllocatorAwareContainer: Introduction and pitfalls...--Jonathan Müller

An interesting article about some dangerous allocators:

AllocatorAwareContainer: Introduction and pitfalls of propagate_on_container_XXX defaults

by Jonathan Müller

From the article:

While I was writing the std_allocator adapter of foonathan/memory I've learned some not so well-known facts about the STL Allocator and AllocatorAwareContainer concepts I'd like to share. Let's take a deep breath and dive in into an aspect of the STL containers that isn't that well covered: Allocator storage.

I will explain the comparison properties of Allocators, show the C++11 propagate_on_container_XXX traits and how the combination of the two can lead to an unnecessary pessimization and a probably not widely known case of undefined behavior...