Если игра не слишком большая, то нормально. Если объёектов планируется спавнить много, то лучше жить с ECS, аренами и сырыми указателями. Ещё есть вариант похожий на gc - autorelease pool, как в кокосе. Там можно ручками инкрементить счётчик ссылок. Проблемы там правда похожие получаются и следить за объектами несколько сложнее, плюс дефолтная реализация управление пулом без допиливание напильником начинает заметно фрагментировать память в некоторых ситуациях. Если есть какие-то ограничения по памяти, то это надо будет патчить.
Если вы про пример со strncopy, то третьим параметром там передаётся размер целевого буфера, а не строки. Зачем там substring магической длины правда непонятно.
Я понял, что ошибся. Думал что вы в первом случае тоже ссылку копируете, но копируются данные. С другой стороны не очень понятно зачем их клонировать, когда сами данные кажется достаточно локальные и можно целиком отдать их в чужое владение, просто развернув их из умного указателя. Но тут вам определённо виднее.
Опционалы в Go фактически существуют. Проблема именно с обработкой - нет удобного способа их обработки. В Rust есть варианты, что можно сделать с ошибкой - лифтануть ошибку выше при помощи элвиса (try_do()? ), запаниковать на месте (try_do().expect("can't do")), конвертнуть (.map_err()), либо вообще бесстрашно развернуть в значение (всякие unwrap(), unwrap_or(x) ,unwrap_or_default() или просто .or()), а при помощи сторонних либ (anyhow , thiserror и пр.) можно ещё и контекст ошибки явно указать и делать удобную конвертацию одних ошибок в другие, в том числе и лениво.
В Zig тоже есть варианты вроде того же элвиса или orfail как в статье или ordefault (по аналогии с растом . При всей похожести кода zig и go наличие лаконичной обработки ошибок в zig делает его заметно приятнее.
Ещё б ржавый код каким-нибудь clippy обработать, а то местами оно выглядит несколько странно и неконсистентно, в сравнении с тем же питоном - приколы типа x.borrow().clone() пополам с Rc::clone().
Интересно, а будет ли профит если пытаться нанимать тех копировальщиков. Сходу поясняешь, что оин в минус работать будут, а ты им з.п. вместо этого обещаешь.
И тут работник сразу же начинает работать хорошо, продуктивно и очень эффектно эффективно.
Вот вы тут паясничаете, а аутисты на серьезных щах страдают от проблем с продуктивностью ибо сенсорная перегрузка и иногда сопутствующий СДВГ мешают им жить.
Не эксперт в PHP. Видел какой-то недавний релиз (~год назад), который делал некоторый пример с трейтами и видимо я их таки спутал с интерфейсами. Тем не менее и интерфейсы и трейты помогают с композицией. Но, учитывая что типизацию допиливают по сей день и интеграция с фреймворками вроде не самая глубокая - С# в этом смысле побеждает.
Есть иммутабельные типы. Да и вообще с типами в C# заметно лучше. И проблем с null/undefined заметно меньше в сравнении с js/ts/php.
Интерфейсы есть с незапамятных времен, в пых только недавно завезли трейты, в чистом JS их вообще нет. Барбару Лисков без них ублажать заметно сложнее и багованнее.
Потенциал к появлению SIMD инструкций в коде и как результат больший перформанс по сравнению с двумя остальными.
Время компиляции TS vs C# сдаётся мне будет на стороне C#.
Мне интересно как у людей с 5к сотрудников не хватает денег на санитарку. Это ж куча народа
когда твоих эйчаров перманентно брутфорсят индусы с китайцами случайная выборка будет фильтровать заметно хуже чем литкодом
попробуйте мозиловский fluent. хотя если Java то будут нюансы
Если игра не слишком большая, то нормально. Если объёектов планируется спавнить много, то лучше жить с ECS, аренами и сырыми указателями. Ещё есть вариант похожий на gc - autorelease pool, как в кокосе. Там можно ручками инкрементить счётчик ссылок. Проблемы там правда похожие получаются и следить за объектами несколько сложнее, плюс дефолтная реализация управление пулом без допиливание напильником начинает заметно фрагментировать память в некоторых ситуациях. Если есть какие-то ограничения по памяти, то это надо будет патчить.
Если вы про пример со strncopy, то третьим параметром там передаётся размер целевого буфера, а не строки. Зачем там substring магической длины правда непонятно.
Есть вот такое. Но вообще для каждого подтипа LINQ обычно есть отдельная либа.
Сделайте на чём-нибудь комиплируемом в wasm. Тогда оно заведётся в том числе и в андроиде прямо в браузере.
Кажется баркоды - самое очевидное решение и кажется самое эффективное, если делать бумажные кассеты с графическим распознованием
Можно взять какую-нибудь трекерную музыку и использовать их формат кодирования для рисования на бумаге. Будет очень похоже на барабанные jukebox.
Я понял, что ошибся. Думал что вы в первом случае тоже ссылку копируете, но копируются данные. С другой стороны не очень понятно зачем их клонировать, когда сами данные кажется достаточно локальные и можно целиком отдать их в чужое владение, просто развернув их из умного указателя. Но тут вам определённо виднее.
Так проблема в первую очередь не писать, а читать. А во вторую - конвертация одних ошибок в другие.
Опционалы в Go фактически существуют. Проблема именно с обработкой - нет удобного способа их обработки. В Rust есть варианты, что можно сделать с ошибкой - лифтануть ошибку выше при помощи элвиса (
try_do()?), запаниковать на месте (try_do().expect("can't do")), конвертнуть (.map_err()), либо вообще бесстрашно развернуть в значение (всякиеunwrap(),unwrap_or(x),unwrap_or_default()или просто.or()), а при помощи сторонних либ (anyhow , thiserror и пр.) можно ещё и контекст ошибки явно указать и делать удобную конвертацию одних ошибок в другие, в том числе и лениво.В Zig тоже есть варианты вроде того же элвиса или
orfailкак в статье или ordefault (по аналогии с растом . При всей похожести кода zig и go наличие лаконичной обработки ошибок в zig делает его заметно приятнее.Ещё б ржавый код каким-нибудь clippy обработать, а то местами оно выглядит несколько странно и неконсистентно, в сравнении с тем же питоном - приколы типа
x.borrow().clone()пополам сRc::clone().дык они ж её только в 25 на дорогах обещают
13.5 часов зарядки на 3к км не звучит обнадёживающе, как и 300км запаса хода.
Тем не менее автор говорит, что тех копировальщиков тысячи. И при этом людей на производство не хватает. Звучит как дырка и пробка под неё.
Интересно, а будет ли профит если пытаться нанимать тех копировальщиков. Сходу поясняешь, что оин в минус работать будут, а ты им з.п. вместо этого обещаешь.
Вот вы тут паясничаете, а аутисты на серьезных щах страдают от проблем с продуктивностью ибо сенсорная перегрузка и иногда сопутствующий СДВГ мешают им жить.
Не эксперт в PHP. Видел какой-то недавний релиз (~год назад), который делал некоторый пример с трейтами и видимо я их таки спутал с интерфейсами. Тем не менее и интерфейсы и трейты помогают с композицией. Но, учитывая что типизацию допиливают по сей день и интеграция с фреймворками вроде не самая глубокая - С# в этом смысле побеждает.
Есть иммутабельные типы. Да и вообще с типами в C# заметно лучше. И проблем с null/undefined заметно меньше в сравнении с js/ts/php.
Интерфейсы есть с незапамятных времен, в пых только недавно завезли трейты, в чистом JS их вообще нет. Барбару Лисков без них ублажать заметно сложнее и багованнее.
Потенциал к появлению SIMD инструкций в коде и как результат больший перформанс по сравнению с двумя остальными.
Время компиляции TS vs C# сдаётся мне будет на стороне C#.
Блин, думал щас алгоритмами будут меряться.