Почему в 2024 году нам приходится писать каст енума к строке вручную, для каждого кастомного типа нужна своя функция логирования, а биндинги к C++ библиотеке требуют кучу повторяющегося кода?

Если Вы задавались этими, или подобными вопросами, то у меня для вас хорошая новость - скоро эти проблемы будут решены. И что самое приятное - на уровне языка, а не нестандартным фреймворком.

Сегодня рассматриваем пропозалы рефлексии, которые с большОй вероятностью попадут в следующий стандарт - C++26.

Привет, Хабр! К сегодняшнему дню написано уже немало учебников и статей по полиморфизму в целом и его воплощения в C++ в частности. Однако, к моему удивлению, при описании полиморфизма никто (или почти никто) не затрагивает тот факт, что помимо динамического полиморфизма в C++ имеется и достаточно мощная возможность использования его младшего брата – полиморфизма статического. Более того, он является одной из основных концепций STL – неотъемлемой части его стандартной библиотеке.

Поэтому в данной статье мне хотелось бы хотя бы в общих чертах рассказать о нём и его отличиях от всем известного динамического полиморфизма. Надеюсь, эта статья будет интересна для тех, кто только начал изучать принципы ООП, и они смогут посмотреть на его “третьего слона” с новой стороны.

Или почему мне кажется, что про них нужно знать, но не нужно использовать в своей каждодневной работе.

В данной статье я опишу свои самые свежие и яркие впечатления от многопоточного программирования. Это мои впечатления, мой опыт  и я буду рад, если он будет полезен другим программистам.

В крайней статье я утверждал, что более серьезные проблемы их поджидают в случае взаимодействующих потоков. Но одно  эти проблемы предполагать или даже предсказывать, а другое - столкнуться с ними непосредственно.

Предсказанное сбылось, как говорится, по полной программе. Думаю, что озвученные далее проблемы для кого-то не станут новостью, но будут и те, кто о них не подозревает, как не подозревал и я. А потому захотелось их зафиксировать и поделиться, с чем пришлось столкнуться.  Ну, и рассказать, как я выкрутился, попав в не совсем привычные для меня ситуации (в автоматном программировании, подчеркну, они не возникли бы в принципе).

Итак, создав ранее тест потоков (о нем подробнее см. [1]), гоняя его многократно и в разных режимах, я заметил, что пусть редко, но выскакивают некорректные результаты. В подобных случаях я грешу обычно на себя. А в данном случае тем более, т.к., что там скрывать, имею весьма небольшой опыт использования потоков.

Но в процессе экспериментов обнажились проблемы, которые сложно списать на недостаток опыты. Что-то при этом удалось преодолеть сразу, с чем-то пришлось повозиться, но были и те проблемы, которые не удалось поправить, даже при наличии достаточно большого опыте в программировании вообще.  О последнем, не об опыте, конечно, а о проблемах, и пойдет далее речь... И даже не о проблемах, а о довольно нежданных и негаданных "засадах", возникших на пути освоения многопоточности.

Дальше будут оговорки. Тем не менее я думаю, что многие не ждут угрозы со стороны, о которой пойдёт речь. Начну издалека, но постараюсь быть кратким.

Ко мне обратился владелец взломанного telegram аккаунта с просьбой о помощи. В его аккаунт вошёл злоумышленник, завершил сессии на устройствах владельца, и начал играть в фишинг с его контактами. Выбросить злоумышленника из аккаунта не удалось, поскольку его сессия стала самой продолжительной, и он постоянно завершал все новые сессии. Также нельзя было удалить аккаунт, поскольку telegram "по причинам безопасности" не дал удалить аккаунт в текущий момент, а только лишь запустил таймер, который удалит аккаунт через 7 дней. К сожалению, лучшее, чем можно было сделать оперативно - это предупредить контакты по не скомпрометированному каналу о том, что telegram аккаунт был взломан.

Но мы решили провести небольшой анализ, чтобы понять, каким образом аккаунт был взломан и пришли вот к чему:

Стандартная процедура входа в telegram:

Данная статья описывает конкретный экземпляр вируса, который обитает на компьютерах под Windows с точки зрения его работы. Посмотрим как он устроен и внедряется в систему и как его найти и удалить вручную, если нет антивируса и интересно покопаться.

Разрабатывая различные приложения, я часто сталкиваюсь с тем, как после очередного коммита, в репозитории я вижу один из важнейших файлов, когда я работаю с переменными окружениями, оказалась на странице репозитория на Github. Речь идет о файле .env, чья общедоступность может быть очень опасным. И для того, чтобы обезопасить хранение конфигурационных переменных и настроек моего приложения, используется данный текстовый файл.

Я работаю на VS Code, и я, to be honest, так и не понял, с какой стати .gitignore "не игнорирует" .env. Причем спокойно "игнорирует" другие файлы, директории.

Всё же, нужно действовать, исходя из конкретного кейса, но если вы не хотите, чтобы какой-нибудь John Doe воспользовался данными из вашего .env, то вы перешли по верной ссылке. Вы же не отдаете ключи грабителю с фразой "Грабьте мой дом", верно?

Сделать свои первые шаги в мире разработки игр совсем непросто. В этой статье мы расскажем об основах программирования игр, а также о том, какие инструменты и ресурсы вы можете использовать для начала работы.

