July 2017

C++17 attributes - maybe_unused, fallthrough and nodiscard—Simon Brand

Do you know these new attributes?

C++17 attributes - maybe_unused, fallthrough and nodiscard

by Simon Brand

From the article:

C++17 adds three new attributes for programmers to better express their intent to the compiler and readers of the code: maybe_unused, fallthrough, and nodiscard. This is a quick post to outline what they do and why they are useful.

Quick Q: Why is the count of weak_ptr tracked also?

Quick A: To be able to know when to delete the control block.

Recently on SO:

Why shared_ptr's reference counting object needs to keep track of the number of weak_ptrs pointing to the object too?

std::weak_ptr refers to the control block to know if the object still exists and if so, to provide a std::shared_ptr to it when needed. For that reason, the control block must exist as long as either a std::weak_ptr or a std::shared_ptr exists. You need to track the number of instances of std::weak_ptr to know when the last one is destroyed, just like for std::shared_ptr.

CppCon 2016: Constant Fun—Dietmar Kühl

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:

Constant Fun

by Dietmar Kühl

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

This presentation discusses why it is useful to move some of the processing to compile time and shows some applications of doing so. In particular it shows how to create associative containers created at compile time and what is needed from the types involved to make it possible. The presentation also does some analysis to estimate the costs in terms for compile-time and object file size.

Specifically, the presentation discusses:
- implications of static and dynamic initialization – the C++ language rules for implementing constexpr functions and classes supporting constexpr objects.
- differences in error handling with constant expressions.
- sorting sequences at compile time and the needed infrastructure – creating constant associative containers with compile-time and run-time look-up.

Yielding Generators—Kirit Sælensminde

The series continue!

Yielding Generators

by Kirit Sælensminde

From the article:

We've seen how the promise_type together with the coroutine return type handles the interactions between the caller and the coroutine itself.

Our target is to be able to do something pretty simple:

generator count() {
    std::cout << "Going to yield 1" << std::endl;
    co_yield 1;
    std::cout << "Going to yield 2" << std::endl;
    co_yield 2;
    std::cout << "Going to yield 3" << std::endl;
    co_yield 3;
    std::cout << "count() is done" << std::endl;
}

CppCon 2016: There and Back Again: An Incremental C++ Modules Design—Richard Smith

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:

There and Back Again: An Incremental C++ Modules Design

by Richard Smith

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

The Clang project has been working on Modules in one form or another for many years. It started off with C and Objective-C many years ago. Today, we have a C++ compiler that can transparently use C++ Modules with existing C++ code, and we have deployed that at scale. However, this is very separate from the question of how to integrate a modular compilation model into the language itself. That is an issue that several groups working on C++ have been trying to tackle over the last few years.

Based on our experience deploying the core technology behind Modules, we have learned a tremendous amount about how they interact with existing code. This has informed the particular design we would like to see for C++ Modules, and it centers around incremental adoption. In essence, how do we take the C++ code we have today, and migrate it to directly leverage C++ Modules in its very syntax, while still interacting cleanly with C++ code that will always and forever be stuck in a legacy mode without Modules.

In this talk we will present our ideas on how C++ Modules should be designed in order to interoperate seamlessly with existing patterns, libraries, and codebases. However, these are still early days for C++ Modules. We are all still experimenting and learning about what the best design is likely to be. Here, we simply want to present a possible and still very early design direction for this feature.

CppCast Episode 110: Coroutines with Gor Nishanov

Episode 110 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Gor Nishanov to talk about the C++ Coroutines proposal.

CppCast Episode 110: Coroutines with Gor Nishanov

by Rob Irving and Jason Turner

About the interviewee:

Gor Nishanov is a Principal Software Design Engineer on the Microsoft C++ team. He works on design and standardization of C++ Coroutines, and on asynchronous programming models. Prior to joining C++ team, Gor was working on distributed systems in Windows Clustering team.

Quick Q: How to (and who can) implement the standard library features defined by the C++ committee?

Quick A: Everyone by reading and applying the C++ standard.

Recently on SO:

How to (and who can) implement the standard library features defined by the C++ committee?

The committee does not release any reference implementations. In the early days, things got standardized and then the tool developers went away and implemented the standard. This has changed, and now the committee looks for features that have been implemented and tested before standardization.

Also major developments usually don't go directly into the standard. First they become experimental features called a Technical Specification or TS. These TS may then be incorporated into the main standard at a later date.

You are free to write you own implementation of the C++ standard library. Plum Hall has a test suite (commercial, I have no connection, but Plum Hall are very involved with C++ standardization).

I don't see any issue with not being conformant. Almost all implementations have some extensions. Just don't make any false claims, especially if you want to sell your product.

If you're interested in getting involved, this can be done via your 'National Body' (ANSI for the USA, BSI for the UK etc.). The isocpp web site has a section on standardization which would be a good starting place.

CLion 2017.2 released with Clang-Tidy and more—JetBrains

Welcome new release of JetBrain's cross-platform C/C++ IDE!

CLion 2017.2 released

by Anastasia Kazakova

From the article:

CLion 2017.2 is all about C++ parser correctness, new code analysis features and performance improvements. Clang-Tidy integration, C++ cast operators and other code analysis enhancements help to ensure the code quality, while the rest bring general improvements to the user experience.

The highlighted new features are:

  • Clang-Tidy checks and complementary quick-fixes come to CLion. This includes checks from C++ Core Guidelines, modernize checks and many others.
  • C++ support enhancements:
    • C++17 is now available in the New Project wizard
    • Precompiled headers are now supported when using Microsoft Visual C++ compiler (in addition to GCC and Clang)
    • Code intentions and quick-fixes use C++ cast operators for C++ code instead of C-style cast
    • Dozens of improvements in C++ parser and built-in code analysis engine
  • A new Force Step Into action for getting into disassembly code only when you really want to.
  • Cancelable CMake reload and Go to navigation actions to ensure better IDE performance.
  • Bundled CMake 3.8.