C++17 Library Papers for Cologne

By Meeting C++ | Feb 14, 2015 03:36 AM | Tags: standardization intermediate committee c++17

The first part of a mini series about the Library Papers for the LWG Meeting in Cologne:

C++17 Library Papers for Cologne

by Jens Weller

From the article:

Last fall I did the last series about the Standardization papers for C++. I didn't had the time to finish the last part for the Library subgroup, as Meeting C++ 2014 was getting close too. I'll be attending the next meeting of the Library Working Group in Cologne, which is just a few days away, so I'll do a miniseries for the LWG papers...

Default Constructed Return Value: return {} -- Adi Shavit

By Adi | Feb 13, 2015 04:52 PM | Tags: c++11

Simplify your code using a default constructed return value with `return {}`:

Default Constructed Return Value: return {}

by Adi Shavit

From the article:

It is common for C/C++ functions to return default values, for example, if some internal condition fails.
This is straightforward for native return types. This pattern is often seen in factory methods or functions that return a polymorphic type via a base handle.

If the function has multiple early return points, this default construction needs to be repeated at each such point and each time stating the explicit return type just for calling the default ctor. This is annoying because the compiler already knows the return type.

Ranges and Iterators for numerical problems

By Meeting C++ | Feb 12, 2015 09:29 AM | Tags: performance intermediate c++11 boost

A guest blog post by Karsten Ahnert at Meeting C++ as a follow up of his talk!

Ranges and Iterators for numerical problems

by Karsten Ahnert

From the article:

In this blog post I am going to show some ideas how one can implement numerical algorithms with ranges. Examples are the classical Newton algorithm for finding the root of a function and ordinary differential equations. The main idea is to put the main loop of the algorithm into range such that the user can...

How do I write complex initialization?--Stack Overflow

By Adrien Hamelin | Feb 11, 2015 11:21 AM | Tags: intermediate c++11

Quick A: Initialize it using a lambda that’s invoked immediately.

Recently on SO:

Best practice for declaring variable without initialising it, so auto is unavailable

I want to declare two variables of the same type, and have the compiler figure out the types. However I don't want to initialise one of the variables until later. I don't think I can use auto here, so what's the best option?

std::vector<int> v;

// `start` and `end` should be the same type
auto start = v.begin();
??? end;

// complicated code to assign a value to `end` (i.e. putting
// the code in a function or using ?: is not practical here) 
if (...) {
    end = ...;
} else {
    end = v.end();
}

What's the best way to tell the compiler that end should be the same type as start, but without having to initialise the variable?

auto start = v.begin(), end;  // Doesn't work, `end` has to be initialised
decltype(start) end;          // Does work, but not sure if it's best practice

Update

A couple of comments have suggested ways that would work in certain situations, so I am clarifying my situation here:

std::vector<int> v;
int amount = 123;

// `start` and `end` should be the same type
auto start = v.begin();
??? end;

// code to assign a value to `end`
if (amount) {
    end = start + amount;
    amount = 0;
} else {
    end = v.end();
}

I believe a lamda function would be trickier here, because amount is being reset to 0 after end is calculated, so in a lamda function that calculates a value for end, amount = 0 would have to come after the return statement. The only option would be to create more local variables, which would incur an (admittedly tiny) performance penalty.

The Rule of Zero revisited: The Rule of All or Nothing--Arne Mertz

By Adrien Hamelin | Feb 11, 2015 11:17 AM | Tags: c++11 basics

In this article you will find a new rule of thumb:

The Rule of Zero revisited: The Rule of All or Nothing

by Arne Mertz

From the article:

In 2012, Martinho Fernandes coined the Rule of Zero in a blog post. In 2014, Scott Meyers wrote a blog post about a concern with that rule and proposed a Rule of Five Defaults.

Back then, I had written a small comment on Scott’s post that deserves some further elaboration. In this post I am going to wrap up my thoughts about the two posts and propose a “Rule of All or Nothing”...

Desired compile-time failures--Andrzej Krzemieński

By Adrien Hamelin | Feb 10, 2015 08:51 AM | Tags: intermediate c++11

Sometimes, an error is what we want:

Desired compile-time failures

by Andrzej Krzemieński

From the article:

However, even though [not introducing breaking changes] works in most of the cases, I believe that this criterion of a “safe addition” is not technically correct, as it fails to take into account an important fact: failure to compile certain programs is a useful, important feature, and if these programs suddenly start to compile, it can cause harm. In this post we will go through the cases where compile-time failure is considered a useful feature...

GCC5 and the C++11 ABI--rhjason

By Adrien Hamelin | Feb 10, 2015 08:24 AM | Tags: c++11 advanced

A new article of interest for library developers:

GCC5 and the C++11 ABI

by rhjason

From the article:

The GNU C++ team works hard to avoid breaking ABI compatibility between releases, including between different -std= modes. But some new complexity requirements in the C++11 standard require ABI changes to several standard library classes to satisfy, most notably to std::basic_string and std::list. And since std::basic_string is used widely, much of the standard library is affected...

Overload 125 is now available

By Felix Petriconi | Feb 10, 2015 02:08 AM | Tags: intermediate c++14

ACCU's Overload journal of February 2015 is out. It contains C++ related articles.

Overload 125

From the journal:

Making a Tool of Deception: Is it possible to use modern C++ to make mocking easy? Björn Fahller introduces Trompeloeil, a header-only mocking framework for C++14.

Modern C++ Testing: Various C++ testing framework exist. Phil Nash compares CATCH with the competition.

I Like Whitespaces: Bob Schmidt shares why he thinks whitespaces matters.

std::random_shuffle is deprecated in C++14

By Meeting C++ | Feb 6, 2015 04:10 AM | Tags: intermediate c++14 boost basics

A new blog post at Meeting C++, this time its about std::random_shuffle and C++14:

std::random_shuffle is deprecated in C++14

by Jens Weller

From the article:

So, one of the new things in C++14 is, that the committee has actually started to deprecate (and later remove) a few things from the standard. One of them is a rather awkward function: random_shuffle.

Quick Q: What is move_iterator for?

By Adrien Hamelin | Feb 4, 2015 02:12 PM | Tags: intermediate c++11

Quick A: To enabling moving out of *iterator.

Recently on SO:

What is move_iterator for?

If I understand it correct, a=std::move(b) binds reference a to the address of b. And after this operation the content that b points to is not guaranteed.

The implementation of move_iterator here has this line

auto operator[](difference_type n) const -> decltype(std::move(current[n]))
  { return std::move(current[n]); }

However, I don't think it makes sense to std::move an element in an array. What happens if a=std::move(b[n])?

The following example confuses me also:

std::string concat = std::accumulate(
                             std::move_iterator<iter_t>(source.begin()),
                             std::move_iterator<iter_t>(source.end()),
                             std::string("1234"));

Since the concat will itself allocate a continuous chunk of memory to store the result, which will not have any overlap with source. The data in source will be copied to concat but not moved.