Articles & Books

More than you need--Andrzej Krzemieński

Some thoughts about what the standard provides by default:

More than you need

by Andrzej Krzemieński

From the article:

The classes you design can do more (in terms of allowed operations) than what you could figure out from just looking at their member function declarations. The C++ Standard defines a number of cases where certain expressions involving your type are valid, even though there are no corresponding member function declarations. Sometimes this is just what you need; but sometimes the additional operations you never asked for can have grave negative impact on your program correctness...

 

Lambda hackery: Overloading, SFINAE and copyrights -- Nikos Athanasiou

Lambdas are often miscalled "functions"; learn how to implement some "function only" features in the article:

Lambda hackery: Overloading, SFINAE and copyrights

by Nikos Athanasiou

From the article:

If we think of lambdas as functions we’d might make an attempt to overload them. This attempt is easy to rebut by stating that lambdas are closures ie runtime objects and well … objects, even callable ones, do not overload! (...) The closest thing to a lambda that can overload is its function call operator, so you might already had your “aha!” moment by now. If not, here it is ...

Quick Q: What container should I use to reduce fragmentation caused by lots of small allocations?

Quick A: The only one matching the requirements is a std::deque, but it might be worth to consider using a memory pool.

Recently on SO:

What C++ std container should I use to reduce fragmentation caused by lots of small allocations?

Since you're asking specifically for a standard container, std::deque is the most promising option given your requirements. As long as you only add elements, the existing ones are not relocated, and references/pointers (but not iterators) remain valid. When removing elements, you may however need to leave gaps or swap the element to remove with the last element.

std::vector is not stable, and std::list, std::forward_list as well as all the associative containers are fragmented.

Looking at Boost.Container, you have additional options, however with other trade-offs:

boost::flat_map provides contiguous storage (like std::vector), but with it the stability problem
boost::stable_vector offers element stability at the cost of contiguity.
Alternatively, you can have a look at pool allocators (like Boost.Pool). They provide low fragmentation and fast allocation, and the container in front of it can still be used like a normal container.

Bitesize Modern C++ : Smart pointers--Glennan Carnie

Do you know about smart pointers?

Bitesize Modern C++ : Smart pointers

by Glennan Carnie

From the article:

The dynamic creation and destruction of objects was always one of the bugbears of C. It required the programmer to (manually) control the allocation of memory for the object, handle the object’s initialisation then ensure that the object was safely cleaned-up after use and its memory returned to the heap. Because many C programmers weren’t educated in the potential problems (or were just plain lazy or delinquent in their programming) C got a reputation in some quarters for being an unsafe, memory-leaking language...

Do You Prefer Fast or Precise?--Jim Hogg

A nice article explaining the troubles of float numbers, and what effects it can have. It is talking in the case of Visual C++, but the problems are the same for other compilers.

Do You Prefer Fast or Precise?

by Jim Hogg

From the article:

Floating Point Basics

In C++, a float can store a value in the 3 (approximate) disjoint ranges { [-E+38, -E-38], 0, [E-38, E+38] }. Each float consumes 32 bits of memory. In this limited space, a float can only store approximately 4 billion different values. It does this in a cunning way, where adjacent values for small numbers lie close together; while adjacent values for big numbers lie far apart. You can count on each float value being accurate to about 7 decimal digits.

Floating Point Calculations

We all understand how a computer calculates with ints. But what about floats? One obvious effect is that if I add a big number and a small number, the small one may simply get lost. For example, E+20 + E-20 results in E+20 – there are not enough bits of precision within a float to represent the precise/exact/correct value...

Bjarne Stroustrup on the 30th anniversary of Cfront (the first C++ compiler) -- A. Regat-Barrel

cpp30.PNGHow time flies -- 30 years ago today, the Cfront 1.0 compiler and the first edition of The C++ Programming Language were officially released. In celebration of the event, here's a new interview with Bjarne Stroustrup.

Bjarne Stroustrup on the 30th anniversary of Cfront (the first C++ compiler)

by Aurélien Regat-Barrel

Candidate for favorite quote: "I did learn a fair bit about C++ by trying to explain it to people." Experienced instructors will all tell you the same thing -- you really grok something after you've taught it to others. Thanks for 30+ years of teaching, Dr. Stroustrup!

30 Years of C++ -- Aurélien Regat-Barrel

Aurélien Regat-Barrel interviewed Bjarne Stroustrup about the first release of CFront (the first C++ compiler), exactly 30 years ago.

30 Years of C++

by Aurélien Regat-Barrel

From the article:

Aurélien Regat-Barrel gives an overview of the evolution of the language and talks with Bjarne Stroustrup about the first publication of "C++ The Programming Language", how he experienced the evolution of the language and they close the interview with an outlook of what is coming in the future.

 

Overload 129 is now available

ACCU’s Overload journal of October 2015 is out. It contains the following C++ related articles.

Overload 129 / PDF

From the journal:

Description : Concepts in C++11 had many false starts. Andrew Sutton show why they are a big deal now they are with us. by Andrew Sutton

Description : Concepts are abstract. Jonathan Coe and Andrew Sutton provide us with a concrete example of their use. by Jonathan Coe

 

 

Improving performance and maintainability through refactoring in C++11 -- Garcia, Stroustrup

garcia-stroustrup.PNGIn the "writing better code" department:

Improving performance and maintainability through refactoring in C++11

by J. Daniel Garcia and Bjarne Stroustrup

Abstract:

Abstraction based programming has been traditionally seen as an approach that improves software quality at the cost of losing performance. In this paper, we explore the cost of abstraction by transforming the PARSEC benchmark fluidanimate application from low-level, hand-optimized C to a higher-level and more general C++ version that is a more direct representation of the algorithms. We eliminate global variables and constants, use vectors of a user-defined particle type rather than vectors of built-in types, and separate the concurrency model from the application model. The result is a C++ program that is smaller, less complex, and measurably faster than the original. The benchmark was chosen to be representative of many applications and our transformations are systematic and based on principles. Consequently, our techniques can be used to improve the performance, flexibility, and maintainability of a large class of programs. The handling of concurrency issues has been collected into a small new library, YAPL.

Bitesize Modern C++ : std::array--Glennan Carnie

Some details about arrays in C++:

Bitesize Modern C++ : std::array

by Glennan Carnie

From the article:

C++98 inherited C’s only built-in container, the array. Arrays of non-class types behave in exactly the same way as they do in C. For class types, when an array is constructed the default constructor is called on each element in the array...