Привет, Хабр!

Задумывались ли вы когда-нибудь, что вашему коду стоило бы пройти сеанс психотерапии? В C++ это возможно благодаря такой замечательной штуке, как рефлексия. Она позволяет вашему коду буквально видить в зеркале себя и понимать свои ошибки и достоинства.

Итак, рефлексия — это процесс, при котором программа может инспектировать и изменять структуру и поведение во время выполнения.

Рефлексия в C++ бывает двух основных типов: компиляционная и рефлексия времени выполнения. Оба типа имеют свои особенности и применяются в различных сценариях.

Некоторые вредные привычки слишком хороши, чтобы от них отказываться — особенно если из них можно извлечь пользу. Рассказываем о десяти вроде как плохих привычках, которые разработчики не готовы бросить.

В этой статье мы рассмотрим, как правильно разрушать объекты в ООП программе на языке C++, не выполняя избыточных операций. Этим мы завершим цикл публикаций, посвящённый обзору ошибок в игровом движке qdEngine.

Часть 1

Обобщённые системы не приводят к интересному геймплею

Для предотвращения многих проблем очень часто рекомендуют повышать обобщённость при помощи систем. Якобы если использовать компоненты, разделённые на мелкие части, а также продуманные системы, то всех проблем с особыми случаями можно избежать.

Это сильный аргумент, на который почти нечем ответить, за исключением того, что обобщённые системы приводят к скучному геймплею. Я был довольно активен в сообществе разработчиков игр на Rust, поэтому видел множество проектов, которые создают другие; разумеется, предлагаемые ими рекомендации коррелируют с теми играми, которые они создают. Люди, которые склонны создавать красиво спроектированные системы, работающие полностью обобщённо, обычно создают не совсем игры, а симуляции того, что со временем станет игрой; в таких симуляциях геймплеем часто считается даже нечто типа «у меня есть персонаж, который может двигаться».

Предисловие: этот пост представляет собой очень длинный перечень мыслей и проблем, возникавших у меня за годы работы; также в нём рассматриваются некоторые из аргументов, которые мне часто говорили. В посте выражено моё мнение, сформировавшееся у меня в процессе разработки игр на Rust в течение многих тысяч часов на протяжении многих лет и после множества завершённых игр. Это не хвастовство и не показатель успеха, я просто хочу сказать, что вложил достаточно много усилий в Rust; здесь не получится сказать «когда наберёшься опыта, тебе всё станет понятно».

Пост не будет ни научной оценкой, ни A/B-исследованием. Это моё личное мнение после разработки игр на Rust маленькой инди-командой (два человека) в попытках заработать достаточно денег, чтобы финансировать процесс. Мы не одни из тех разработчиков с бесконечными финансами от инвестора и многолетним запасом времени. Если вы находитесь в этой категории и получаете удовольствие от многолетней разработки систем, то всё написанное ниже к вам не относится. Я рассматриваю всё с такой точки зрения: «Мне хочется создать игру максимум за 3-12 месяцев, чтобы люди могли сыграть в неё, а я — немного заработать». Статья не написана с точки зрения «Я хочу изучить Rust, а разработка игр — это весело», хотя это и вполне нормальная цель; просто она никак не согласуется с тем, чего хотим мы — заниматься разработкой игр коммерчески успешным и самодостаточным образом.

Мы выпустили несколько игр на Rust, Godot, Unity и Unreal Engine, и многие люди сыграли в них в Steam. Мы создали с нуля собственный игровой 2D-движок с простым рендерером, а также в течение нескольких лет использовали Bevy и Macroquad во многих проектах, некоторые из которых были очень нетривиальными. Кроме того, я бэкенд-разработчик на полную ставку и пишу код на Rust. Этот пост — не какое-то поверхностное мнение после изучения нескольких туториалов или разработки небольшой игры для геймджема. За три с лишним года мы написали сильно больше ста тысяч строк кода на Rust.

Задача этого поста — развеять популярные и часто повторяемые аргументы. Но это всё-таки субъективное мнение; по большей части я написал пост, чтобы не объяснять снова и снова одно и то же. Пусть это будет справочный материал о том, почему мы, скорее всего, откажемся от Rust как от инструмента для разработки игр. Мы ни в коем случае не планируем прекращать создавать игры, просто не будем делать это на Rust.

Привет, Хабр! На связи Виталий Киреев, руководитель R&D SpaceWeb. Это первая часть статьи про веб-безопасность — здесь я расскажу про главные уязвимости Server Side, покажу примеры и объясню, как защищать данные. 

Собственно ответка на указанную статью.

Решил ответить на претензии автора. А так же рассказать, почему С\С++ именно такой какой есть. Почему приняты такие решения при его создании и развитии. Указать на явные недостатки Rust'а и его инфраструктуры. Язык не может существовать сам по себе. Он должен иметь не только токсичное сообщество, но и быть нужным работодателю.

В мире компьютерных наук мало что может сравниться с созданием собственной операционной системы. В этой статье мы погрузимся в увлекательный мир разработки операционных систем, создав 16-битную ОС с помощью языка ассемблера NASM под архитектуру процессоров Intel x86-64. Мы рассмотрим каждый этап разработки, начиная с основ и заканчивая реализацией ключевых компонентов.