Я реализую свой собственный signal
/slot (шаблон наблюдателя, стиль Qt), поэтому у меня может быть property
, который уведомляет ... материал ... который был изменен.Реализация сигналов (шаблон наблюдателя): возможно изменение или const_cast?
Я думаю, что C++ 11 обеспечивает все необходимое, чтобы сделать очень сукцину и возможность использования. «Проблема», с которой я столкнулся, - это если я хочу «подключиться» к сигналу объекта const
, мне нужно, чтобы функция signal::connect
была константой, но изменила список обратных вызовов/наблюдателей. Есть два способа прямолинейные, чтобы исправить это:
const_cast
списки внутриconnect
.- Составьте список
mutable
.
И мне кажется, как одно и то же (и это было предложено ранее, например в this question), и прекрасно логически, но стилистически сомнительна. Отсюда вопрос. Есть ли способ обойти это или это действительно оправданное использование const_cast
/mutable
?
Некоторые prelimenary код, как я сейчас:
template<typename... ArgTypes>
class signal
{
public:
template<typename Callable>
void connect(Callable&& callback) const
{
std::lock_guard<std::mutex> lock(slots_mutex);
slots.emplace_back(callback);
}
void emit(ArgTypes... arguments) const
{
std::lock_guard<std::mutex> lock(slots_mutex);
for(auto&& callback : slots)
{
callback(arguments...);
}
}
private:
// mutable here allows to connect to a const object's signals
mutable std::vector<std::function<void(ArgTypes...)>> slots;
std::mutex slots_mutex;
};
Примечание Я не проверял этот код; это всего лишь отражение моего нынешнего состояния ума.
Неисследованный код ... tsk tsk ... –
@Arnav Я буквально пишу тесты сейчас, мне просто нужно было снять эту проблему с дизайном: p. – rubenvb
Боюсь, я не понимаю, почему сам 'signal' должен выставлять методы' const'. Почему бы не позволить пользователю «сигнала» решить, хотят ли они его изменять (или нет)? –