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.

Making things do stuff – Part 1--Glennan Carnie

By Adrien Hamelin | Apr 3, 2017 01:29 PM | Tags: community advanced

C++ for embedded too!

Making things do stuff – Part 1

by Glennan Carnie

From the article:

C has long been the language of choice for smaller, microcontroller-based embedded systems; particularly for close-to-the-metal hardware manipulation.

C++ was originally conceived with a bias towards systems programming; performance and efficiency being key design highlights.  Traditionally, many of the advancements in compiler technology, optimisation, etc., had centred around generating code for PC-like platforms (Linux, Windows, etc).  In the last few years C++ compiler support for microcontroller targets has advanced dramatically, to the point where Modern C++ is a increasingly attractive language for embedded systems development...

C++ User Group Meetings in April

By Meeting C++ | Apr 3, 2017 06:09 AM | Tags: community

The monthly overview of upcoming C++ User Group Meetings

C++ User Group Meetings in April 2017

by Jens Weller

From the article:

So far there are already 36 Meetings announced! There are 2 new C++ User Groups: Minneapolis, Stockholm (LLVM).

Variadic CRTP -- Steve Dewhurst

By Jon Kalb | Mar 29, 2017 10:40 AM | Tags: variadic templates crtp advanced

Steve Dewhurst has published a new paper under his category Once Weakly:

Variadic CRTP

by Steve Dewhurst

From article:

One problem with [the] traditional application of CRTP is that it’s inflexible....  We can get [more] flexibility by specifying the CRTP capability as a template template parameter.

Trip report: Winter ISO C++ standards meeting (Kona) -- Botond Ballo

By Blog Staff | Mar 27, 2017 07:17 PM | Tags: None

A new trip report from the just-concluded ISO C++ meeting:

Trip report: C++ standards meeting in Kona, February 2017

by Botond Ballo

From the article:

Conclusion

C++17 is effectively out the door, with its Draft International Standard sent out for ballot, and the official release expected later this year.

Development on C++20 is well under way, with numerous core language and library features already earmarked for it, and several Technical Specifications expected to be merged into it. A proposal for an overall vision for the release aims to focus the committee’s efforts on four headliner features – Concepts, Modules, Ranges, and Networking. That is, of course, not a guarantee these features will be in C++20 (nor is it intended to exclude other features!), but I believe with some luck and continued hard work we can make part of all of that plan a reality.

Modules, in particular, are expected to be a game-changer for C++...

Trip report: Winter ISO C++ standards meeting (Kona) -- Herb Sutter

By Blog Staff | Mar 24, 2017 05:03 PM | Tags: None

A trip report from the just-concluded ISO C++ meeting:

Trip report: Winter ISO C++ standards meeting (Kona), C++17 is complete

by Herb Sutter

From the article:

C++17 is done!

The big news is that we completed C++17, which dominated the work of the meeting: C++17 is now technically finished and being sent out for its final ISO balloting. All that remains for C++17 now is some ISO red tape and minor touch-up to get it officially published, which is expected to be just mechanical...

Constexpr Additions in C++17--Arne Mertz

By Adrien Hamelin | Mar 20, 2017 01:11 PM | Tags: intermediate experimental

constexpr evolves!

Constexpr Additions in C++17

by Arne Mertz

From the article:

Last year, I have written about constexpr and compile time constants in general. Last week, the Draft International Standard for C++17 has been sent to its ballot. Time to provide some updates to earlier posts!

Does const mean thread-safe?--Anthony Williams

By Adrien Hamelin | Mar 20, 2017 01:06 PM | Tags: intermediate

What do you think?

Does const mean thread-safe?

by Anthony Williams

From the article:

There was a discussion recently on the cpplang slack about whether const meant thread-safe.

As with everything in life, it depends. In some ways, yes it does. In others, it does not. Read on for the details.

Singleton revisited--Giuseppe Puoti

By Marco Arena | Mar 20, 2017 02:02 AM | Tags: intermediate

The use of Singleton is often justified by the will of being able to easily refer to a unique object from any point. Giuseppe Puoti describes an alternative:

Singleton revisited

by Giuseppe Puoti

From the article:

It happens quite often to deal with those annoying objects, used everywhere in your applications. This may be because of a poorly designed application but, sometime, it is simply an inevitable condition...