June 16-21, Sofia, Bulgaria
September 13-19, Aurora, CO, USA
October 25, Pavia, Italy
November 6-8, Berlin, Germany
November 16-21, Kona, HI, USA
By Jonas Devlieghere | Apr 19, 2017 12:04 AM | Tags: c++11 basics
Storing unique pointers in containers is great, but how do you design an API around it?
Exposing Containers of Unique Pointers
by Jonas Devlieghere
From the article:
There's probably no reason to expose to the caller that objects are stored as unique pointers.
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)...
By Adrien Hamelin | Apr 18, 2017 12:52 PM | Tags: experimental advanced
What's the status of reflection in C++?
An Introduction to Reflection in C++
by Jackie Kay
From the article:
Stop me if you’ve heard this one before. You are working on a messaging middleware, a game engine, a UI library, or any other large software project that has to deal with an ever-growing, ever-changing number of objects. These objects have many different qualities but can be grouped by their functionality: they can be sent across the network or collided with or rendered.
Because you are a good programmer who believes in the DRY principle, you want to write the “action” code that does the stuff on these objects without repetition, and plug in specific Message types or Renderable types into your generic pipeline at the appropriate places. It would be really nice to compose objects hierarchally: for example, if I had a widget class composed of several different renderable Rectangles, I want to be able to automatically generate the rendering code for my widget based on the existing rendering logic for its constituent shapes...
By Adrien Hamelin | Apr 18, 2017 12:46 PM | Tags: c++11 advanced
Some thoughts about final classes.
Final Classes
by Arne Mertz
From the article:
A few days ago, a colleague asked me if it was wise to make every class a final class. Here is a more sophisticated answer than I could give at that time...
By Adrien Hamelin | Apr 14, 2017 01:07 AM | Tags: None
Quick A: Lambda captures are const by default, and it is not possible to move a const.
Recently on SO:
std::move with std::shared_ptr in lambda
The captured variable ptr in a lambda is by default const, i.e. the type of ptr is
const std::shared_ptr<int>.
std::movecannot move out const objects, so a copy is created instead.If you really want to move it, the ptr must be allowed to be mutable:
auto lambda = [ptr]() mutable {
By Adrien Hamelin | Apr 14, 2017 01:03 AM | Tags: community basics
Quick A: No
Recently on SO:
Are the experimental features of modern C++ reliable for long-term projects?
Is it guaranteed that all compliant compilers have the same experimental features?No, experimental features are optional.Are experimental features prone to big changes that make them unreliable?Yes, the C++ committee might even decide to abandon a feature or in the process of standardization a defect might come up that would force a feature to change.Generally, it's not a good idea to depend on experimental features. Experimental features are exactly what the word says (i.e., to experiment with).
By Adrien Hamelin | Apr 5, 2017 02:24 PM | Tags: c++11 advanced
An issue we do not think often about:
Post-Conditions on Self-Move
by Eric Niebler
From the article:
TL;DR: In addition to the usual rule about move operations leaving the source object in a valid but unspecified state, we can add an additional guideline (not quite a rule, but follow it anyway):
Self-move assignment should “work” and leave the object in a valid but unspecified state.
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.
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
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::pairandstd::tuplecan 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.