Articles & Books

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.

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

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

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

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

Still Comparing "this" Pointer to Null?--Dmitry Meshcheryakov

The article explains why one must never use the (this == 0) expression. It's a very bad code. It being able to work at times doesn't mean anything. By writing (this == 0), you let undefined behavior into your program.

Still Comparing "this" Pointer to Null?

by Dmitry Meshcheryakov

From the article:

In the same way the compiler can optimize the code comparing "this" pointer to null. According to the Standard, this cannot be null and therefore the checks and the corresponding code branches can be eliminated, which will greatly affect the code dependent on the comparison of "this" pointer to null. The compiler has a full right to "break" (actually just break it further) the code CWindow::GetSafeHandle() and generate machine code which doesn't contain the comparison and only reads the class field all the time.
...
GOOD LORD, the "this" pointer equals 0x00000004 on entering the method when compiled in Visual C++ 9, as the pointer initially set to null is adjusted so that it points to the beginning of a subobject of the corresponding class.

No need to square, sum, and sqrt manually anymore--Indi

A useful remainder for programmers, the std::hypot function:

No need to square, sum, and sqrt manually anymore

by Indi

From the article:

I hang out a lot with engineers and game programmers, so that means I tend to see a lot of code dealing with physics problems. One of the most commonly used bits of code in both domains has to be the Euclidean distance equation. However, few programmers realize that that equation is a lot easier than it used to be...

Improving error messages in C++ by transporting substitution failures--Paul Fultz II

A useful post for library writers:

Improving error messages in C++ by transporting substitution failures

by Paul Fultz II

From the article:

This is an advanced blog post more geared to library writers who want to improve error messages due to substitution failure. It discuss how substitution failures can be transported so the correct information can be presented to the user. Lets first look at the problem...

The bell has tolled for rand()--Indi

An extensive article about rand(), it's replacement in C++11 and the possible future was posted last december:

The bell has tolled for rand()

by Indi

Form the article:

In their recent meeting in Urbana, the C++ standard committee took the rare step of removing several outdated facilities from (what will probably become) C++17. Most of the things removed had been deprecated since C++11, but there was one surprising item on the list: std::random_shuffle(). Its removal is a signal of a big change that has been building in the background for a while: the end of std::rand()...