LUA скрипт [GS] DX Render++

[fidachyo]

так разве контекст сам по себе не будет глобальным? с учетом того, что придется хукать функции вызываемые из разных потоков, то и объект должен быть глоабльным, типа статического обжекта как я понимаю

контекст может быть доступным "глобально", но это не делает его singleton'ом в плохом смысле

вот в чем разница:
1. глобальный доступ (можно достучаться из разных мест и потоков)
2. глобальное владение и инициализация (где get метод сам все это создает в непредсказуемый момент)

типа, если у тебя хуки из разных потоков, то да, какая-то точка доступа будет глобальной, но лучше чтоб она была "тонкой", к примеру глобальный context* который выставляется в момент когда модуль уже готов, а дальше только чтение. если публикация до старта потоков, то достаточно будет обычного указателя, в другом же случае нужно будет допустим использовать atomic дополнительно

сам контекст может жить в root и внутри контекста можно делать lazy-init подсистем, в busy ты тогда будешь уходить только при необходимости.

p.s. мог не очень понятно объяснить, не обессудь

 

[Trich1337]

контекст может быть доступным "глобально", но это не делает его singleton'ом в плохом смысле

вот в чем разница:
1. глобальный доступ (можно достучаться из разных мест и потоков)
2. глобальное владение и инициализация (где get метод сам все это создает в непредсказуемый момент)

типа, если у тебя хуки из разных потоков, то да, какая-то точка доступа будет глобальной, но лучше чтоб она была "тонкой", к примеру глобальный context* который выставляется в момент когда модуль уже готов, а дальше только чтение. если публикация до старта потоков, то достаточно будет обычного указателя, в другом же случае нужно будет допустим использовать atomic дополнительно

сам контекст может жить в root и внутри контекста можно делать lazy-init подсистем, в busy ты тогда будешь уходить только при необходимости.

p.s. мог не очень понятно объяснить, не обессудь

честно говоря, это звучит не особо профитнее синглтона

 

[fidachyo]

честно говоря, это звучит не особо профитнее синглтона

ну смотря в чем профит, если в скорости написания, то понятное дело синглтон куда быстрее написать простой, а если смотреть с точки зрения архитектуры, то мой вариант правильный.

p.s. и я в принципе не говорю о профите, я говорю о том как "должно" быть, нагрузка не отличается, при этом плюсов от моего способа куда больше, к тому же это архитектурно верно и соответствует современным практикам написания кода, это особенно важно для не приватных исходников, которыми кто-то может пользоваться.

 

[Trich1337]

p.s. и я в принципе не говорю о профите, я говорю о том как "должно" быть, нагрузка не отличается, при этом плюсов от моего способа куда больше, к тому же это архитектурно верно и соответствует современным практикам написания кода, это особенно важно для не приватных исходников, которыми кто-то может пользоваться

я не считаю, что есть какие то должные паттерны или ещё какая то такая хуйня, или, что код можно писать правильно и тд. Код может быть либо рабочим, либо не рабочим, и рабочий должен решать поставленную задачу. по моему все просто до нельзя, усложнять жизнь на ровном месте мне не нравится.

 

[fidachyo]

я не считаю, что есть какие то должные паттерны или ещё какая то такая хуйня, или, что код можно писать правильно и тд. Код может быть либо рабочим, либо не рабочим, и рабочий должен решать поставленную задачу. по моему все просто до нельзя, усложнять жизнь на ровном месте мне не нравится.

грустно, конечно, что ты так думаешь, но я тебя не осуждаю.

если бы все работало по твоему принципу, то проекты в которых очень много строк кода представляли из себя полнейший хаос, но при этом он бы нормально работал, как это поддерживать в будущем - неизвестно. для того и придуманы различные паттерны, практики и прочее, чем больше ты будешь их применять, тем больше выгоды от них почувствуешь и быстрее вникать в базу и как-то модифицировать ее. мне тоже раньше казалось что нет смысла в книгах, которые рассказывают о том как правильно писать код и т.д., но чем больше ты в это погружаешься, тем больше ты чувствуешь всю ту пользу, что закладывают в это всё авторы. к тому же подобные вещи ОЧЕНЬ полезны для твоего мозга, я не буду объяснять почему, так как это все долго и сложно.

