Денис Загаевский, в разных областях разные конвенции именования. Если это фреймворк или библиотека, то пояснения к коду и именованию будут в документации.
Тут же явный самопал, а значит все должно быть сделано так, чтобы понять неправильно возможностей было минимум.
В стандарте C++ есть только один assert, и он никакого string не принимает.
Денис Загаевский, исхожу из следующего. Обычный ассерт = обычное утверждение. И это ничего не говорит об утверждаемом выражении.
Утверждать можно что угодно, допустим, успешный провал теста. Или ошибочный?
Ложно-положительный результат?
В выше указанном примере, true на false поменять и смысл выражения, которое утверждается меняется на противоположное.
Кроме как в имени функции, ограничение никак не реализовать, потому что ассерт ведёт себя как предикат.
Вообще, в данном случае, я бы даже Assert сделал бы namespac'ом, а сами нужные проверки уже функциями.
А в шаблонной функции неплохо бы проверить на is_same
А ещё лучше, использовать готовую библиотеку, где все уже продумано, конечно...
Эта штука в основном работает как интерфейс для визуального программирования шейдеров.
Как бонус - можно использовать для прототипирования, но это только относится к предметной области разработки игр. И сложную логику выражать через визуальные ноды просто невозможно.
В любом случае, эти блупринты не дадут функционала взаимодействия с системными ресурсами на том уровне, который он нужен в разработке прикладного ПО.
Советую подбирать SDK и пользоваться привязками для python с самого начала.
using System;
public class Test
{
public static void Main()
{
double c = 3.6;
double k = c;
c = Math.Floor(c);
double rnd = Math.Round(k - c,1);
Console.WriteLine(c);
Console.WriteLine(k);
Console.WriteLine(rnd);
}
}
Wadim_wadim2000, в общем-то, все зависит от качества прослойки между клавиатурой и стулом. Так-то xrEngine разработчики писали сами на плюсах, возмодно р физический движок тоже, и о качестве нагрузки, когда много пуль и гранат взрывается одновременно, можно судить только по модам, либо делать тесты через игровую консоль / свой мод.
Что касается оригинальной игры, то там все сцены и стычки выверены, чтобы не выходить за определенные ограничения.
Например, на Зов Припяти есть мод SGM, там есть патч на отряд Альфа - наемников, которые при встрече им игроком будут его преследовать по всей локации. Обычно это 6-7 нпс, и если они все одновремнно начинают стрелять, по личному опыту, скажу что риск вылета xrEngine сильно возрастает.
То же самое касается, если кинуть гранату в скопление ящиков, которые можно сломать, потому что они разлетаются с физическим просветом осколков.
Sozdatel_Nichego, в таком случае, использованной вами методологией организации разработки ПО будет скорее всего водопад, т.к. у вас весь код есть монолит и он не может быть разбит на модули. Термин обычно не используют для контекстов, где человек не является субъектом, для методологии человек всегда субъект и использует методологию для достижения целей.
Методологией конструирования кода будет приоритет оптимизации над внесением изменений, т.к. иных объективных причин не использовать инструментарий компилятора - классы - быть не может.
Какие парадигмы вы будете использовать во время написания кода зависит только от выбора конкретного способа отображения абстракции или поведения в коде. Если вы не используете классы и язык предоставляет инструменты для обращения к памяти через указатели, то вы можете использовать ООП, если захотите, просто вам придется реализовывать концепции самостоятельно и вы будете проводить статический анализ самостоятельно вместо компилятора. Зато вы получите гибкость в нужных местах, поскольку сможете нарушать парадигмы ООП в любом месте на любом этапе жизни объекта, за счёт дикой оптимизации, например на инициализации объектов классов и освобождении памяти из пула, над которым вы имеете полный контроль. Вы можете делать небезопасные преобразования типов, просто через указатели и расположение полей, вместо апкастов и даункастов, вы можете использовать знание о том, какого класса и с какими значениями полей был объект, когда его уничтожили, для того, чтобы переиспользовать память и сэкономить несколько спичек во время инициализации объекта другого класса или со схожими значениями полей.
Ваши абстракции скорее всего будут выражены в комментариях, а не в локализованных участках кода, инварианты вообще не будут практически никак не отображены, и логика для каждой абстракции игровой модели будет действительно размазана по всему коду.
Вы не будете использовать общепринятые практики конструирования ПО, и ваш код будет мало понятен другим людям, т. к. очень много вещей не будут выражены непосредственно явно выражены в коде.
Но если ТЗ гарантировано неизменно, то вы с таким подходом уместитесь в память, но разработка будет вестись очень долго, а тестирование будет невозможно автоматизировать.
Тут же явный самопал, а значит все должно быть сделано так, чтобы понять неправильно возможностей было минимум.
В стандарте C++ есть только один assert, и он никакого string не принимает.