Topics

Featured in Development

Alex Bradbury gives an overview of the status and development of RISC-V as it relates to modern operating systems, highlighting major research strands, controversies, and opportunities to get involved.

Featured in Architecture & Design

Will Jones talks about how Habito, the leading digital mortgage broker, benefited from using Haskell, some of the wins and trade-offs that have brought it to where it is today and where it's going next. He also talks about why functional programming is beneficial for large projects, and how it helps especially with migrating the data store.

Featured in AI, ML & Data Engineering

Katharine Jarmul discusses research related to fair-and-private ML algorithms and privacy-preserving models, showing that caring about privacy can help ensure a better model overall and support ethics.

Featured in Culture & Methods

This personal experience report shows that political in-house games and bad corporate culture are not only annoying and a waste of time, but also harm a lot of initiatives for improvement. Whenever we become aware of the blame game, we should address it! DevOps wants to deliver high quality. The willingness to make things better - products, processes, collaboration, and more - is vital.

Featured in DevOps

Service mesh architectures enable a control and observability loop. At the moment, service mesh implementations vary in regard to API and technology, and this shows no signs of slowing down. Building on top of volatile APIs can be hazardous. Here we suggest to use a simplified, workflow-friendly API to shield organization platform code from specific service-mesh implementation details.

C++ Core Guidelines will Help Writing Good Modern C++

As announced at CppCon, Bjarne Stroustrup and Herb Sutter have started working on a set of guidelines for modern C++. The goal of this effort is improving how developers use the language and help ensuring they write code that is type safe, has no resource leaks, and is as much as possible free of programming logic errors.

Our core C++ guidelines makes such code simpler to write than older styles of C++ and the safety can be validated by tools that should soon be available as open source.

The guidelines are available on GitHub and have received contributions from experts at CERN, Microsoft, and other organizations, according to the two main authors. The document, although namely still at version “0.6”, is already pretty large, counting more than 200 pages when printed. It is made of several sections, each focusing on individual language features — such as interfaces, classes, expressions, etc. —, or techniques — such as resource management, generic programming, concurrency, etc. The guideline contains a rather varies set of recommendations, going from basic suggestions such as “Give a class a default constructor” (C.43), and “Avoid magic constants” (ES.45), to more advanced ones, such as “Use a T&& parameter together with move for rare optimization opportunities” (F.25). Each rule comes with a short discussion and code samples showing how it is correctly implemented.

The document also contains a section dedicated to a new “Guideline Support Library” (GSL) that has been developed to make it easier to apply the guidelines and provides a set of common types such as array_view, which can represent ranges, and not_null, which can be used to express the constraint that null is not a valid value for a pointer type. An initial portable implementation of GSL has been contributed by Microsoft.

One interesting aspects of the C++ Core Guidelines is the related effort of building a checker tool able to enforce them. Again, an initial implementation has been contributed by Microsoft and should be made available in binary form next October. In a CppCon session, Microsoft Principal Software Engineer Neil MacIntosh provided more details on such tool, claiming that modern static analysis can go well beyond lint and “find subtle, complex bugs early, identify opportunities to improve performance, encourage consistent style and appropriate usage of libraries and APIs”.

InfoQ has reached out to Bjarne Stroustrup to ask him about the new guidelines.

How would you see the newly announced C++ Core Guidelines as the base for the definition of a restricted set of C++, an often recurring idea in discussion forums, which only contains “safe” or “easy to use” language features? Do you think it could be a first step in that direction?

We have no wish to make a subset language. That would fail. One reason is that the billions of lines of C++ code using older features will not go away any day soon. Another, fundamental, reason is that we need the dangerous/unsafe/low-level/error-prone features to implement the higher-level/safe/easy-to-use features. We must not damage C++’s ability to deal directly with hardware.

The GitHub document, in its current form, runs at more than 200 pages when printed. How would you address the criticism that it is in itself testament to C++ unavoidable complexity?

Any comprehensive list of rules for any language would be hundreds of pages. There will be many more rules and many more pages before we are finished. Had we wanted to be this comprehensive for C or Java we would probably have needed more rules. We are not just concerned with safety. We want to help developers adopt techniques that speed up development, deliver good performance, ease maintenance, use of libraries, etc. Not every programmer will need every rule, and we are not recommending people reading all the rules. The tools will know the rules and point the programmers to the exact rule they break — and the rationale and examples will be right there to provide explanation.

Tell us what you think

Community comments

Modern C++ is great, but

Your message is awaiting moderation. Thank you for participating in the discussion.

The lack of good package management for C++ is really limiting it in today's software development world. Alternate systems programming languages like Go and Rust are making it easy to download and incorporate third party libraries in applications. These languages are making in roads into areas that used to be solely the realm of C++. With C++ the library and dependency management is non trivial and presents a lot of challenges to get a project started. Case in point - we were recently looking at incorporating some open source third party libraries in our networking server but the sheer complexity of setting up the build system and dev environments, prompted us to take a look at Go and finally we decided to go with GO. Although there are some fundamental differences in the runtime, the developer productivity gains are considerable to make a move towards Go. Hoping that the committee will address this challenge to make C++ more easily adoptable.