September 13-19, Aurora, CO, USA
October 25, Pavia, Italy
November 6-8, Berlin, Germany
November 3-8, Kona, HI, USA
By Meeting C++ | Oct 31, 2015 08:28 AM | Tags: intermediate c++11 advanced
Happy Halloween!
C++ and Zombies: A moving question
by Jens Weller
From the article:
And that there are two fractions, one of them stating, that it is ok to have well defined zombies, while some people think that you'd better kill them...
By Mantosh Kumar | Oct 29, 2015 01:16 AM | Tags: performance efficiency
Discussion regarding systematic approach to go about optimization of logic.
Random Acts of Optimization
by Tony Albrecht
From the article:
The three stages mentioned here, while seemingly obvious, are all too often overlooked when programmers seek to optimize. Just to reiterate:1. Identification: profile the application and identify the worst performing parts.
The solution above is not the fastest possible version, but it is a step in the right direction—the safest path to performance gains is via iterative improvements.
2. Comprehension: understand what the code is trying to achieve and why it is slow.
3. Iteration: change the code based on step 2 and then re-profile. Repeat until fast enough.
By Adrien Hamelin | Oct 27, 2015 09:35 AM | Tags: intermediate c++14
Variadics are even more easy to use than we tought:
Using Variadic Templates cleanly
by Florian Weber
From the article:
When one comes across examples for variadic templates, almost always recursion is used to achieve almost everything, for example like this:
// We are lucky: the author correctly used zero // arguments instead of one as the base-case, // thereby avoiding code-duplication: inline void print_to_stream(std::ostream&) {} template<typename Head, typename...Tail> void print_to_stream(std::ostream& stream, const Head& h, const Tail&... t) { stream << h; print_to_stream(stream, t...); }In this article we will see what better alternatives for this rather clumsy hack exist and see how we can write a better version with less code...
By Blog Staff | Oct 25, 2015 02:33 PM | Tags: None
Another hour, another trip report from the just-concluded ISO C++ meeting:
Trip report: Fall 2015 ISO C++ standards meeting
by Herb Sutter
See also STL's trip report. The above one goes into more detail on some of the bigger proposals making their way through the standardization process.
By Blog Staff | Oct 25, 2015 01:18 PM | Tags: None
The fall ISO C++ standards meeting concluded less than 24 hours ago, and our own STL (the person, not the library) has posted the first trip report to Reddit. It was a very successful meeting with considerable progress.
C++17 Progress Update! (Oct 2015)
by Stephan T. Lavavej (aka STL)
Note that this report is focused on an overview of what reached full committee approval, with an emphasis on library features. Important milestones were also achieved to progress other major topics, including modules, contracts, and variant that we hope will reach formal full committee approval at the next meeting or two, and these topics will no doubt be covered in other people's trip reports and commentaries as well.
By Adrien Hamelin | Oct 23, 2015 02:34 PM | Tags: intermediate c++11
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...
By Niks | Oct 22, 2015 11:00 PM | Tags: c++14
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 ...
By Adrien Hamelin | Oct 22, 2015 01:51 PM | Tags: intermediate
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::dequeis 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::vectoris not stable, andstd::list,std::forward_listas 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 (likestd::vector), but with it the stability problem
boost::stable_vectoroffers 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.
By Adrien Hamelin | Oct 22, 2015 01:43 PM | Tags: c++11 basics
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...
By Adrien Hamelin | Oct 20, 2015 12:26 PM | Tags: performance advanced
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...