Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / c++ реализуема такая конструкция?

c++ реализуема такая конструкция?

Поделиться

Страницы: 1 2 Следующая

FuntikПостоялецwww28 окт. 201712:01#0
Всем привет!
Поясню суть проблемы... Мне показалось удобным упаковывать WinAPI переменные используя std::shared_ptr, например:
поля класса можно записать таким образом:
std::shared_ptr<std::remove_pointer<HWND>::type> hWnd;
std::shared_ptr<std::remove_pointer<HDC>::type> hDC;
std::shared_ptr<std::remove_pointer<HGLRC>::type> hRC;
Это даёт удобное использование. Создаётся функция с её делетером, например, где то в используемой функции:
auto hwnd = CreateWindowEx(wndExStyle, wcl.lpszClassName, appTitle.c_str(), wndStyle,
  0, 0, rc.right - rc.left, rc.bottom - rc.top, nullptr, nullptr, wcl.hInstance, this);

std::shared_ptr<std::remove_pointer<HWND>::type>(hwnd, &DestroyWindow).swap(hWnd);
А вопрос заключается в том, возможно ли тоже самое или почти тоже самое провернуть с RegisterClassEx и UnregisterClass???
Не могу понять как это могло бы выглядеть...
Например, для std::shared_ptr<std::remove_pointer<HDC>::type> hDC;, я создаю отдельный класс:
class DeleterDC
{
public:
  DeleterDC(std::shared_ptr<std::remove_pointer<HWND>::type> wnd) : wnd_(wnd) {}

  void operator()(HDC dc) { ReleaseDC(wnd_.get(), dc); }
private:
  std::shared_ptr<std::remove_pointer<HWND>::type> wnd_;
};
И использую таким образом:
std::shared_ptr<std::remove_pointer<HDC>::type>(GetDC(hWnd.get()), DeleterDC(hWnd)).swap(hDC);
Очень хотелось бы так же записать RegisterClassEx.
Ghost2Постоялецwww28 окт. 201714:08#1
Funtik
struct reg_class_t
{
    reg_class_t(...)
    {
        RegisterClassEx(...);
    }

    ~reg_class_t()
    {
        UnregisterClass(...);
    }
};

А вообще, you are doing it wrong. Не нужны тут shared_ptr'ы.

xПостоялецwww28 окт. 201717:43#2
Шаблоны головного мозга.
FuntikПостоялецwww28 окт. 201719:54#3
Ghost2
Спасибо тебе за ответ!!! Очень помог!!! Сутки не спал, и голова уже отключалась...
Да. Сделал именно так. Вытащил из функции структуру WNDCLASSEX и RegisterClassEx(...) и поместил в конструктор,
а UnregisterClass(...) в деструкторе... Логично выглядит и работает на ура!
Спасибо!!!
loysoПостоялецwww29 окт. 20177:21#4
Funtik
Терминологии ради - есть такая идиома:
https://ru.wikipedia.org/wiki/Получение_ресурса_есть_инициализация
Тут главное цепочка получения знаний "не знаю как делать" -> "знаю как делать" -> "знаю как делать БЕЗ этого и правильно".
SuslikМодераторwww29 окт. 201711:49#5
Ghost2
> struct reg_class_t
а потом он ещё захочет такие хэндлы копировать, присваивать, счётчик ссылок, брать слабые указатели, и получится велосипед с огромной архитектурой рефкаунтинга на каждый такой хенл. по-моему, странно, что плюсы не предоставляют какой-нибудь intrusive_ptr по дефолту в стандартной библиотеке, чтоб каждый раз это не писать.
loysoПостоялецwww29 окт. 201711:58#6
Suslik
> intrusive_ptr по дефолту в стандартной библиотеке
RC - не серебряная пуля (к счастью). Процитирую aruslan'а:
последние 100500 раз когда я выпиливал подсчёт ссылок, это было потому что
- веерно тормозило потому что удаление одного объекта удаляло тысячи,
- веерно тормозило потому что удаление одного объекта модифицировало распиханные в тонне мест ссылки и трешило кеш,
- намертво сцепляло объекты CPU и находящиеся в полёте асинхронные объекты типа текстур на GPU итп,
- создавало изощренные графы зависимостей где никто не может сказать когда что нужно грохнуть,
- люди передавали умные указатели по значению,
- люди синхронизировались по умным указателям всегда.
наверное были ещё 100500 причин, но вот эти - главные.
(я про интерактивные среды.)

