- Zefick
- Постоялец
RikiTikiTak
> хоть на 200% процентов изучи проект или его совсем не изучай это проблемы индейцев.
Когда индейцы исправляя один баг добавляют в код ещё два это становится уже проблемой шерифа. Просто отругать индейцев не получится, они тогда вообще перестанут что-то делать боясь всё сломать.
> модульность это когда порядок вызова функций не важен
Это в вашем заборостроительном вам такое говорили? Порядок операций всегда важен, вне зависимости от используемого архитектурного подхода.
=A=L=X=
> GLuint vertexShader = glCreateShader( GL_VERTEX_SHADER );
> ALX_FINALLY( if ( vertexShader ) glDeleteShader( vertexShader ) );
Ты уже обернул это в класс только анонимный. Осталось обернуть в именнованный
1 frag / 2 deaths
> Ты уже обернул это в класс только анонимный. Осталось обернуть в именнованный
Да, просто ради одной (и это факт - одна единственная строка кода с glCreateShader) я посчитал ненужным заводить класс.
Попробуй поспорь.
RikiTikiTak
> Нужно вносить правки так что бы ничего не ломать и больше меня ничего не интересует
ну конечно тебя интересует, одна очень важная вещь - время.
время - сколько займёт внесение этих самых правок.
=A=L=X=
> но он обмазал синтаксис метками.
Так задумано конкретно в моём велосипедном случае, чтобы улучшение укладывалось в существующий синтаксис жабаскрипта, и за счёт этого сэкономить на парсере. Семантически это, конечно, операторы. При серьёзно-официальном улучшении, конечно, это всё можно сделать, как надо.
=A=L=X=
> Попробуй поспорь.
Ок, давай поспорю
Если данное "завершающее действие" делается один раз в жизни под одну ситуацию которая никогда больше не повторится, то действительно достаточно такого finally.
Если ты пишешь свой фреймворк где создание шейдера может происходить разными способами в нескольких функциях то тогда целесообразнее завернуть в класс
1 frag / 2 deaths
> Ок, давай поспорю
> Если данное "завершающее действие" делается один раз в жизни под одну ситуацию которая никогда больше не повторится, то действительно достаточно такого finally.
> Если ты пишешь свой фреймворк
Т.е. ты так и не прочитал?
Ну понятно.
Тарас сегодня вялый пошёл.
Ну мож прочитае, еще раз кину ссылку, а то ведь уйдёт глупый https://gamedev.ru/flame/forum/?id=153724&page=15&m=6089967#m214
Впрочем пять уже страниц назад я понимаю - не до перечитки. А это уже пять страниц назад.
По идее, за 30 лет кто-то уже должен был написать человеческие обертки над win32 api. Я не разбираюсь ни в win32api, ни в крестах, но вот это вроде похоже, не?
Чтоб не упарываться большими фреймворками - много виндовых хэндлов можно ведь обернуть практически одним шаблонным классом, который инкапсулирует хэндл без возможности копирования и шаблонным nontype-параметром тащит функцию освобождения хэндла.
Применять хэндл через тайпкаст-метод, а чтоб случайно через этот тайпкаст не скопировать - конструктор инкапсулированного хэндла должен быть не из сырого хэндла, а через вариадик-фабрику, которой апишная функция создания передается через шаблонный параметр (шаблон уже не типа, а самого метода-фабрики).
Dmitry_Milk
> Чтоб не упарываться большими фреймворками - много виндовых хэндлов можно ведь обернуть практически одним шаблонным классом, который инкапсулирует хэндл без возможности копирования и шаблонным nontype-параметром тащит функцию освобождения хэндла.
Похоже?
https://github.com/kennykerr/dx/blob/master/handle.h
entryway
> Похоже?
Не могу распарсить. В частности, не пойму, откуда берется Traits и его Traits::close.
entryway
> По идее, за 30 лет кто-то уже должен был написать человеческие обертки над win32 api
MFC и OWL - бесчеловечные? :)
Dmitry_Milk
> можно ведь обернуть практически одним шаблонным классом, который инкапсулирует хэндл б
Ипать прозрел когда решение уже озвучено было.
Далее мысль куда пойдёт?