Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / [C++] Управление памятью (2 стр)

[C++] Управление памятью (2 стр)

Поделиться
Advanced: Тема повышенной сложности или важная.
Страницы: 1 2 3 48 Следующая »
TruthfinderПостоялецwww4 дек. 201714:52#15
Атличный код ящетаю Изображение
SuslikМодераторwww4 дек. 201714:55#16
Демон
> cSprite *bg = Engine->Get("bg");
> delete bg;
вообще в нормальном коде если где-то встречается new или delete, это можно считать ошибкой, потому что этот код потенциально не безопасен. запихивание мьютекса в смартпойнтер — это очень плохая практика, потому что оно создаёт жуткий оверхед даже в singlethreaded среде и, как уже сказали, дедлоки в многопоточной. thread safety должен менеджиться уровнем выше, а никак не на уровне самого смартпойнтера. \

> cSprite *bg = Engine->Get("bg");
в этом случае у тебя объектом всегда владеет как минимум engine. какой смысл считать reference count'ы, если объект гарантированно нельзя удалить до тех пор, пока им владеет как минимум engine? какой смысл кому-то хранить живой указатель на объект, если он уже удалён в engine'е? я к тому, что этот случай — классического unique ownership'а, который гораздо эффективнее и контролируемее реализуется через std::unique_ptr, чем через shared_ptr и тем более чем через любой велик.

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

Правка: 4 дек. 2017 15:02

ДемонПостоялецwww4 дек. 201715:00#17
Стас
> Весь этот код это "Инструкция как делать дедлоки". И плюс еще утечка памяти.
Это шаблон написанный на сайте, понятно что доработка будет
СтасПостоялецwww4 дек. 201715:02#18
Демон
> Это шаблон написанный на сайте, понятно что доработка будет
Забудь про этот велосипед, и как минимум почитай про interlocked. Твой код не просто дырявый, и приглашение к проблемам... Но он еще и тормозной сверх всякой меры. А лучше не велосипидируй а используй stl
ДемонПостоялецwww4 дек. 201715:07#19
Suslik
> в этом случае у тебя объектом всегда владеет как минимум engine. какой смысл
> считать reference count'ы, если объект гарантированно нельзя удалить до тех
> пор, пока им владеет как минимум engine? какой смысл кому-то хранить живой
> указатель на объект, если он уже удалён в engine'е? я к тому, что этот случай —
> классического unique ownership'а, который гораздо эффективнее и контролируемее
> реализуется через std::unique_ptr, чем через shared_ptr и тем более чем через
> любой велик.
>
> вообще в подобных случаях прежде, чем бежать на форум создавать advanced темы
> лучше поинтересоваться, почему именно так много людей смартпойнтеры, как они
> работают и имеет ли объективно смысл писать свой пятиколёсный велик.
engine не всегда владеет.
Есть деревья объектов где храниться объект, есть сетевой уровень где есть ссылка на него, есть деревья октри где есть опять же ссылка, есть конвеер рендера где снова присутствует объект. а может пользователь просто извлечь объект из движка для самостоятельных махинаций, или инициализировать обьект самостоятельно и отдать на управление движку, при этом что мешает сохранить ему ссылку и удалять когда захочеться. Мютексы в поинтер погорячился, но оставлю там для ручного вызова для больших объектов. например заблокировать слой, или сцену. опять же с таймером блокировки

Правка: 4 дек. 2017 15:10

SuslikМодераторwww4 дек. 201715:20#20
Демон
> Есть деревья объектов где храниться объект, есть сетевой уровень где есть
> ссылка на него, есть деревья октри где есть опять же ссылка, есть конвеер
> рендера где снова присутствует объект. а может пользователь просто извлечь
> объект из движка для самостоятельных махинаций, или инициализировать обьект
> самостоятельно и отдать на управление движку, при этом что мешает сохранить ему
> ссылку и удалять когда захочеться.
вообще часто если хочется, чтобы объектом владели сразу несколько сущностей равноправно, это значит, что ты что-то делаешь не так. не всегда, но часто. твой случай — совершенно типичный. если считать, что объект нельзя удалять до тех пор, пока им какой-то там, видите ли, сетевой уровень где-то владеет или там пользователь его для себя зачем-то извлёк, то это приводит к хаосу из никогда не удаляемых объектов, потому что кто-то на них вечно хранит ссылку. случай с единственным владельцем, у которого все остальные просят временный доступ к объекту, контролируется гораздо лучше и предсказуемее, плюс реализуется гораздо эффективнее(не нужен рефкаунтинг).

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

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