не просто так создан cppcoreguidelines тот же.

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

 

[Trich1337]

если бы все работало по твоему принципу, то проекты в которых очень много строк кода представляли из себя полнейший хаос, но при этом он бы нормально работал, как это поддерживать в будущем - неизвестно.

паттерн это тот же хаос, просто понятный человеку, который в этом разбирается. Так же как для нас не понятны языки давно вымерших цивилизаций, оставившие после себя только письменность, так же не понятны паттерны для людей, которые их не учили и с ними не сталкивались.
Любую периодику подчиняющуюся анализу можно назвать паттерном. Так что проекты в которых очень много кода - хаотичны и это неизбежно. Даже великий линус торвальдс пишет код в котором используются рандомные магические числа(и это в ядре), хотя он вроде уважаемый чел.

 

[fidachyo]

паттерн это тот же хаос, просто понятный человеку, который в этом разбирается. Так же как для нас не понятны языки давно вымерших цивилизаций, оставившие после себя только письменность, так же не понятны паттерны для людей, которые их не учили и с ними не сталкивались.
Любую периодику подчиняющуюся анализу можно назвать паттерном. Так что проекты в которых очень много кода - хаотичны и это неизбежно. Даже великий линус торвальдс пишет код в котором используются рандомные магические числа(и это в ядре), хотя он вроде уважаемый чел.

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

"Проекты хаотичны и это неизбежно" - ну это слишком фаталиcтично, сложность понятное дело неизбежна, но самое главное, что ее можно снижать и контролировать, в этом и есть смысл архитектуры, инвариантов и так далее.

а пример с Линусом Торвальдсом и магическими числами - это совсем не контраргумент. в ядре есть свой стиль, ревью, подсистемы, границы ответственности и так далее, оно не держится на рандоме, там есть дисциплина. то что есть какие-то куски кода плохие не отменяет полезность всех правил.

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

 

[Trich1337]

то что есть какие-то куски кода плохие не отменяет полезность всех правил.

не отменяет полезность, а уравновешивает её. если в одном месте все якобы понятно, то в другом вдруг нет, и вся картинка не выстраивается.
Я бы понял если бы речь шла про C, но речь идет о C++ - хаотичном, местами нелогичном языке, стандарты этого языка многое о нем говорят, архитектура разительно отличается от проекта к проекту, "чистота" кода тоже, но главное одно - он работает. Напомню, что С++ и так не читаемый язык по сравнению с С, и пытаться реально структурировано что то делать это утопия. Лучше делать так, что бы оно работало, ведь это главная цель, так как абстракция это буквально хаос, что доказывается людьми с психическими отклонениями, которые по другому её интерпретируют, например, Терри Дэвис, его код не выглядит красиво и "как надо", но он ахуенный и главное рабочий.

Возможности языка надо использовать для решения задачи, а не для поддержания архитектуры в первую очередь. Пример с синглтоном очень наглядно это показывает - просто и работает, я не свидетель синглтонов, но все же там, где я его выбрал использовать, я выбрал не зря. Иметь структуру с указателями на хиповые объекты и называть это контекстом мне не особо хочется. Да и кому надо тот и разберется, опять же, это открытое ПО, что подразумевает, что ты должен сам в нем лазить, и никто никому ничего не должен, даже если бы это решало хоть что то.

По твоим сообщениям плюс "контекста" только в том, что он "архитектурно выгоднее", хотя не понятно в чем, ведь прикладных примеров ты не предоставил, но уже пожалел меня в моем выборе.

 

[Desolution]

Проблемы с мультикором. Они поыикшены, но скрипт не обновлён просто. Если время появится, мб залью нормальную версию

ну ждёмс

у тебя в апи кстати рендер картинки не расписан, только в примере есть

и если можешь, то прошу добавить возможность рендера svg

 

[Klient]

ну ждёмс

у тебя в апи кстати рендер картинки не расписан, только в примере есть

и если можешь, то прошу добавить возможность рендера svg

В новой версии все есть, даже больше. Просто пока времени нету это выложить