Так точно, проблема в инициализации параметров, где уже собственно и происходит вызов перемещающего конструктора. А само вычисление аргументов в данном случае не приводит к модификации указателя. В объяснении из статьи использована неверная терминология.
Для примера:
Аргумент (std::move(context), std::make_unique()) будет вычислен, но неопределенного поведения в context->task_runner() не будет, т.к. перемещеия в данном случае не будет.
По первому примеру не могу согласиться: не имеет значения в каком порядке будет «вычислен» std::move, он никак не модифицирует передаваемый аргумент, т.к. производится лишь преобразование типа ссылки — в стандарте указано (20.2.5):
Не нравится мне этот подход с индексированием базовых типов и побочным эффектом у оператора приведения типа. Можно сделать перечисление базовых типов в виде SFINAE специализации шаблона. Например:
Код
#include <iostream>
#include <tuple>
#include <typeinfo>
#include <utility>
namespace reflect {
namespace detail {
template <size_t>
struct ubiq {
template <class T>
constexpr operator T&() const;
};
template <class T>
struct exact {
constexpr operator T&() const;
};
template <class>
using void_t = void;
template <class T, size_t N = sizeof( T ), class S = std::make_index_sequence<N>, class = void>
struct tuple_size_helper : tuple_size_helper<T, N - 1, std::make_index_sequence<N - 1>> {
};
template <class T, size_t N, size_t... I>
struct tuple_size_helper<T, N, std::index_sequence<I...>, void_t<decltype( T{ubiq<I>{}...} )>> {
using type = std::integral_constant<size_t, N>;
};
} // namespace detail
template <class T>
using tuple_size = typename detail::tuple_size_helper<T>::type;
namespace detail {
template <size_t N, class T, class = std::make_index_sequence<N>, class = std::make_index_sequence<tuple_size<T>::value - N - 1>,
class = void>
struct tuple_element_helper;
template <size_t N, class T, size_t... I, size_t... J>
struct tuple_element_helper<N, T, std::index_sequence<I...>, std::index_sequence<J...>,
void_t<decltype( T{ubiq<I>{}..., exact<int>{}, ubiq<J>{}...} )>> {
using type = int;
};
template <size_t N, class T, size_t... I, size_t... J>
struct tuple_element_helper<N, T, std::index_sequence<I...>, std::index_sequence<J...>,
void_t<decltype( T{ubiq<I>{}..., exact<size_t>{}, ubiq<J>{}...} )>> {
using type = size_t;
};
template <size_t N, class T, size_t... I, size_t... J>
struct tuple_element_helper<N, T, std::index_sequence<I...>, std::index_sequence<J...>,
void_t<decltype( T{ubiq<I>{}..., exact<std::string>{}, ubiq<J>{}...} )>> {
using type = std::string;
};
} // namespace detail
template <size_t N, class T>
struct tuple_element {
using type = typename detail::tuple_element_helper<N, T>::type;
};
template <size_t N, class T>
using tuple_element_t = typename tuple_element<N, T>::type;
namespace detail {
template <class T, class = std::make_index_sequence<tuple_size<T>::value>>
struct as_tuple_helper;
template <class T, size_t... I>
struct as_tuple_helper<T, std::index_sequence<I...>> {
using type = std::tuple<tuple_element_t<I, T>...>;
};
} // namespace detail
template <class T>
using as_tuple_t = typename detail::as_tuple_helper<T>::type;
} // namespace reflect
struct s {
int a;
size_t b;
int x;
std::string q;
};
int main()
{
std::cout << reflect::tuple_size<s>() << std::endl;
std::cout << typeid( reflect::tuple_element_t<0, s> ).name() << std::endl;
std::cout << typeid( reflect::tuple_element_t<1, s> ).name() << std::endl;
std::cout << typeid( reflect::tuple_element_t<2, s> ).name() << std::endl;
std::cout << typeid( reflect::tuple_element_t<3, s> ).name() << std::endl;
std::cout << typeid( reflect::as_tuple_t<s> ).name() << std::endl;
}
Сигналы теряются, т.к. при эмиссии нескольких сигналов до вызова метода dbms_alert.waitone, он возвращает только последний. Т.е. если между вызовами waitone было более одного сигнала остальные будут потеряны.
Ну и подписываться/отписываться (dbms_alert.register/remove) на сигнал внутри процедуры не имеет смысла.
Для себя нашел, что использовать template template для передачи метафункций не удобно, как минимум возникают проблемы с возвратом функций из функций. Вместо этого я в явном виде объявляю метафункцию аппликации:
struct And {
template <class X, class... Y>
struct call;
};
template <class X>
struct And::call<X> {
using value = X;
};
template <class X, class... Y>
struct And::call<Zero, X, Y...> {
using value = Zero;
};
template <class X, class... Y>
struct And::call<One, X, Y...> {
using value = apply<And, X, Y...>;
};
Таким образом сами функции более не являются шаблоном от параметров, и ими можно оперировать как другими объектами — положить в список, вернуть в виде результата другой функции и т.п.
Но это всё выглядит страшновато и плохо пахнет. Можем ли мы лучше?
Возможно, в рамках C++14 и можем, но я не придумал, как, а скорее нашёл доказательство, что этого сделать нельзя, но поля этой статьи слишком узки для него.
Мне тоже, но я еще не придумал как его можно использовать.
Забавно, что схожее предложение на днях было опубликовано в рамках WG21.
С другой стороны данная статья может быть использована как наглядный пример для дальнейшего устранения недостатков лямбд (variadic move-capture, const mutable lambda call, rvalue lambda и т.д.)
Для примера:
Аргумент (std::move(context), std::make_unique()) будет вычислен, но неопределенного поведения в context->task_runner() не будет, т.к. перемещеия в данном случае не будет.
Ну и подписываться/отписываться (dbms_alert.register/remove) на сигнал внутри процедуры не имеет смысла.
Которые можно применять на месте:
Польный пример
А далее все функции имеют вложенный шаблон call:
Таким образом сами функции более не являются шаблоном от параметров, и ими можно оперировать как другими объектами — положить в список, вернуть в виде результата другой функции и т.п.
Можем, если вынести враппер на уровень выше:
Забавно, что схожее предложение на днях было опубликовано в рамках WG21.
С другой стороны данная статья может быть использована как наглядный пример для дальнейшего устранения недостатков лямбд (variadic move-capture, const mutable lambda call, rvalue lambda и т.д.)