Правка: 4 дек. 2017 15:23

ДемонПостоялецwww4 дек. 201715:23#21
Suslik
> вообще часто если хочется, чтобы объектом владели сразу несколько сущностей
> равноправно, это значит, что ты что-то делаешь не так. не всегда, но часто.
> твой случай — совершенно типичный. если считать, что объект нельзя удалять до
> тех пор, пока им какой-то там, видите ли, сетевой уровень где-то владеет или
> там пользователь его для себя зачем-то извлёк, то это приводит к хаосу из
> никогда не удаляемых объектов, потому что кто-то на них вечно хранит ссылку.
> случай с единственным владельцем, у которого все остальные просят временный
> доступ к объекту, контролируется гораздо лучше и предсказуемее, плюс
> реализуется гораздо эффективнее(не нужен рефкаунтинг).
> в подобных случаях всегда критически важно для себя уяснить, какую
> функциональность было бы теоретически неплохо иметь, а какая — абсолютно
> необходима, потому что практически всегда пожертвовав чем-то всё равно не
> слишком важным, можно сделать гораздо более эффективную и устойчивую
> реализацию.
Тут можно добавить флаг удаления, т. е. если необходимо удалить объект то, все уровни удаляют свою копию объекта?
SuslikМодераторwww4 дек. 201715:25#22
Демон
> Тут можно добавить флаг удаления, т. е. если необходимо удалить объект то, все
> уровни удаляют свою копию объекта?
а ещё можно перезагрузить компьютер, да? это называется костыль. перезагрузки между уровнями используются именно как очень простой способ менеджмента времени жизни игровых объектов. если у тебя всё равно объекты удаляются при перезагрузке уровня, тогда нафига вообще вся эта телепня с рефкаунтингом, если уровень можно просто считать владельцем всех объектов и удалять их, когда уровень выгружается?

Правка: 4 дек. 2017 15:27

ДемонПостоялецwww4 дек. 201715:29#23
Suslik
> а ещё можно перезагрузить компьютер, да? это называется костыль. перезагрузки
> между уровнями частично нужны именно чтобы скрыть косяки в системе непрерывного
> менеджмента объектов, которые не позволяют работать непрерывно. если у тебя всё
> равно объекты удаляются при перезагрузке уровня, тогда нафига вообще вся эта
> телепня с рефкаунтингом, если уровень можно просто считат владельцем всех
> объектов и удалять их, когда уровень выгружается?
Повторное использование ресурсов, выгружается только то что не используется, каждый объект имеет свои файлы настроек, модель или спрайт, локальный скрипт, зачем нам очищать меш если снова ее грузить
SuslikМодераторwww4 дек. 201715:32#24
Демон
> Повторное использование ресурсов, выгружается только то что не используется,
> каждый объект имеет свои файлы настроек, модель или спрайт, локальный скрипт,
> зачем нам очищать меш если снова ее грузить
хотел что-то в ответ написать, но потом забил. ты всё равно посчитаешь, что знаешь лучше. так что могу посоветовать просто поприменять свой велосипед для чего-то реального, поработать желательно в команде с кем-нибудь итп.
nesПостоялецwww4 дек. 201715:36#25
А еще доставляет что автор на каждый пук выделяет память )
TruthfinderПостоялецwww4 дек. 201716:01#26
nes
> А еще доставляет что автор на каждый пук выделяет память )

Мы поместили new внутрь new, чтобы выделять память во время выделения памяти.

TruthfinderПостоялецwww4 дек. 201716:03#27
ТСу стоило бы поизучать код boost/std для общего развития.

Правка: 4 дек. 2017 16:09

ZabПостоялецwww4 дек. 201716:49#28
Стоит для начала изучить С++, для общего развития. Память научиться выделять и освобождать, отслеживать парность lock и unlock, узнать что такое конструктор копирования и передача параметров по ссылке.

Ну и stl хотя бы на том уровне, что был 1989 году, где уже были shared_ptr, кстати (Или их там не было?).

Правка: 4 дек. 2017 16:54

ZabПостоялецwww4 дек. 201716:51#29
В курсе, что время блокирования мьютекса ограничено? Ты не можешь заблокировать и ждать несколько секунд пользовательского ввода, к примеру.
Страницы: 1 2 3 48 Следующая »

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

Тема закрыта.

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