Home » Blog » Categories » Articles & Books

Articles & Books

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.

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.

What Every Programmer Should Know About Compiler Optimizations--Hadi Brais

By Adrien Hamelin | Feb 4, 2015 02:08 PM | Tags: performance intermediate

Everything is in the title:

What Every Programmer Should Know About Compiler Optimizations

by Hadi Brais

From the article:

High-level programming languages offer many abstract programming constructs such as functions, conditional statements and loops that make us amazingly productive. However, one disadvantage of writing code in a high-level programming language is the potentially significant decrease in performance. Ideally, you should write understandable, maintainable code—without compromising performance. For this reason, compilers attempt to automatically optimize the code to improve its performance, and they’ve become quite sophisticated in doing so nowadays. They can transform loops, conditional statements, and recursive functions; eliminate whole blocks of code; and take advantage of the target instruction set architecture (ISA) to make the code fast and compact. It’s much better to focus on writing understandable code, than making manual optimizations that result in cryptic, hard-to-maintain code. In fact, manually optimizing the code might prevent the compiler from performing additional or more efficient optimizations...

Expressions can have Reference Type--Scott Meyers

By Adrien Hamelin | Feb 4, 2015 02:03 PM | Tags: c++11 advanced

Did you you know that...

Expressions can have Reference Type

by Scott Meyers

From the article:

Today I got email about some information in Effective Modern C++. The email included the statement, "An expression never has reference type." This is easily shown to be incorrect, but people assert it to me often enough that I'm writing this blog entry so that I can refer people to it in the future...

Iterators++, Part 1--Eric Niebler

By Adrien Hamelin | Feb 4, 2015 01:53 PM | Tags: c++11 advanced

A new post on iterators:

Iterators++, Part 1

by Eric Niebler

From the article:

In the last post, I described the so-called proxy iterator problem: the fact that iterators that return proxy references instead of real references don’t sit comfortably within the STL’s framework. Real, interesting, and useful iterators fall foul of this line, iterators like vector<bool>‘s or like the iterator of the zip view I presented. In this post, I investigate what we could do to bring proxy iterators into the fold — what it means for both the iterator concepts and for the algorithms. Since I’m a library guy, I restrict myself to talking about pure library changes...