"ExternalAssets" — это путь в никуда, если нужно не только подкладывать ассеты, но и обновлять их. Самое правильное и простое решение — это изолировать локальные ассеты проекта (в статье это "InternalAssets"), а внешние ассеты хранить так как их подготовили авторы — в идеале, отдельными папками на уровне папки "InternalAssets". В этом случае обновление становится легким и простым, не нужно сортировать по кастомным папкам то, что может приехать в обновлении и чего не было ранее. К тому же есть специальные папки, которые нельзя двигать и которые могут быть только в корне (Gizmos, Plugins/Android, Plugins/iOS и т.п.). С остальным согласен, писал когда-то аналогичный пост.
У меня специализация — мобильный геймдев, процессинг данных в рантайме без фризов на сборку мусора, т.е нулевые аллокации в основном цикле апдейта, причем на несравнимо более дохлом железе, чем десктоп. Кейсы с выделением памяти всегда выносятся на этап инициализации и не допускаются в процессинге (и не потому, что рантайм такое не позволяет). Где общая производительность и непрерывность по времени исполнения не важна — там допускаю использование всего, чего душа пожелает.
Штатная правильная реализация != «ухты, мы теперь можем и так!» По ссылкам выше как раз показаны особенности, обходя которые, можно использовать данный функционал. Другое дело — кто будет разбираться в этих тонкостях в общем случае? Работает и ладно.
Я предлагаю крайне осторожно использовать генерики для структур или вообще запретить их к использованию. Разумеется, в командах и административными мерами, а не на уровне языка. Пусть кто хочет, тот себе стреляет во все конечности.
Ну генерики в структах вообще зло и должны быть запрещены из-за непредсказуемых аллокаций на ровном месте. Вложенные структуры — да, не использую, надо будет обновить тесты.
А разве в случае «in» компилятор не просто проверяет попытки прямых изменений полей, из-за чего появляется возможность передавать структуры не по значению, а по ссылке? Тесты показывают хорошее ускорение в случае сложных структур, если бы создавались защитные копии — было бы наоборот.
Очень медленное развитие. За 2018 год сделали 5 превью 4.х линейки — на macos без инсталлера и через homebrew собрать было невозможно — ocaml ругался на зависимости (сейчас возможно пофикшено). Теоретически интересная штука, на практике — полумертвое.
dotpeek — коммерческое платное решение, имеющее в себе нечто уникальное, что составляет коммерческую тайну и у чего нет аналогов типа ilspy и прочих альтернатив? А решарпер — он на чистом шарпе? Не mixed? Проблема win7 как раз в этом была.
Я не заявлял, что это в 100% случаях именно так, но в большинстве своем правда. Опенсорсные решения, поддерживаемые корпорациями, существуют не просто так, а в том числе и для привлечения еще большего числа людей в коммунити для смежных проектов.
Сейчас это или enteprise-решения, которые наружу никогда не выйдут, либо клиенты к бизнес-логике, исполняющейся на сервере и которую не увидят конкуренты. Бизнес-решений без прятания логики где-то на чистом шарпе не существует.
Проблема win7 была в том, что там не было поддержки нейтива вообще. Это значит — все приложения по сути опенсорсны (MSIL прекрасно реверсируется в чистый исходник на шарпе) и ни одна вменяемая контора со своим платным и закрытым софтом не пошла туда. Это что касается бизнес-приложений без бекенда. Что касается игрушек — это нужно было писать всем с нуля свой движок, ибо все популярные были с нейтивной частью. Переход на 8-ку был вынужден по сути, чтобы позволить исполнять закрытый код — это позволило запускать все приложения с конкурирующих платформ, но момент уже был упущен.
Почему бы и нет.
"ExternalAssets" — это путь в никуда, если нужно не только подкладывать ассеты, но и обновлять их. Самое правильное и простое решение — это изолировать локальные ассеты проекта (в статье это "InternalAssets"), а внешние ассеты хранить так как их подготовили авторы — в идеале, отдельными папками на уровне папки "InternalAssets". В этом случае обновление становится легким и простым, не нужно сортировать по кастомным папкам то, что может приехать в обновлении и чего не было ранее. К тому же есть специальные папки, которые нельзя двигать и которые могут быть только в корне (Gizmos, Plugins/Android, Plugins/iOS и т.п.). С остальным согласен, писал когда-то аналогичный пост.
«У меня все работает» ©. Игнорирование потенциально возможных проблем на разных рантаймах — это не решение. Раньше подобное приходилось слышать про mono.
Отличный аргумент. Но это не значит, что их там нет.
jacksondunstan.com/articles/3453
jacksondunstan.com/articles/3468
Надеюсь, что никогда не придется пользоваться подобным «высокопроизводительным» кодом.
Господи, сколько же вас еще придет из кровавого enterprise-а в мой любимый, но все более и более тормозящий геймдев…