CppCon 2017: C++ as a "Live at Head" Language--Titus Winters

New video of Cppcon!

C++ as a "Live at Head" Language

by Titus Winters

From the article:

Engineering is programming integrated over time. That is to say, as much as it can be difficult to get your code to build and run correctly, it is manifestly harder to keep it working in the face of changing assumptions and requirements. This is true no matter the scale, from a small program to a shared library. Only two solutions have been shown to be theoretically sound: never change or provide no compatibility guarantees. What if there were a third option? What if we took the question of maintenance out of the realm of theory and moved it to practice? This talk discusses the approach we've used at Google and how that intersects with other languages, package management, API and ABI compatibility, and a host of other software engineering practices. The particulars of C++ as a language and an ecosystem make it well positioned for a different approach: Live at Head.

#CPPCON2017. Day 2. Why Local Allocators are a Good ...--"No Bugs" Hare

The conference continues!

#CPPCON2017. Day 2. Why Local Allocators are a Good Thing(tm) Performance-Wise, and Why I am Very Cautious about C++17 STL parallelized algos

by "No Bugs" Hare

From the article:

At CPPCON2017 Day 2, two talks were of special interest to me. One was a 2-hour talk about Local Allocators – and another about C++17 STL parallelised algorithms.

CppCon 2017: Learning and Teaching Modern C++--Bjarne Stroustrup

Cppcon 2017 opening keynote by Bjarne Stroustrup is now live.

Learning and Teaching Modern C++

by Bjarne Stroustrup

From the article:

We – attendees at CppCon – are all teachers. Some teach for a living; many occasionally teach a course or give a lecture; essentially all give advice about how to learn C++ or how to use C++. The communities we address are incredibly diverse.

What do we teach, and why? Who do we teach, and how? What is “modern C++”? How do we avoid pushing our own mistakes onto innocent learners?

Teaching C++ implies a view of what C++ is; there is no value-neutral teaching. What teaching tools and support do we need? Consider libraries, compiler support, and tools for learners. This talk asks a lot of questions and offers a few answers. Its aim is to start a discussion, so the Q&A will be relatively long.

Introducing Abseil, a new common libraries project--Titus Winters

A new library is out!

Introducing Abseil, a new common libraries project

by Titus Winters

From the article:

Today we are open sourcing Abseil, a collection of libraries drawn from the most fundamental pieces of Google’s internal codebase. These libraries are the nuts-and-bolts that underpin almost everything that Google runs. Bits and pieces of these APIs are embedded in most of our open source projects, and now we have brought them together into one comprehensive project. Abseil encompasses the most basic building blocks of Google’s codebase: code that is production tested and will be fully maintained for years to come.

Bjarne Stroustrup awarded 2017 Faraday Medal

The Faraday Medal is awarded for conspicuous service rendered to the advancement of science, engineering and technology:

Bjarne Stroustrup awarded 2017 Faraday Medal

by Institution of Engineering and Technology

From the article:

“I am honored and humbled to see my name among so many illustrious previous winners of the prize,” said Stroustrup. “This privilege is only possible through the superb work of the C++ community.”

Static libs do not modular make -- Thomas Young

An article about static libraries, the benefits (or non-benefits) of splitting your project into static libraries, and the knock-on effects this can have on project dependencies.

Static libs do not modular make

by Thomas Young

From the article:

A cautionary tale about statically-linked libraries, as generated by C/C++ build tools.

As a project accumulates features, and complexity, it gets harder to understand exactly what's going on, and to find your way around the source code. You need to find some way to organise the code and try and keep things manageable.

A common idea, in this situation, is to group some source files together to split out as a static library.

I'm going to argue that this actually does very little, in itself, to increase modularity, can have the effect of significantly increasing dependencies, and is maybe not such a good idea, after all.