Home » Blog » Categories » Articles & Books

Articles & Books

Yes, we must replace it++ with ++it--Andrey Karpov

By Andrey Karpov | Jan 29, 2015 11:18 PM | Tags: performance iterators c++ basics

I decided to find out if there is practical sense in writing ++iterator instead of iterator++ when handling iterators.

Is it reasonable to use the prefix increment operator ++it instead of postfix operator it++ for iterators?

by Andrey Karpov

From the article:

I will always write ++it. I did so before but I did it "just in case". Now I can see how useful it is because I regularly launch debug versions. In general, of course, ++it has a very slight influence on the running time. But if I don't make such small optimizations in different places of the code, it will be too late and the profiler won't help me. Bottlenecks will be spread throughout the code.

 

Funny bug #20150127--Marco Foco

By Marco Arena | Jan 29, 2015 10:14 AM | Tags: intermediate boost

Marco Foco spotted a subtle bug in a piece of code that used boost::program_options. Can you find it?

Funny bug #20150127

by Marco Foco

From the article:

Two days ago I’ve been asked to have a look at a nonworking piece of code, based on boost::program_options [...] This syntax is not only unusual, but also dangerous. 

To Be or Not to Be (an Iterator) -- Eric Niebler

By Felix Petriconi | Jan 29, 2015 01:03 AM | Tags: intermediate basics

Eric Niebler gives in his recent blog post insights about iterators

To Be or Not To Be (an Iterator)

by Eric Niebler

From the article:

Way back in 1999, when the ink on the first C++ standard was still damp, Herb Sutter posed a GoTW puzzler in the still extant C++ Report (RIP): When Is a Container Not a Container? In that article, Herb described the problems of the now-infamous vector<bool>. According to the standard’s own container requirements, vector<bool> is not a container.

In a nutshell, it’s because vector<bool>‘s iterators claim to be random-access, but they’re not. Random-access iterators, when you dereference them, must return a real reference. They can only do that if the thing they point to really exists somewhere. But the bool that a vector<bool>::iterator points to does not exist anywhere. It’s actually a bit in a packed integer, and dereferencing a vector<bool>‘s iterator returns an object of some type that merely acts like a bool& without actually being a bool&.

Experimenting with a Proposed Standard Drawing Library for the C++ language -- Eric Mittelette

By Blog Staff | Jan 28, 2015 08:42 PM | Tags: None

Today on MSOT:

Experimenting with a Proposed Standard Drawing Library for the C++ language

by Eric Mittelette

From the article:

Back in July, Michael McLaughlin, Herb Sutter, and Jason Zink submitted to the ISO an updated proposal to standardize a 2D Graphics API for the C++ programming language. The ISO C++ Committee will evaluate the proposal for the possible inclusion of these new features in the next versions of the specification.

Given MS Open Tech’s historical interest in cross-platform graphics development, we took a closer look. In an attempt to familiarize with the API from the perspective of a C++ developer, we developed a sample app that we just contributed to Michael’s github repository. In the sections below, we share some salient aspects of how this new crop of Graphics experiences built with “straight” C++ could be written, only a few years from now!
 

 

The compiler can make up its own calling conventions, within limits--Raymond Chen

By Herb Sutter | Jan 28, 2015 12:43 PM | Tags: advanced

A new article from the Old New Thing:

The compiler can make up its own calling conventions, within limits

by Raymond Chen

From the article:

There are three parties to a calling convention. The function doing the calling. The function being called. The operating system. The operating system needs to get involved if something unusual occurs, like an exception, and it needs to go walking up the stack looking for a handler...

The lvalue/rvalue metaphor--Joseph Mansfield

By Herb Sutter | Jan 28, 2015 12:38 PM | Tags: intermediate c++11

Joseph Mansfield discusses about an important topic in C++:

The lvalue/rvalue metaphor

by Joseph Mansfield

From the article:

Every expression in C++ is either an lvalue or an rvalue. This distinction is what makes something like 5 = x; invalid, as the expression 5 is an rvalue expression and so cannot appear on the left of an assignment...

January 2015 C++ Compilers Status--Christophe Riccio

By Herb Sutter | Jan 28, 2015 12:29 PM | Tags: intermediate c++14 c++11

Christophe Riccio gives us an interesting point of view for a library author and shares the latest status of some compilers:

January 2015 C++ Compilers Status

by Christophe Riccio

From the article:

...Finally, a last issue for adopting new C++11 features is simply our own ignorance of which feature is available on all the compilers we support. To resolve that problem, I made the followiong table listing all the C++ features and their support on Clang, GCC, ICC and Visual C++...

for_each_arg -- Eric Niebler

By Felix Petriconi | Jan 26, 2015 05:49 AM | Tags: None

Eric Niebler picked up the Sean Parent's challenge regarding his for_each_argument tweet.

for_each_arg

by Eric Niebler

And after several iterations between Sean and Eric this is the beautiful result:

template<class F, class...Ts>
F for_each_arg(F f, Ts&&...a) {
  return (void)initializer_list<int>{(ref(f)((Ts&&)a),0)...}, f;
}