Зачем нужен весь этот колхоз не очень понятно:
1. Есть готовые реализации, например, вот хорошая github.com/kikito/middleclass/
2. Lua предполагает несколько другую парадигму вместо ООП, вот ей и надо пользоваться.
А так получилась статья из серии «а смотрите как я могу». Можете, молодец. Но зачем это здесь? Кому нужен этот непонятный код?
> Сумбурно звучит, знаю, но лучше не могу объяснить — не спец :)
> Не судите строго, может кому-то зачем-то пригодится это решение!
Плохого в них ничего нет, я немного не понял вопрос.
Здесь я имел в виду, что код игры достаточно сложный и большой. Соответственно, обсуждать его нужно с этих позиций и написанные мной мысли применимы именно в таком контексте.
Я заметил тенденцию восприятия моего текста фрагментарно. Не забывайте про комплексность проблемы. Про то, что у нас здесь большой проект, которому нужна производительность, портируемость, возможность работы над ним нескольким программистам и наверное что нибудь ещё. В случае написания каких-нибудь десктопных приложений ваш подход вполне может иметь место.
Или вот вы схватились за «умные» указатели, но кроме них предлагали использовать буст и исключения. Я же привел указатели как самый очевидный и легкий пример для обсуждения, подразумевая, конечно, что проблема не только в них, но целиком в ошибочности (в конкретном случае) подхода, который вы предложили.
> Что значит найти?
Предположим, что объект в unique_ptr у нас удаляется только по завершении жизни некоего класса, жизнь которого зависит от другого класса, а того от третьего. И таких классов в проекте, ну, пусть даже сотня. А у некоторых зависимость не от одного, а, предположим, от жизни двух или трех. Это что же, везде сидеть искать где заканчивается scope? Сами в своем коде мы может это всё и сможем проверуть. А коллеги?
В случае с простым delete мы опять же можем это сделать быстрее и точнее. Всегда можно быстро тыкнуть в код и сказать — вот, класс удаляется здесь, и он ещё тянет за собой вот эт и то. Явно.
Но, тут я повторюсь, это уже скорее не проблема игр, где памятью стараются управлять немного иначе, что делает использование «умных» указателей не оправданным ещё в большей степени.
> Стандартная библиотека, она одна. Она на то и стандартная
Я имел в виду реализации стандартных библиотек. У которых местами немного разное поведение.
> вызвали вы функцию printArray(ptr), а она ptr и удалила
Боюсь что этот пример как раз показывает отсутствие преимуществ у «умных» указателей в данном случае, т. к. неумелый программист может и reset сделать где не надо, что полностью нивелирует профит. И если явный delete мы найдем быстро, то неявный out of scope можем найти быстро не всегда. Как минимум придется посмотреть где что умирает и от чего зависит.
> можно ориентироваться на MSVC как на
> минимально поддерживающего новые фичи
Мы всё ещё говорим про игры уровня Doom 3? Вы программируете только для Windows?
> Во-первых, мы точно знаем, что он будет удален. При out-of-scope.
Но вы пропустили ещё одну часть моей мысли. Этот out-of-scope ещё надо найти. Думаю, не надо объяснять что он очевиден только при использовании в пределах функции.
Кстати, немного отклонюсь от темы чтобы сообщить вам, что в играх стараются не использовать (а в некоторых не используют вообще) аллокации непосредственно во время игры. Что делает проблему указателей и выделения памяти чуть менее тяжелой и делает необходимость в «умных» указателях не такой важной как может показаться.
> В 99% процентов случаев только там.
Оставшийся процент как раз и даст о себе знать. Никого не интересуют простые паттерны использования той или иной технологии.
> Прошерстив код на предмет delete.
Да, но ТОЛЬКО на предмет delete и ничего более.
> Правило такое хорошего тона.
> нормальные люди очень редко использют reset посередине использования
Я бы не стал полагаться на это при написании больших проектов.
> если изуить стандартную библиотеку
Здесь вы, кажется, пропустили мой самый первый абзац. Стандартных библиотек, кстати, несколько. Каждую изучать?
В вашем комментарии я вижу уже как минимум два неявных места:
> они эффективно раскручиваются, иналйнаятся и оптимизируются
> от всех геттеров не останется вообще ничего после инлайна.
это зависит не только от компилятора, но даже и от его версии и ключей компиляции, вот вам первое место, в котором вы не можете быть уверены. уверенность здесь может быть достигнута только путем накопления большого количества опыта и глубокого знания своего инструмента. поменялся компилятор/платформа — думаю понятно.
> Тот же unique_ptr развернется в пару new и delete
здесь мы, например, не всегда сможем быстро сказать где конкретно (и когда) будет удален объект. придется шерстить код не только на предмет reset, но и на предмет out of scope / operator=. Если же мы используем сырые указетели, то место удаления можно предсказать с точностью 100%.
> Что вы понимаете под «неявными местами», мне непонятно.
Надеюсь я добавил понимания.
Ещё раз обращаю ваше внимание, что здесь я говорю именно про игровые проекты уровня Doom 3 (собственно про это и топик). Если мы пишем другие проекты, то применение технологий стоит рассматривать в их контексте отдельно.
Например, smartptr добавляет видимую простоту, но в долгосрочной перспективе он добавляет большое количество неявных мест, что в итоге не идет на пользу проекту.
Если бы это было, предположим, офисное приложение, то это было бы не так страшно, но в условиях когда идет борьба за каждый кадр — чем меньше таких штук тем лучше, тем проще оптимизировать, тем проще предсказать поведение программы и так далее.
На мой взгляд как трилогия, «Трилогия Моста» получилась гораздо удачнее «Киберпространства». Однако, «Нейромантика» ни одна из остальных пяти книг по отдельности не переплюнула. :)
Кстати, возвращаясь к недавнему обсуждению Stand Alone Complex, хочу отметить, что второй сезон, который я досмотрел на днях, получился лучше первого. Если качество сюжетной части можно обсуждать, то построение эпизодов, чередование филлеров и сюжетных серий сделано на порядок лучше, что делает сериал ещё более захватывающим.
1. Есть готовые реализации, например, вот хорошая github.com/kikito/middleclass/
2. Lua предполагает несколько другую парадигму вместо ООП, вот ей и надо пользоваться.
А так получилась статья из серии «а смотрите как я могу». Можете, молодец. Но зачем это здесь? Кому нужен этот непонятный код?
> Сумбурно звучит, знаю, но лучше не могу объяснить — не спец :)
> Не судите строго, может кому-то зачем-то пригодится это решение!
Ноу коммент. Филиал ЖЖ открыт?
Поддержка субтитров есть. Кодировку менять можно. Субтитры понимает как встроенные (в том числе можно выбирать между несколькими), так и внешние.
Разные аудиодорожки понимает.
Ещё из полезных фишек — выбор аппаратного/программного декодирования отдельно для видео и аудио.
Я нигде не упоминал люблю я офисные приложения или не люблю. Это ваши выдумки.
> Не такой уж он и большой, кстати
Какой же он? ) С какого количества строк начинается большой?
Здесь я имел в виду, что код игры достаточно сложный и большой. Соответственно, обсуждать его нужно с этих позиций и написанные мной мысли применимы именно в таком контексте.
Или вот вы схватились за «умные» указатели, но кроме них предлагали использовать буст и исключения. Я же привел указатели как самый очевидный и легкий пример для обсуждения, подразумевая, конечно, что проблема не только в них, но целиком в ошибочности (в конкретном случае) подхода, который вы предложили.
> Что значит найти?
Предположим, что объект в unique_ptr у нас удаляется только по завершении жизни некоего класса, жизнь которого зависит от другого класса, а того от третьего. И таких классов в проекте, ну, пусть даже сотня. А у некоторых зависимость не от одного, а, предположим, от жизни двух или трех. Это что же, везде сидеть искать где заканчивается scope? Сами в своем коде мы может это всё и сможем проверуть. А коллеги?
В случае с простым delete мы опять же можем это сделать быстрее и точнее. Всегда можно быстро тыкнуть в код и сказать — вот, класс удаляется здесь, и он ещё тянет за собой вот эт и то. Явно.
Но, тут я повторюсь, это уже скорее не проблема игр, где памятью стараются управлять немного иначе, что делает использование «умных» указателей не оправданным ещё в большей степени.
> Стандартная библиотека, она одна. Она на то и стандартная
Я имел в виду реализации стандартных библиотек. У которых местами немного разное поведение.
> вызвали вы функцию printArray(ptr), а она ptr и удалила
Боюсь что этот пример как раз показывает отсутствие преимуществ у «умных» указателей в данном случае, т. к. неумелый программист может и reset сделать где не надо, что полностью нивелирует профит. И если явный delete мы найдем быстро, то неявный out of scope можем найти быстро не всегда. Как минимум придется посмотреть где что умирает и от чего зависит.
> можно ориентироваться на MSVC как на
> минимально поддерживающего новые фичи
Мы всё ещё говорим про игры уровня Doom 3? Вы программируете только для Windows?
Но вы пропустили ещё одну часть моей мысли. Этот out-of-scope ещё надо найти. Думаю, не надо объяснять что он очевиден только при использовании в пределах функции.
Кстати, немного отклонюсь от темы чтобы сообщить вам, что в играх стараются не использовать (а в некоторых не используют вообще) аллокации непосредственно во время игры. Что делает проблему указателей и выделения памяти чуть менее тяжелой и делает необходимость в «умных» указателях не такой важной как может показаться.
> В 99% процентов случаев только там.
Оставшийся процент как раз и даст о себе знать. Никого не интересуют простые паттерны использования той или иной технологии.
> Прошерстив код на предмет delete.
Да, но ТОЛЬКО на предмет delete и ничего более.
> Правило такое хорошего тона.
> нормальные люди очень редко использют reset посередине использования
Я бы не стал полагаться на это при написании больших проектов.
> если изуить стандартную библиотеку
Здесь вы, кажется, пропустили мой самый первый абзац. Стандартных библиотек, кстати, несколько. Каждую изучать?
> они эффективно раскручиваются, иналйнаятся и оптимизируются
> от всех геттеров не останется вообще ничего после инлайна.
это зависит не только от компилятора, но даже и от его версии и ключей компиляции, вот вам первое место, в котором вы не можете быть уверены. уверенность здесь может быть достигнута только путем накопления большого количества опыта и глубокого знания своего инструмента. поменялся компилятор/платформа — думаю понятно.
> Тот же unique_ptr развернется в пару new и delete
здесь мы, например, не всегда сможем быстро сказать где конкретно (и когда) будет удален объект. придется шерстить код не только на предмет reset, но и на предмет out of scope / operator=. Если же мы используем сырые указетели, то место удаления можно предсказать с точностью 100%.
> Что вы понимаете под «неявными местами», мне непонятно.
Надеюсь я добавил понимания.
Ещё раз обращаю ваше внимание, что здесь я говорю именно про игровые проекты уровня Doom 3 (собственно про это и топик). Если мы пишем другие проекты, то применение технологий стоит рассматривать в их контексте отдельно.
Если бы это было, предположим, офисное приложение, то это было бы не так страшно, но в условиях когда идет борьба за каждый кадр — чем меньше таких штук тем лучше, тем проще оптимизировать, тем проще предсказать поведение программы и так далее.
Также, как и везде, большое значение имеет то, насколько код прост. Чем крупнее проект, тем важнее этот фактор.
Конечно, я и не ставил целью намекнуть на это. Просто забавная история и не более того. =)
Solid State Society тоже крутой.
Так что рекомендую.