«Хорошее решение» демонстрирует код таким, каким он должен быть, если бы он изначально писался на С++, и писался хорошо.
Вы сравниваете «специализацию» с наследованием, и в «хорошем решении» с перегрузкой функций. Дело не в том, как должно быть «хорошо», а в том, что вы сравниваете разные вещи.
Это сработает только для очень простых примеров, для любой сложной реализации типажей у вас не получится провернуть подобный трюк.
Подобные утверждения требуют какого-то подтверждения. Можете привести пример?
Заметил интересную тенденцию, почти все, кто сравнивает реализацию на каком-либо языке с реализацией на C++, приводят либо заведомо усложненную, либо вообще не имеющую ничего общего с реализацией на сравниваемом языке, реализацию на C++. С какой целью это делается остается только гадать. Корректная калька первого примера на C++ должна выглядеть как-то так:
#include <iostream>
template <class T>
struct Display;
struct Foo {
int x;
};
template <>
struct Display<Foo> {
static auto& fmt( const Foo& self, std::ostream& os )
{
return os << "(x: " << self.x << ")";
}
};
struct Bar {
int x;
int y;
};
template <>
struct Display<Bar> {
static auto& fmt( const Bar& self, std::ostream& os )
{
return os << "(x: " << self.x << ", y: " << self.y << ")";
}
};
template <class T>
void print_me( const T& obj )
{
Display<T>::fmt( obj, std::cout ) << std::endl;
};
int main()
{
auto foo = Foo{7};
auto bar = Bar{5, 10};
print_me( foo );
print_me( bar );
}
Является эквивалентом приведения только для простых типов.
Но соглашусь, статья является не полной без описания явных и неявных приведений типов в конструкторах и вызовах функций, из чего и следует данный вариант приведения.
Как раз об этом подумал, но вы меня обогнали. Еще нужно поправить и в конструкторе. Но обычный std::remove_reference_t не подойдет, тогда не получится использовать простые функции. Напишем свой:
Спецификатор register уже давно как deprecated. И в целом в рассматриваемом примере нет ничего, что касалось бы оптимизации. Выравнивание может незначительно повлиять на std::sort, а для рассматриваемого алгоритма оно не имеет значения. Список инициализации в принципе не является оптимизацией (наоборот, не использование списков инициализации можно считать дурным тоном), к тому же никаким образом не влияет на рассматриваемый алгоритм.
Как это выглядит для индивидуального пользователя:
Покупка PVS-Studio лично для себя практически нереальна. И даже CppCat все равно слишком дорог.
Как это выглядит для корпоративного пользователя:
Зачем покупать CppCat — заведомо ущербный аналог PVS-Studio. Даже если на самом деле это не так, разница в цене создает реальное психологическое давление.
В вашем примере происходит лишнее выделение памяти под хендл.
Именно поэтому unique_ptr и не является хорошим инструментом для реализации scope_guard.
При освобождении ресурса функция CloseHandle может бросить исключение и память, выделенная под хендл, не будет освобождена.
Тут у нас есть несколько решений — потребовать условия noexcept(CloseHandle(*h)), просто проигнорировать исключение посредством try-catch, или передать это исключение для дальнейшей обработки:
Все так. Спекуляция в том, что проблемы с использованием std::unique_ptr не по назначению выставляются как его недостатки. Очевидно, что unique_ptr не является панацеей, а unique_resource востребован.
Можно будет писать так:
Вы сравниваете «специализацию» с наследованием, и в «хорошем решении» с перегрузкой функций. Дело не в том, как должно быть «хорошо», а в том, что вы сравниваете разные вещи.
Подобные утверждения требуют какого-то подтверждения. Можете привести пример?
Это неправда. Для вашего примера, решенного в лоб:
компилятор с вектороной оптимизацией (напр. g++ -O3) сгенерирует следующий код для цикла:
Но соглашусь, статья является не полной без описания явных и неявных приведений типов в конструкторах и вызовах функций, из чего и следует данный вариант приведения.
Покупка PVS-Studio лично для себя практически нереальна. И даже CppCat все равно слишком дорог.
Как это выглядит для корпоративного пользователя:
Зачем покупать CppCat — заведомо ущербный аналог PVS-Studio. Даже если на самом деле это не так, разница в цене создает реальное психологическое давление.
Именно поэтому unique_ptr и не является хорошим инструментом для реализации scope_guard.
Тут у нас есть несколько решений — потребовать условия noexcept(CloseHandle(*h)), просто проигнорировать исключение посредством try-catch, или передать это исключение для дальнейшей обработки:
Что, впрочем, не является лучшей идеей, учитывая, что deleter будет вызван в деструкторе unique_ptr.