February 2018

optional in a possible C++20 future--Barry Revzin

Lots of proposals:

optional<T> in a possible C++20 future

by Barry Revzin

From the article:

C++17 gave us std::optional which is, in the words of a friend of mine, one of those really simple, ultra complex types — in the sense that it’s very easy to understand and use properly, even for relatively inexperienced programmers… but extremely difficult to implement correctly, even for experts (another such is std::pair). Today, it’s well over a thousand lines of code, most of which is critical to support even its most basic functionality. optional<T> is the simplest sum type, and it appears in lots of different languages (and even has special syntax in Swift) under various related names — Maybe, Option, etc. — but in the languages I’m even nominally familiar with, it’s about as simple to implement as it is to use.

But that’s the state of affairs today. What does tomorrow bring?

How if constexpr simplifies your code in C++17--Meeting C++

Very useful.

How if constexpr simplifies your code in C++17

by Meeting C++

From the article:

So, yesterday we had a little live coding session at my C++ User Group Düsseldorf. I want to recreate some of this code, to show how C++17 actually does help quite a bit with making code shorter and more expressive. Since I don't have a local C++17 compiler installed, I use godbolt and wandbox to test some of the examples...

Quick Q: What's the difference between std::move and std::forward?

Quick A: One is used to forward parameters, one to move an object.

Recently on SO:

What's the difference between std::move and std::forward?

std::move takes an object and allows you to treat it as a temporary (an rvalue). Although it isn't a semantic requirement, typically a function accepting a reference to an rvalue will invalidate it. When you see std::move, it indicates that the value of the object should not be used afterwards, but you can still assign a new value and continue using it.

std::forward has a single use case: to cast a templated function parameter (inside the function) to the value category (lvalue or rvalue) the caller used to pass it. This allows rvalue arguments to be passed on as rvalues, and lvalues to be passed on as lvalues, a scheme called "perfect forwarding."

To illustrate:

void overloaded( int const &arg ) { std::cout << "by lvalue\n"; }
void overloaded( int && arg ) { std::cout << "by rvalue\n"; }

template< typename t >
/* "t &&" with "t" being template param is special, and  adjusts "t" to be
   (for example) "int &" or non-ref "int" so std::forward knows what to do. */
void forwarding( t && arg ) {
    std::cout << "via std::forward: ";
    overloaded( std::forward< t >( arg ) );
    std::cout << "via std::move: ";
    overloaded( std::move( arg ) ); // conceptually this would invalidate arg
    std::cout << "by simple passing: ";
    overloaded( arg );
}

int main() {
    std::cout << "initial caller passes rvalue:\n";
    forwarding( 5 );
    std::cout << "initial caller passes lvalue:\n";
    int x = 5;
    forwarding( x );
}

As Howard mentions, there are also similarities as both these functions simply cast to reference type. But outside these specific use cases (which cover 99.9% of the usefulness of rvalue reference casts), you should use static_cast directly and write a good explanation of what you're doing.

C++ Tips on Initialization

C++ initialization is tricky. Check out Abseil's C++ Tips on initialization, which we've published over the past two weeks:

Fro​m Tip of the Week #142:


"Prior to C++11, the explicit keyword was meaningful only for constructors that could be called with a single argument, and our style guide required its use for such constructors so that they did not act as 'converting constructors.' That requirement was not applied for multi-parameter constructors. Indeed the style guide used to discourage use of explicit for multi-parameter constructors as it had no meaning. That’s no longer the case."

New: C++ Foundation Developer Survey "Lite", 2018-02

cpp_logo.pngToday the Standard C++ Foundation opened its first-ever global C++ developer survey. As the name suggests, it's a one-pager:

C++ Developer Survey "Lite": 2018-02

Please take 10 minutes or so to participate! A summary of the results, including aggregated highlights of common answers in the write-in responses, will be posted publicly here on isocpp.org and shared with the C++ standardization committee to help inform C++ evolution.

If this one is successful we plan to do it again, perhaps annually or quarterly.

Thank you for participating and helping to inform our committee and community.

CopperSpice: Undefined Behavior

New videos on the CopperSpice YouTube Channel:

C++ Undefined Behavior

by Barbara Geller and Ansel Sermersheim

About the video:

A look at the topic of Undefined Behavior in C++. We discuss what UB is, what can happen when your program experiences UB, and how to avoid it.

Please take a look and remember to subscribe!