Articles & Books

Quick Q: C++11 auto: what if it gets a constant reference?

Quick A: auto never deduces a reference.

Recently on SO:

C++11 auto: what if it gets a constant reference?

Read this article: Appearing and Disappearing consts in C++

Type deduction for auto variables in C++0x is essentially the same as for template parameters. (As far as I know, the only difference between the two is that the type of auto variables may be deduced from initializer lists, while the types of template parameters may not be.) Each of the following declarations therefore declare variables of type int (never const int):

auto a1 = i;
auto a2 = ci;
auto a3 = *pci;
auto a4 = pcs->i;

During type deduction for template parameters and auto variables, only top-level consts are removed. Given a function template taking a pointer or reference parameter, the constness of whatever is pointed or referred to is retained:

template<typename T>
void f(T& p);

int i;
const int ci = 0;
const int *pci = &i;

f(i);               // as before, calls f<int>, i.e., T is int
f(ci);              // now calls f<const int>, i.e., T is const int
f(*pci);            // also calls f<const int>, i.e., T is const int

This behavior is old news, applying as it does to both C++98 and C++03. The corresponding behavior for auto variables is, of course, new to C++0x:

auto& a1 = i;       // a1 is of type int&
auto& a2 = ci;      // a2 is of type const int&
auto& a3 = *pci;    // a3 is also of type const int&
auto& a4 = pcs->i;  // a4 is of type const int&, too

Since you can retain the cv-qualifier if the type is a reference or pointer, you can do:

auto& my_foo2 = GetFoo();

Instead of having to specify it as const (same goes for volatile).

Edit: As for why auto deduces the return type of GetFoo() as a value instead of a reference (which was your main question, sorry), consider this:

const Foo my_foo = GetFoo();

The above will create a copy, since my_foo is a value. If auto were to return an lvalue reference, the above wouldn't be possible.

Using C++17 Parallel Algorithms for Better Performance--Billy O’Neal

Are you using the parallel capacities of the std?

Using C++17 Parallel Algorithms for Better Performance

by Billy O’Neal

From the article:

C++17 added support for parallel algorithms to the standard library, to help programs take advantage of parallel execution for improved performance. MSVC first added experimental support for some algorithms in 15.5, and the experimental tag was removed in 15.7.

The interface described in the standard for the parallel algorithms doesn’t say exactly how a given workload is to be parallelized. In particular, the interface is intended to express parallelism in a general form that works for heterogeneous machines, allowing SIMD parallelism like that exposed by SSE, AVX, or NEON, vector “lanes” like that exposed in GPU programming models, and traditional threaded parallelism.

Our parallel algorithms implementation currently relies entirely on library support, not on special support from the compiler. This means our implementation will work with any tool currently consuming our standard library, not just MSVC’s compiler. In particular, we test that it works with Clang/LLVM and the version of EDG that powers Intellisense...

How To Use std::visit With Multiple Variants--Bartlomiej Filipek

Variant utility.

How To Use std::visit With Multiple Variants

by Bartlomiej Filipek

From the article:

std::visit is a powerful utility that allows you to call a function over a currently active type in std::variant. It does some magic to select the proper overload, and what’s more, it can support many variants at once.

Let’s have a look at a few examples of how to use this functionality...

Quick Q: C++ constexpr - Value can be evaluated at compile time?

Quick A: if parameter are not known at compile time, it is like a normal function

Recently on SO:

C++ constexpr - Value can be evaluated at compile time?

The quoted wording is a little misleading in a sense. If you just take PlusOne in isolation, and observe its logic, and assume that the inputs are known at compile-time, then the calculations therein can also be performed at compile-time. Slapping the constexpr keyword on it ensures that we maintain this lovely state and everything's fine.

But if the input isn't known at compile-time then it's still just a normal function and will be called at runtime.

So the constexpr is a property of the function ("possible to evaluate at compile time" for some input, not for all input) not of your function/input combination in this specific case (so not for this particular input either).

It's a bit like how a function could take a const int& but that doesn't mean the original object had to be const. Here, similarly, constexpr adds constraints onto the function, without adding constraints onto the function's input.

Admittedly it's all a giant, confusing, nebulous mess (C++! Yay!). Just remember, your code describes the meaning of a program! It's not a direct recipe for machine instructions at different phases of compilation.

(To really enforce this you'd have the integer be a template argument.)

C++ Links #1--Bartlomiej Filipek

Things to look at.

C++ Links #1

by Bartlomiej Filipek

From the article:

I'd like to make an experiment on the blog and introduce a new simple series. Each Friday you'll see a summary with valuable links and resources from the C++ World. The links and annotations are coming from a guest author - Wojciech Razik - one of the co-author of cpp-polska.pl.

Stack Factory Puzzle -- Alex Marmer

When instances of classes derived from the same class need to be created based on certain conditions, they are created on the heap. The puzzle is about how to do it on the stack.

Stack Factory Puzzle

By Alex Marmer

 

Mathematics behind Comparison #4: Three-Way Comparison--Jonathan Müller

Everything you need to know!

Mathematics behind Comparison #4: Three-Way Comparison

by Jonathan Müller

From the article:

In order to sort a collection of elements you need to provide a sorting predicate that determines when one element is less than the other. This predicate must “induce a strict total ordering on the equivalence classes” according to cppreference. Wait, what?

The upcoming C++ spaceship operator implements a three-way comparison, i.e. it is a single function that can return the results of <, == and > combined. But related to it are terms like “strong equality” and “weak ordering” which are somewhat confusing if you don’t have the mathematical background.

So let’s untangle it: This series will explain both the mathematics behind equality and ordering, as well as give concrete guidelines for implementing the comparison operators and the spaceship operator.

Now that we’ve covered both equivalence and ordering relations we can finally talk about the spaceship operator and three-way comparisons...

Quick Q: How to track newer C++ std documents of given topic?

Quick A: Use wg21.link

Recently on SO:

How to track newer C++ std documents of given topic?

For the newer proposals (ones that start with the letter P) you can use wg21.link redirect service to obtain the latest document:

wg21.link - WG21 redirect service.

Usage:
wg21.link/nXXXX
wg21.link/pXXXX
wg21.link/pXXXXrX Get paper.

wg21.link/standard
Get working draft.

wg21.link/cwgXXX
wg21.link/ewgXXX
wg21.link/lwgXXX
wg21.link/lewgXXX
wg21.link/fsXXX
wg21.link/editXXX
Get issue.

wg21.link/index.json
wg21.link/index.ndjson
wg21.link/index.txt
wg21.link/specref.json
Get everything.

wg21.link/
Get usage.

For example for P0476: Bit-casting object representations if we use wg21.link/P0476 we obtain the latest version which is P0476R2.

In my answer to How does the standards committee indicate the status of a paper under consideration? I go into more details of the WG21 site and what documents you can find there.

Use the everything link for Pre P proposals
If we use the wg21 redirect service Get Everything link we can do a text search for the paper title. So for your example Improvements to std::future<T> and Related APIs we can see the last document is N3857:

"N3857": {
"type": "paper",
"title": "Improvements to std::future and Related APIs",
"subgroup": "Concurrency",
"author": "N. Gustafsson, A. Laksberg, H. Sutter, S. Mithani",
"long_link": "http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3857.pdf",
"link": "https://wg21.link/n3857",
"source": "http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/",
"date": "2014-01-16"
},