SuslikМодераторwww29 окт. 201712:10#7
loyso
я тоже вовсе не сторонник рефкаунтинга и вообще любых архитектур без явного владения ресурсами. однако, это не значит, что shared_ptr должен перестать существовать и нет случаев, когда он мог бы быть кому-то полезен. всякие джавы и сишарпы живут фактически в мире, где все указатели — shared, и ничего, это не всегда заканчивается плохо. однако, даже при реализации RAII с уникальным владельцем для каждого ресурса по типу unique_ptr, всё равно приходится писать для каждого хендла код с запретом копирования, с move-конструкторами и присваиваниями, итп. я бы хотел, чтобы заготовка такой RAII-штуки c подсчётом ссылок или с единственным владельцем была в стандарте.

Правка: 29 окт. 2017 12:10

loysoПостоялецwww29 окт. 201712:39#8
Suslik
> всё равно приходится писать для каждого хендла
handle - это weak pointer в каком-то смысле со 'static extension methods' вместо member methods.
Писать адаптеры к такому - очень специфичное занятие и обычно решается на другом уровне - либами типа WTL.

Правка: 29 окт. 2017 12:39

innuendoПостоялецwww29 окт. 201713:15#9
loyso
> RC - не серебряная пуля (к счастью). Процитирую aruslan'а:

Это чисто типа конзольный стайл ? Ничего против не имею, когда жёсткое ТЗ под конзоли.

А вот когда движок будет использован в других конторах под разные задачи... тут очень весёлый вопрос. Я вот знаю такие примеры, лично имел дело

Напомни, ты имел отношение к скриптам на perl в одном известном движке ? :):):)

Правка: 29 окт. 2017 13:24

innuendoПостоялецwww29 окт. 201713:16#10
Suslik
> однако, даже при реализации RAII с уникальным владельцем для каждого ресурса по
> типу unique_ptr, всё равно приходится писать для каждого хендла код с запретом
> копирования,


ага, не всё так просто с unique_ptr... у самого такое было

loysoПостоялецwww29 окт. 201713:21#11
Suslik
> код с запретом копирования, с move-конструкторами и присваиваниями, итп. я бы
> хотел, чтобы заготовка такой RAII-штуки c подсчётом ссылок или с единственным
> владельцем была в стандарте.
А, ну и фанаты могут обойтись макросами
https://cs.chromium.org/chromium/src/v8/src/base/macros.h

Типично DISALLOW_COPY_AND_ASSIGN на большинство классов.

Правка: 29 окт. 2017 13:40

loysoПостоялецwww29 окт. 201713:24#12
innuendo
> Это чисто типа конзольный стайл
Да ну нет конечно. Оно - то что оно есть. Реально тормозит или утечки потому что цикл в ссылках можно неделями искать в огромном проекте.
Каша в голове как обычно, а не в коде или платформе или требованиях.
innuendoПостоялецwww29 окт. 201713:27#13
loyso
> Реально тормозит или утечки потому что цикл в ссылках можно неделями искать в
> огромном проекте.

ооо, я тебе так же могу сказать, можно месяцами искать проблему с гайзенберг багами когда нету rc.

> Каша в голове как обычно, а не в коде или платформе или требованиях.

Скажи это геймдизам, с которыми я имел дело. Вчера хотели так, сегодня вот так, завтра по новому

innuendoПостоялецwww29 окт. 201713:38#14
loyso
> Процитирую aruslan'а:

а можно услышать лично твой опыт с конкретными проектами ?

Страницы: 1 2 Следующая

/ Форум / Программирование игр / Общее

2001—2017 © GameDev.ru — Разработка игр