На данный момент Rust — единственный язык программирования, обладающий одновременно активным сообществом и характеристиками, позволяющими ему решать задачи, решаемые языками C/C++.
D вообще бинарно совместим с C — просто влинковываем объектник и всё работает.
В C# есть атрибут DllImport — можно делать биндинги к любой нативной dll. Есть некоторые проблемы с маршалингом — базовые типы (int, float, string) работают более-менее, более сложное нужно разруливать руками. В целом терпимо :)
За другие языки не скажу.
Увы, сейчас мода на всё готовое — и поэтому все 4 пункта легко решаются готовым графическим двиганом. Впрочем, в случае с непосредственно OpenGL, у вас есть богатая обратная совместимость, так что никто не мешает рисовать на glBegin/glEnd, разве что будет работать всё это чрезмерно медленно. Если не нужен «графон как в крузисе» то и на OpenGL 2.0-2.1 можно собрать то, что нужно :)
Я не хочу показаться невежливым, но за кой нам еще одно статья о том, как запихнуть флоаты в VBO и нарисовать их? Простой поиск на хабре по ключу «OpenGL» находит множество статей с совершенно идентичным содержанием, причём зачастую с гораздо более полным. Так вот зачем?
Почти не использую, и у меня вопрос. А разве JIT не в состоянии сам заинлайнить маленькие методы, если даже этот атрибут не используется? Если может и JIT умнее, то зачем вообще помечать?
Не просто в состоянии, а даже активно это делает, когда может. Вот тут есть небольшой текст с рационализацией процесса инлайнинга. Я тоже не до конца понимаю смысла помечать методы агрессивным инлайнингом — это то, что я бы назвал premature optimization. Пока нету метрик перформанса с явным пониманием, что метод мог бы быть быстрее, если заинлайнен — зачем вообще писать лишний код?
Можно ли как-то подробнее осветить эти решения «того периода»? Очень интересно.
Нельзя полноценно назвать «архитектурными решениями», но вот, например. Да вот весь раздел полон того, что сейчас называют «Legacy». У Unreal действительно есть некоторые проблемы с кодом, но его нельзя винить в этом — движок достаточно пожилой и пережил много смен стандарта.
Я не слишком силён именно в анриле; но из того, что помню, могу сказать разве что код там явно «не свежий», и переписать какую-то часть на более новом стандарте со всякими variadic template'ами, constexpr'ами и прочими штуками могло бы быть прикольным :)
Provides a mechanism for releasing unmanaged resources.
Перевод: Предоставляет механизм для отчистки неуправляемых ресурсов. Нету ни слова о детерменированности, вы себе ее тут придумываете.
что даже не вызвав Dispose мы всё равно с течением времени освободим ресурс, но недетерминировано
Не освободим, если это struct. Я это уже говорил, но вы решили об этом забыть.
и, вообще, зачем нужны явные umanaged в структуре(?), явный антипаттерн и источник проблем за редкими исключениями
Антипаттерн — это использовать публичный протокол, который требует явной очистки ресурсов, и потом эти ресурсы не очищать. Также антипаттерн — это надеяться на детали реализации, что кто-то за вами там что-то почистит когда-нибудь. А еще антипаттерн — это использовать классы и гонять по ссылке то, что может спокойно себе полежать на стэке:
public struct SomeCThing : IDisposable
{
[DllImport("c.dll")]
private static extern IntPtr create_c_thing(...);
private IntPtr handle;
// Дальше идут обвязочные методы
}
вместо того чтобы ждать неявной очистки, которая произойдёт «когда-нибудь»
И о моей поправке:
А точнее, которая может произойти никогда
Если не вызывать Dispose явно (или через using), то очистка может не произойти никогда — если это struct (кстати, любая struct). И вы получите утечку памяти/хэндла/еще каких гадостей. Мне кажется, вы совершенно проигнорировали мою исходную позицию, и вместо этого теперь пытаетесь сказать мне то же самое.
И дело тут, кмк, не в
Лучше явно очистить ресурсы как можно скорее
А в том, что если Dispose не вызвать — вы потенциально простреливаете себе ногу.
Лучше явно очистить ресурсы как можно скорее (вызвав Close, Dispose или оператор using), вместо того чтобы ждать неявной очистки, которая произойдёт «когда-нибудь» (когда сама среда запустит финализаторы).
А точнее, которая может произойти никогда. MSDN намекает на то, что Dispose нужен мягко говоря для другого — не просто что-то закрыть, а освободить неуправляемые ресурсы, которые иначе освобождены никогда не будут.
Я могу предложить вам поиграть в Terminator на NES или любую другую игру, в которой известно омерзительно заторможенное управление. И потом сделать выводы по поводу лага :)
Не знаю, проблема ли в эмуляторе или в моем железе, но у меня BizHawk при эмуляции Sega Genesis стабильно выдаёт ровно 1 кадр (16/20мс) задержки инпута, и в 99% случаев это заканчивается врезанием в стены, прыжками в не туда и другими забавными последствиями. И если к 1 кадру можно привыкнуть (через достаточное количество боли), и к 2 кадрам можно в принципе привыкнуть, да и к 10 можно. Но назвать такой экспириенс удовлетворительным можно только в случае с, внезапно, жанром кинца, когда к вводу игрока нет совершенно никаких требований.
Любой инпут лаг, каким бы он не был, всегда понижает отзывчивость игры, а пониженная отзывчивость понижает уровень экшена.
Ну и напоследок могу добавить, что многие современные игры умудрятся прозевать нажатия будучи запущенными локально на проводных клавиатурах и мышах, так что очень сомнительные утверждения.
Если начать серьезно занудствовать, то мне вариант с двойной инициализацией не нравится хотя бы тем, что нарушает SRP и инкапсуляцию, предоставляю какую-никакую информацию о своей реализации, что не очень архитектурно красиво :)
Edit: впрочем, местами может быть оправдано, например в случае запуска сервера или еще чего-то, где метод start() будет частью интерфейса.
Чтобы избежать таких ситуаций, есть несколько вариантов решения.
Эм… и где они? Я как-то подсознательно ожидал листинга способов или разбор плюсов и минусов того или иного способа, но вы их даже не предоставили. Как-то даже немного обидно получилось :(
Искусство, как и все остальное, имеет под собой довольно строгие правила, которые тоже не просто так взялись. А люди этих правил не знают и начинают судить всё через личное восприятие «нравится / не нравится». Композиция в изобразительном искусстве учитывает особенности расположения глаз у человека. Цветоведение учитывает особенности восприятия цвета нашим мозгом. Ноты в музыке выбраны не случайным образом, а с особенности человеческого восприятия звуковых волн. Из неслучайно выбранных нот строятся неслучайно выбранные аккорды, которые позволяют строить сочетания, приятные уху.
Очень часто встречается, что люди просто никогда не видели чего-то хорошего и из-за этого не могут восприимать и видеть разницу между действительно сложным, хорошим и искусным и проходняком, который сделан кое-как или не очень хорошо, не очень осмысленно. Или проблема уже непосредственно в понимании слова искусство — это ведь черезвычайно развитое мастерство в какой-то области? Оттуда и прилагательное искусный — умело, хорошо сделанный.
Ну, насчёт нейронных сетей вы сильно загнули — формально их описали уже к 60-ым годам 20 века, просто их было негде считать. А сейчас они начали работать как раз благодаря усовершенствованию видеокарт и увеличению количества дискового и не очень пространства. Да и те не спешат на замену всяким продавцам по вполне справедливым причинам — они всё еще недостаточно хороши, чтобы полноценно заменить человека. Тот же самый указанный вами генеработ «фотк лиц» выдаёт действительно приемлимый результат раз в 10 кликов в лучшем случае, в остальных получаются либо неанатомичные уроды, либо совсем вырвиглазный трэш
И частично в том, что на момент выхода PUBG лагал даже на топовом железе, был засорен читерами и банами по велению левой пятки разработчиков. Обо всех других проблемах можно почитать в рецензиях стима :)
Спасибо за поправку.
Даже с учётом исправленного варианта, именно наличие такого фильтра не диктуется законом, лишь указывается, что это один из возможных способов выполнения мер. Хотя я больше, чем уверен, что именно фильтры и будут применяться, в пору искуственного интеллекта и биг даты то :)
Я, конечно, не люблю лезть в политику, но ситуация вокруг артиклей 11 и 13 меня не может оставить. Основная проблема в том, что многие пытаются то ли ссылаться, то ли делать выводы о статьях, даже не видев их в глаза. И почти все статьи о топике даже не птыаются ссылаться на документы или давать ссылки. Сам документ не говорит ничего ни о каких фильтрах и ни о каких штрафах.
Information society service providers that store and provide to the public access to large amounts of works… shall, in cooperation with rightholders, take measures to ensure the functioning of agreements… Those measures, such as the use of effective content recognition technologies, shall be appropriate and proportionate. The service providers shall provide rightholders with adequate information on the functioning and the deployment of the measures, as well as, when relevant, adequate reporting on the recognition and use of the works and other subject-matter.
Вольный перевод:
Сервисы, которые хранят и дают доступ к большому количеству работ… должны, кооперируясь с правообладателями, принять меры для сохранения соглашений… Эти меры, в том числе эффективное использование технологий распознования контента, должны быть соответствующими и соразмерными. Провайдеры должны предоставлять правообладателям адекватную информацию о функционировании и деплойменте таких мер, а так же, когда применимо, адекватно доносить о распозновании и использовании работ и другого
Я выделил то, что считаю важным в этом артикле. Я не претендую на глубокие познания юриспруденции и права, но мне кажется, что это банальная попытка как-то законно описать существующие уже давно фильтры на том же самом ютубе, твиче и прочих. А то сейчас закон не регулирует именно эту сферу и могут быть казусы.
А как же D? :'(
В C# есть атрибут DllImport — можно делать биндинги к любой нативной dll. Есть некоторые проблемы с маршалингом — базовые типы (int, float, string) работают более-менее, более сложное нужно разруливать руками. В целом терпимо :)
За другие языки не скажу.
Taritsyn полностью прав, базовым классом может быть любой класс, от которого можно наследоваться.
Не просто в состоянии, а даже активно это делает, когда может.
Вот тут есть небольшой текст с рационализацией процесса инлайнинга. Я тоже не до конца понимаю смысла помечать методы агрессивным инлайнингом — это то, что я бы назвал premature optimization. Пока нету метрик перформанса с явным пониманием, что метод мог бы быть быстрее, если заинлайнен — зачем вообще писать лишний код?
Нельзя полноценно назвать «архитектурными решениями», но вот, например. Да вот весь раздел полон того, что сейчас называют «Legacy». У Unreal действительно есть некоторые проблемы с кодом, но его нельзя винить в этом — движок достаточно пожилой и пережил много смен стандарта.
Я не слишком силён именно в анриле; но из того, что помню, могу сказать разве что код там явно «не свежий», и переписать какую-то часть на более новом стандарте со всякими variadic template'ами, constexpr'ами и прочими штуками могло бы быть прикольным :)
С каких пор у boolean появилось, помимо истины/лжи, третье значение «может быть»?
Читаем по ссылке: Перевод: Предоставляет механизм для отчистки неуправляемых ресурсов. Нету ни слова о детерменированности, вы себе ее тут придумываете.
Не освободим, если это struct. Я это уже говорил, но вы решили об этом забыть.
Антипаттерн — это использовать публичный протокол, который требует явной очистки ресурсов, и потом эти ресурсы не очищать. Также антипаттерн — это надеяться на детали реализации, что кто-то за вами там что-то почистит когда-нибудь. А еще антипаттерн — это использовать классы и гонять по ссылке то, что может спокойно себе полежать на стэке:
И о моей поправке:
Если не вызывать Dispose явно (или через using), то очистка может не произойти никогда — если это struct (кстати, любая struct). И вы получите утечку памяти/хэндла/еще каких гадостей. Мне кажется, вы совершенно проигнорировали мою исходную позицию, и вместо этого теперь пытаетесь сказать мне то же самое.
И дело тут, кмк, не в
А в том, что если Dispose не вызвать — вы потенциально простреливаете себе ногу.
то в каком именно финализаторе он освободится, в несуществующем?
А точнее, которая может произойти никогда. MSDN намекает на то, что Dispose нужен мягко говоря для другого — не просто что-то закрыть, а освободить неуправляемые ресурсы, которые иначе освобождены никогда не будут.
Не знаю, проблема ли в эмуляторе или в моем железе, но у меня BizHawk при эмуляции Sega Genesis стабильно выдаёт ровно 1 кадр (16/20мс) задержки инпута, и в 99% случаев это заканчивается врезанием в стены, прыжками в не туда и другими забавными последствиями. И если к 1 кадру можно привыкнуть (через достаточное количество боли), и к 2 кадрам можно в принципе привыкнуть, да и к 10 можно. Но назвать такой экспириенс удовлетворительным можно только в случае с, внезапно, жанром кинца, когда к вводу игрока нет совершенно никаких требований.
Любой инпут лаг, каким бы он не был, всегда понижает отзывчивость игры, а пониженная отзывчивость понижает уровень экшена.
Ну и напоследок могу добавить, что многие современные игры умудрятся прозевать нажатия будучи запущенными локально на проводных клавиатурах и мышах, так что очень сомнительные утверждения.
Edit: впрочем, местами может быть оправдано, например в случае запуска сервера или еще чего-то, где метод start() будет частью интерфейса.
Эм… и где они? Я как-то подсознательно ожидал листинга способов или разбор плюсов и минусов того или иного способа, но вы их даже не предоставили. Как-то даже немного обидно получилось :(
Композиция в изобразительном искусстве учитывает особенности расположения глаз у человека. Цветоведение учитывает особенности восприятия цвета нашим мозгом.
Ноты в музыке выбраны не случайным образом, а с особенности человеческого восприятия звуковых волн. Из неслучайно выбранных нот строятся неслучайно выбранные аккорды, которые позволяют строить сочетания, приятные уху.
Очень часто встречается, что люди просто никогда не видели чего-то хорошего и из-за этого не могут восприимать и видеть разницу между действительно сложным, хорошим и искусным и проходняком, который сделан кое-как или не очень хорошо, не очень осмысленно. Или проблема уже непосредственно в понимании слова искусство — это ведь черезвычайно развитое мастерство в какой-то области? Оттуда и прилагательное искусный — умело, хорошо сделанный.
Даже с учётом исправленного варианта, именно наличие такого фильтра не диктуется законом, лишь указывается, что это один из возможных способов выполнения мер. Хотя я больше, чем уверен, что именно фильтры и будут применяться, в пору искуственного интеллекта и биг даты то :)
Вольный перевод:
Я выделил то, что считаю важным в этом артикле. Я не претендую на глубокие познания юриспруденции и права, но мне кажется, что это банальная попытка как-то законно описать существующие уже давно фильтры на том же самом ютубе, твиче и прочих. А то сейчас закон не регулирует именно эту сферу и могут быть казусы.