C++11 reentrant class locking strategy

Question

I have an interface using the pimpl idiom, however the interface needs to be reentrant. Calling threads do not need to be aware of the locking, however. This is

Answer 1

For question 1, one thing I'd be tempted to do is use SFINAE to restrict the lock types passed in as LockType allowed to shared_lock_t or unique_lock_t.

Ie:

template <typename LockType>
typename std::enable_if<
  std::is_same< LockType, shared_lock_t > || std::is_same< LockType, unique_lock_t >,
  size_t
>::type 
bar_capacity(LockType& lk) const;

... but that does get a bit verbose.

which means that passing in the wrong type of Lock gives you a "nothing matches" error. Another approach would be to have two different bar_capacity that take shared_lock_t and unique_lock_t exposed, and a private bar_capacity that they that takes a template LockType.

As written, any type with a .owns_lock() method that returns a type convertible to bool is a valid argument there...

Answer 2

Using a Pimpl idiom, the mutex should be part of the implementation. This will let you to master when the lock is started.

BTW, why using a unique_lock when a lock_guard will be enough?

I don't see any advantage to make impl public.

std::unique_ptr should be as efficient as a pointer for most of the moderns compilers. Not verified however.

I would forward the const char[N] foo_set not as

  template<std::size_t N>
  bool foo_set(const char (&new_val)[N]) { return foo_set(std::string(new_val, N)); }

but like

  template<std::size_t N>
  bool foo_set(const char (&new_val)[N]) { return foo_set(N, new_val); }

This avoids the string creation on the header file and let the implementation do whatever is needed.