Home » Blog » Tags » intermediate

intermediate

CppCon 2016: Leak-Freedom in C++... By Default--Herb Sutter

By Adrien Hamelin | May 15, 2017 08:00 AM | Tags: intermediate community

Have you registered for CppCon 2017 in September? Don’t delay – Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2016 for you to enjoy. Here is today’s feature:

Leak-Freedom in C++... By Default

by Herb Sutter

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Lifetime safety means writing code that, by construction, is guaranteed to eliminate two things: (a) use of null/dangling pointers (including pointerlike things such as references, iterators, views, and ranges), and (b) leaks (including the rare 1% case where we’re tempted to admit the possibility of an ownership cycle or need to support lock-free concurrent data structures).

Last year, my CppCon 2015 talk “Writing Good C++14… By Default” focused on (a), null/dangling, because it's the more difficult and usually more serious problem. I gave an overview of a new approach of using static analysis rules to eliminate use of null and dangling in C++. That work continues and we’re in the process of writing down the formal rules for the approach that I showed last year.

This year, the focus will be on (b), leaks: The talk aims to begin with a set of simple rules, the “5-minute talk” to demonstrate that a handful of rules can be taught broadly to programmers of all levels, and results in code that is clean and free of leak bugs by construction.

But, since we’ll still have 85 minutes left, we can use the time to spelunk through a series of “Appendix” code examples, in which we'll demonstrate "why and how" to apply those rules to a series of increasingly complex/difficult situations, and that are aimed at increasingly advanced and “clever” (note: not always a good thing) programs and programmers. We’ll address questions such as: How should we represent Pimpl types? How should we represent trees – what should the child and parent pointer types be, and (when) should they be unique and when shared? How should we deal with “intra-module” or “encapsulated” cycles when you control all the objects in the cycle, such as all the nodes within a Graph? And what about “inter-module” or “compositional” cycles when you don’t know in advance about all the objects that could be in the cycle, such as when combining libraries written by different people in a way that may or may not respect proper layering (notoriously, using callbacks can violate layering)? The answers focus on cases where we have solid guidance, and then move toward some more experimental approaches for potentially addressing the ~1% of cases that aren’t yet well covered by unique_ptr, shared_ptr, and weak_ptr.

Quick Q: When should you ever use functions over functors in C++?

By Adrien Hamelin | May 4, 2017 01:21 PM | Tags: intermediate

Quick A: They behave differently, it depends on what you need.

Recently on SO:

When should you ever use functions over functors in C++?

Functions support distributed overriding. Functors do not. You must define all of the overloads of a Functor within itself; you can add new overloads of a function anywhere.

Functions support ADL (argument dependent lookup), permitting overloading in the argument-type associated namespace. Functors do not.

Function pointers are a kind of type-erased stateless functor that is a POD, as evidenced by how stateless lambdas convert into it. Such features (POD, stateless, type erasure) are useful.

Understand ranges better with the new Cartesian Product adaptor--Jonathan Boccara

By Adrien Hamelin | Apr 18, 2017 01:17 PM | Tags: intermediate experimental

The future explained:

Understand ranges better with the new Cartesian Product adaptor

by Jonathan Boccara

From the article:

A couple of days ago, the range-v3 library got a new component: the view::cartesian_product adaptor.

Understanding what this component does, and the thought process that went through its creation is easy and will let you have a better grasp of the range library. (Note that you could just as well understand all the following by looking at the zip adaptor. But cartesian_product is brand new, so let’s discover this one, in order to hit two birds with one stone)...

Quick Q: Prevent user from derive from incorrect CRTP base

By Adrien Hamelin | Apr 5, 2017 02:15 PM | Tags: intermediate

Quick A: Make it impossible to construct a class of the wrong type.

Recently on SO:

Prevent user from derive from incorrect CRTP base

1) make all constructors of Base private (if there are no constructors, add one)

2) declare Derived template parameter as friend of Base

template <class Derived>
class Base
{
private:

  Base(){}; // prevent undesirable inheritance making ctor private
  friend  Derived; // allow inheritance for Derived

public :

  void call ()
  {
      static_cast<Derived *>(this)->call_impl();
  }
};

After this it would be impossible to create any instances of the wrong inherited D2.

Quick Q: Conditionally acquire an std::mutex

By Adrien Hamelin | Apr 3, 2017 01:42 PM | Tags: intermediate c++11

Quick A: use a std::unique_lock with std::try_to_lock parameter in the constructor.

Recently on SO:

Conditionally acquire an std::mutex

It is actually unsafe to have a unique_lock accessible from multiple threads at the same time. I'm not familiar with the opencv portion of your question, so this answer is focused on the mutex/lock usage.

static std::mutex s_FAST_GPU_mutex;
{
   // Create a unique lock, attempting to acquire
   std::unique_lock<std::mutex> guard(s_FAST_GPU_mutex, std::try_to_lock);
   if (guard.owns_lock())
   {
       cv::gpu::FAST_GPU(/*params*/)(/*parameters*/);
       guard.unlock(); // Or just let it go out of scope later
   }
   else
   {
       cv::FAST(/*parameters*/);
   }
}

This attempts to acquire the lock, if it succeeds, uses FAST_GPU, and then releases the lock. If the lock was already acquired, then goes down the second branch, invoking FAST

Smelly std::pair and std::tuple--Arne Mertz

By Adrien Hamelin | Apr 3, 2017 01:36 PM | Tags: intermediate c++11

Do you use them badly?

Smelly std::pair and std::tuple

by Arne Mertz

From the article:

Depending on their use, std::pair and std::tuple can be code smells. That’s why we should be careful around these two.

Having a code smell is not a no-go, it’s more like a red flag. It’s one of those things that are not a problem themselves but rather a hint that there might be a less obvious problem hidden in the code.