advanced

Quick Q: How can a class template store either reference or value?

Quick A: This happen by default.

Recently on SO:

How can a class template store either reference or value?

You already wrote it (minus the required template <typename T>). The deduction rules for a forwarding reference preserve value category as follows:

  1. If t is bound to an lvalue of type T2, then T = T2&.
  2. If t is bound to an rvalue of type T2, then T = T2.

It's those deduction rules that std::forward relies on to do its job. And why we need to pass the type to it as well.

The above means that you instantiate holder directly with T2 in the rvalue case. Giving you exactly what you want. A copy is made.

As a matter of fact, two copies are made. Once to create the constructor argument t, and the other copy is to initialize obj_m from it. But we can get rid of it with some clever use of type_traits:

template <class T>
class holder {
    T  obj_m;  // should be a reference if possible...
public:
    holder(std::add_rvalue_reference_t<T> t) :obj_m { std::forward<T>(t) } {}
};

template<typename T>
auto hold_this(T && t) { return holder<T>(std::forward<T>(t)); }

See it live. We use add_rvalue_reference_t to make t be of the correct reference type in each case. And "simulate" the argument deduction which would make obj_m { std::forward<T>(t) } resolve to initializing obj_m from the correct reference type.

I say "simulate" because it's important to understand the constructor argument for holder cannot be a forwarding reference because the constructor itself is not templated.

By the way, since you tagged c++17, we can also add a deduction guide to your example. If we define it as follows (with the feedback from T.C. incorporated):

template <class T>
class holder {
    T  obj_m;  // should be a reference if possible...
public:
    holder(T&& t) :obj_m { std::forward<T>(t) } {}
};

template<typename T>
holder(T&&) -> holder<T>;

Then this live example shows you can define variables as hold h1{t}; and hold h2{test()};, with the same deduced types as the function return values from before.

Quick Q: Most concise way to disable copy and move semantics

Quick A: Delete the move assignment.

Recently on SO:

Most concise way to disable copy and move semantics

According to this chart (by Howard Hinnant):

The most concise way is to =delete move assignment operator (or move constructor, but it can cause problems mentioned in comments).

Though, in my opinion the most readable way is to =delete both copy constructor and copy assignment operator.

The Most Vexing Parse: How to Spot It and Fix It Quickly—Jonathan Boccara

Did you have that problem?

The Most Vexing Parse: How to Spot It and Fix It Quickly

by Jonathan Boccara

From the article:

Everyone has their little defaults. You know, that little something that they do from time to time and that gets on your nerves, even though they’re otherwise nice people?

For C++, one of these little annoyances is the most vexing parse, well, as its name suggests...

C++ Comma Operator—Ivan Sanz

It needs to be used carefully, but has its uses.

C++ Comma Operator

by Ivan Sanz

From the article:

Comma operator has been with us for a long time. First seen in C spec and improved with custom overloads in C++, it quickly became one of those hidden things you shouldn’t use.
Most C/C++ books avoid speaking about goto the same way they do about comma operator. This is not fair, as both of them can be used properly on certain cases. Let’s speak about that...