Quick Q: std::move with std::shared_ptr in lambda

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::move cannot 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 {

Quick Q: Are the experimental features of modern C++ reliable for long-term projects?

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

Disabling narrowing conversions in signal/slot connections--Giuseppe D'Angelo

A new useful feature in Qt:

Disabling narrowing conversions in signal/slot connections

by Giuseppe D'Angelo

From the article:

A small new feature that I have added to Qt 5.8 is the possibility of disabling narrowing conversions in the new-style QObject::connect statement. In this short blog post I would like to share with you why I thought this was useful and therefore implemented it...

C++ Debugging and Diagnostics--Adam Welch

A quick tour of the Visual Studio native debugger and how it can help you in all areas of your C++ development:

C++ Debugging and Diagnostics

by Adam Welch

From the article:

Debugging is one of the cornerstones of software development, and it can consume a significant portion of a developer’s day.  The Visual Studio native debugger provides a powerful and feature-rich experience for finding and fixing problems that arise in your applications...

CppCast Episode 96: Jewelbots with Sara Chipps

Episode 96 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Sara Chipps to discuss Jewelbots, Arduino and getting girls interested in STEM fields.

CppCast Episode 96: Jewelbots with Sara Chipps

by Rob Irving and Jason Turner

About the interviewee:

Sara Chipps is a JavaScript developer based in NYC. She has been working on Software and the Open Source Community since 2001. She’s been obsessed with hardware and part of Nodebots since 2012.

She is the CEO of Jewelbots, a company dedicated towards drastically changing the number of girls entering STEM fields using hardware.

She was formerly the CTO of Flat Iron School, a school dedicated to teaching people of all ages how to build software and launch careers as software developers.

In 2010 she cofounded Girl Develop It, a non-profit focused on helping more women become software developers. Girl Develop It is in 45 cities, and has taught over 17,000 women how to build software.

Post-Conditions on Self-Move--Eric Niebler

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.

Quick Q: Prevent user from derive from incorrect CRTP base

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

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

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.