Selective argument application -- Krzysztof Ostrowski

By fj | Mar 6, 2018 09:04 AM | Tags: c++17 advanced

Presentation of a technique that enables transparent interception of the selected arguments passed to any function by means of a user-provided predicate metafunction.

Selective argument application

by Krzysztof Ostrowski

From the article:

Presentation of a design of an interceptor abstraction built over C++17 utilities that records values of the selected arguments passed to any action transparently, then applies that action to the captured arguments, and eventually passes the result value to the next action.

RIP index_sequence, 2014–2017 -- Matt Aubury

By Matt Aubury | Mar 6, 2018 09:00 AM | Tags: c++17

Matt Aubury philosophizes about digging a grave for certain std::index_sequence idioms. 

RIP index_sequence, 2014–2017

by Matt Aubury

From the article:

std::tuple was one of the great additions to C++11. Whilst sometimes abused by lazy programmers (who should really be using a struct or class), it’s true value is as a container of arbitrary values in variadic templates.

Sadly, static typing makes working with tuples much harder in C++ than in most languages [...]

What are the C and C++ Standard Libraries?

By triangles | Mar 6, 2018 08:55 AM | Tags: None

A brief tour into the realm of writing C and C++ applications, the role of the Standard Library and how it is implemented in various operating systems.

What are the C and C++ Standard Libraries?

By Triangles @ Internal Pointers

From the article:

I have been playing around with C++ for a while and one thing that always got me confused in the beginning was its anatomy: where do the core functions and classes I'm using come from? Who invented them? Are they packaged somewhere in my system? Is there a kind of official C++ manual around?

What Should Go Into the Standard Library -- Titus Winters

By shreck | Mar 2, 2018 12:04 AM | Tags: None

Titus responds to Guy Davidson's article, what should go into the STL.

What Should Go Into the C++ Standard Library

By Titus Winters

From the article:

So, what should go in the standard library? Fundamentals. Things that can only be done with compiler support, or compile-time things that are so subtle that only the standard should be trusted to get it right. Vocabulary. Time, vector, string. Concurrency. Mutex, future, executors. The wide array of “sometimes useful data structure” and “random metaprogramming” could and should be shuffled off into a semi-standard repository of available but distinct utility libraries. Those may themselves have different design and stability philosophies, like Boost or Abseil - the principles that make the standard what it is are not necessarily universal even if they are good for the standard. Graphics is too much - many won’t want it, and those that think they do may not understand what they are asking for.

C++ User Group Meetings in March

By Meeting C++ | Mar 1, 2018 08:19 AM | Tags: usergroups meetingcpp community

The monthly overview on upcoming C++ User Group Meetings

C++ User Group Meetings in March

by Jens Weller

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

By Adrien Hamelin | Feb 27, 2018 07:59 PM | Tags: experimental

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++

By Adrien Hamelin | Feb 27, 2018 07:56 PM | Tags: c++17

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?

By Adrien Hamelin | Feb 27, 2018 07:50 PM | Tags: c++11 advanced

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

By shreck | Feb 27, 2018 01:45 AM | Tags: None

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

• Tip of the Week #61: Default Member Initializers

• Tip of the Week #88: Initialization: =, (), and {}

• Tip of the Week #134: make_unique and private constructors

• Tip of the Week #142: Multi-parameter Constructors and `explicit`

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."

A cake for your cherry: what should go in the C++ standard library? -- Corentin Jabot

By Corentin Jabot | Feb 22, 2018 11:34 PM | Tags: None

A reply to Guy Davidson’s article “Batteries not included: what should go in the C++ standard library?”.

A cake for your cherry: what should go in the C++ standard library?

by Corentin Jabot

From the article

Over the past few years there has been a push to include a graphics library into the C++ standard. It would be something a bit like cairo. Or SDL.

I do think this is a path that should not be pursued. Let me tell you why...