GCC5 and the C++11 ABI--rhjason

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

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.

CppCon 2014 Modernizing Legacy C++ Code--James McNellis & Kate Gregory

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Modernizing Legacy C++ Code

by James McNellis and Kate Gregory

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

C++ is a programming language with a long, storied history spanning over three decades--four if one includes its C ancestry. The C++ language has undergone many changes during that time, compiler technology has advanced substantially, and computers today are very different from the computers of decades past. But despite all of these advances, there's an awful lot of C++ code in use today that looks like it was written in the 1980s. In some cases, the code was written in the 1980s and it's still in use; in other cases, it's recently-written code that just doesn't use modern style.

In this talk, we'll discuss some of the problems with legacy code, and review some practical techniques for applying principles of modern C++ to gradually improve the quality of legacy code and improve maintainability and debuggability. We'll show how some very small changes to code can yield huge benefits.

N4373: Atomic View (Rev. N4142, Atomic Operations on a Very Large Array) -- C Edwards, H Boehm

New WG21 papers are available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4373

Date: 2015-01-26

Atomic View (Revision to N4142, Atomic Operations on a Very Large Array)

by Carter Edwards and Hans Boehm

Excerpt:

This paper proposes an extension to the atomic operations library [atomics] for atomic operations applied to non-atomic objects. The proposal is in three parts: (1) the concept of an atomic view, (2) application of this concept for atomic operations applied to members of a very large array in a high performance computing (HPC) code, and (3) application of this concept for atomic operations applied to an object in a large legacy code which cannot replace this object with a corresponding atomic object.

CppCon 2014 Writing Data Parallel Algorithms on GPUs--Ade Miller

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Writing Data Parallel Algorithms on GPUs

by Ade Miller

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Today most PCs, tablets and phones support multi-core processors and most programmers have some familiarity with writing (task) parallel code. Many of those same devices also have GPUs but writing code to run on a GPU is harder. Or is it?

Getting to grips with GPU programming is really about understanding things in a data parallel way. This talk will look at some of the common patterns for implementing algorithms on today's GPUs using examples from the C++ AMP Algorithms Library. Along the way it will cover some of the unique aspects of writing code for GPUs and contrast them with a more conventional code running on a CPU.

Sqlpp11, An EDSL For Type-Safe SQL In C++11

A new video from Meeting C++ 2014:

Sqlpp11, An EDSL For Type-Safe SQL In C++

by Roland Bock

From the talk description:

Most C/C++ interfaces to SQL databases are string based. Theses strings effectively hide expression structures, names and types from the compiler. And they are vendor-specific. And they defer expression parsing and validation until the test phase or (even worse) production...

Quick Q: What is move_iterator for?

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.