New updates of CppHints.com, service of recommendations on C++ programming from PVS-Studio team

By Andrey Karpov | Nov 2, 2015 06:03 AM | Tags: intermediate errors bugs basics

New updates of C++Hints, service of recommendations on C++ programming

Changes in CppHints.com

by PVS-Studio Team

We got a lot of positive feedback from our readers and continue developing the C++Hints project. We have also answered two requests, that we saw quite often in the letters:

• The RSS feed is added (http://cpphints.com/rss)
• The up-to-date full list of hints is created at: http://cpphints.com/archive

By this moment we have published the following articles:

• Why incorrect code works
• Don't forget that the loop termination conditions are always evaluated completely
• Undefined behavior is closer than you think
• Visual C++ and wprintf() function
• Use a prefix increment operator (++i) in iterators instead of a postfix (i++) operator
• Avoid using a macro if you can use a simple function
• Don't name functions "empty"
• Hot on the heels
• Make your code more stable
• Insidious VARIANT_BOOL
• Do not compare 'this' to nullptr anymore
• Use the keyword "override" when overriding virtual functions
• Evaluate the string literal length automatically
• Do not use #pragma warning(default:X)
• Table-style formatting (continuation)
• Make sure you work with data in streams the right way
• Delegating constructors make life easier
• Use dedicated functions to clear private data
• Table-style formatting
• Don't spare code lines
• Start using enum class in your code, if possible
• A good compiler and coding style aren't always enough
• When using Copy-Paste, be especially careful with the last lines
• Don't try to squeeze as many operations as possible in one line
• Use the '\0' literal for the terminal null character
• Avoid using multiple small #ifdef blocks
• Beware of throwing exceptions in destructors
• Check all the fragments where a pointer is explicitly cast to integer types
• Do not call the alloca() function inside loops
• Don't Do the Compiler's Job
• Use available tools to analyze your code
• Larger than 0 does not mean 1
• Copy once, check thrice
• Beware of the ?: operator and enclose it in parentheses

An introduction to C++'s SFINAE concept -- Jean Guegant

By Felix Petriconi | Nov 2, 2015 12:49 AM | Tags: c++14 c++11 advanced

Jean Guegant describes in a very detailed way different implementation stategies of compile-time introspection of a class member for C++98, C++11 and C++14.

An introduction to C++'s SFINAE concept: compile-time introspection of a class member

by Jean Guegant

From the article:

As a C++ enthusiast, I usually follow the annual C++ conference cppconf or at least try to keep myself up-to-date with the major events that happen there. One way to catch up, if you can't afford a plane ticket or the ticket, is to follow the youtube channel dedicated to this conference. This year, I was impressed by Louis Dionne talk entitled "C++ Metaprogramming: A Paradigm Shift". One feature called is_valid that can be found in Louis's Boost.Hana library particulary caught my attention. This genious is_valid function heavily rely on an even more "magic" C++ programming technique coined with the term SFINAE discovered at the end of the previous century. If this acronym doesn't speak to you, don't be scared, we are going to dive straight in the subject.

Happy Halloween: C++ and zombies

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

Random Acts of Optimization --Tony Albrecht

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

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.

Using Variadic Templates cleanly--Florian Weber

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

Trip report: C++ standards meeting in Kona, October 2015 -- Herb Sutter

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.

Trip report: C++ standards meeting in Kona, October 2015 -- Stephan T. Lavavej

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.

More than you need--Andrzej Krzemieński

By Adrien Hamelin | Oct 23, 2015 02:34 PM | Tags: intermediate c++11

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

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

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

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