Привет, хабровчане. В связи со стартом набора в новую группу по курсу «Разработчик C++», делимся с вами переводом второй части статьи «Лямбды: от C++11 до C++20». Первую часть можно прочитать тут.



В первой части серии мы рассмотрели лямбды с точки зрения C++03, C++11 и C++14. В этой статье я описал побуждения, стоящие за этой мощной фичей C++, базовое использование, синтаксис и улучшения в каждом из языковых стандартов. Я также упомянул несколько пограничных случаев.
Теперь пришло время перейти к C++17 и немного заглянуть в будущее (очень близкое!): C++20.

Автор материала, перевод которого мы сегодня публикуем, говорит, что C++, в его современном виде, если сравнивать его с тем, чем был этот язык несколько лет назад, значительно изменился в лучшую сторону. Конечно, эти изменения произошли далеко не сразу. Например, в былые времена C++ не хватало динамичности. Непросто было найти человека, который мог бы сказать, что он питает к этому языку нежные чувства. Всё изменилось тогда, когда те, кто отвечает за стандартизацию языка, решили дать ход новшествам. В 2011 году C++ стал динамическим языком, языком, который постоянно развивается и вызывает у программистов куда больше положительных эмоций.

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



Сегодня мы поговорим о некоторых новых возможностях языка (начиная с C++ 11, которому, кстати, уже 8 лет), знать о которых будет полезно любому программисту.

Игровой процесс может быть очень сложной задачей. Некоторые игры, например, «Змеи и лестницы», достаточно прямолинейны, однако такие игры, как SpaceChem и Factorio могут быть невероятно сложной проверкой работы мозга.

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

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

В C# есть делегаты. В python есть делегаты. В javascript есть делегаты. В Java есть выполняющую их роль замыкания. А в C++ делегатов нет O_O. Многие талантливые программисты успешно борются с этим недостатком, разрабатывая и используя sigslots, boost::function и другие ценные и нужные библиотеки. К сожалению, большинство реализаций отличаются не только методом использования, но также эпической сложностью применяемой шаблонной магии. Дабы при изучении исходников boost::function волосы не вставали дыбом, я написал эту небольшую статью, показывающую как самым простым и топорным способом реализовать делегат на C++. Описанная реализация является иллюстративной, имеет множество недостатков и ее вряд ли можно применить в серьезных проектах — зато она максимально простая и позволяет ознакомиться с предметной областью не разбирая трехэтажные шаблоны sigslots :).

На днях прошла встреча международного комитета по стандартизации C++ в Кёльне. В прошлый раз был принят feature freeze на C++20, так что комитет должен был обсуждать только исправления уже принятых вещей, а добавлять новинки уже в C++23…

… но всё было не так!



Что сделали с std::flat_map; останутся ли страшные ключевые слова co_return, co_await и co_yield; успели ли доделать std::format; в каком виде будут контракты в C++20? Всё это вас ждёт под катом.

Здравствуйте, коллеги.

Не так давно наше внимание привлекла почти готовая книга издательства Manning «Programming with types», подробно рассматривающая важность правильной типизации и ее роль при написании чистого и долговечного кода.



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

У WG21 есть строгий график (см. P1000) выпуска стандарта каждые три года. И никаких задержек.

В течение каждого цикла мы регулярно получаем вопросы «ну почему так строго?», особенно от новых участников комитета, которые не знакомы с его историей и причинами текущего положения вещей. И во время предварительной телеконференции с администрацией Кёльна несколько человек порекомендовали описать, почему мы так делаем и как принималось решение о принятии этого графика.

Всё это я расписал в виде вопросов и ответов для следующего черновика Р1000, и разослал копию участникам комитета, направлявшимся в Кёльн. Этот материал будет опубликован в следующей публичной версии Р1000, её мы разошлём через несколько недель начиная с текущего момента.

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

Как можно более равномерное распределение точек на сфере — невероятно важная задача в математике, науке и компьютерных системах, а наложение сетки Фибоначчи на поверхность сферы при помощи равновеликой проекции — чрезвычайно быстрый и эффективный метод аппроксимации для её решения. Я покажу, как благодаря незначительным изменениям его можно сделать ещё лучше.


Какое-то время назад этот пост появился на главной странице Hacker News. Его обсуждение можно прочитать здесь.

Введение

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

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

• Упаковка и покрытие
• Выпуклые оболочки, ячейки Вороного и треугольники Делоне
• Ядра $$-энергии Риса
• Кубатура и определители

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

Ради краткости в этом посте мы рассмотрим только два критерия: минимальное расстояние упаковки и выпуклую оболочку/сетку Делоне (объём и площадь).

В прошлый раз, мы использовали SFINAE, чтобы понять, есть ли у типа определение, и мы использовали это в сочетании с if constexpr и универсальными лямбда-выражениями, чтобы код мог использовать тип, если он определен, при этом все еще принимаясь компилятором (и отбрасываясь) если тип не определен.

Однако в этом применении существует несколько проблем:

• Каждый раз нужно писать struct.
• Если тип не существует, то при присвоении ему имени этот тип вводится в текущее пространство имен, а не в пространство имен, в котором вы хотели, чтобы тип был.
• Нужно использовать struct с неквалифицированным именем. Нельзя использовать его для проверки типа, который вы не импортировали в текущее пространство имен.

Мы можем исправить все три проблемы с помощью одного решения: предварительно объявить тип в нужном пространстве имен.

Здравствуйте, коллеги.

Мы не смогли пройти мимо этой статьи и с радостью предлагаем вам ее перевод. Поскольку в будущем году у нас большие планы по геймдизайну и разработке игр, считаем, что здесь рассмотрены принципиальные вопросы, которые многим подскажут, как разрабатывать игры правильно, и куда двигаться дальше.

Основные задачи художников визуальных эффектов

Если говорить только о визуальных эффектах, то их можно разделить на два основных типа задач: геймплейные эффекты и природные эффекты (или эффекты окружений). Принцип их разделения зависит от конкретного проекта. Например в такой игре, как Castlevania (жанра hack'n'slash), 90% визуальных эффектов состояло в умениях персонажа и магии, сильно влиявших на геймплей. Такие задачи требуют серьёзного понимания механик игры и постоянного общения с командой дизайнеров, с которой нужно постоянно договариваться. Для примера давайте возьмём огнемёт. Дизайнеры геймплея подбирают область урона атаки, а затем вам необходимо создать эффект поверх отладочного цилиндра. Постепенно уменьшающийся огонь не полностью соответствует области урона, и дизайнеры начинают на это жаловаться. Вот один из примеров «конфликтов» между двумя дисциплинами, потому что если придерживаться строгих правил, огонь не будет похож на огонь. Поэтому приходится искать альтернативы и убеждать дизайнеров, что игрок не заметит, что небольшой исчезающий огонь не нанёс никакого урона.

Среди прочих жанров, геймплейные эффекты более «важны» в файтингах и RPG.

Существуют и другие игровые жанры, например, шутеры (в особенности это касается реалистичных), в которых природные эффекты так же важны, как и геймплейные. В этом случае художник, ответственный за природные эффекты, становится практически художником по окружениям и в основном сотрудничает с этой командой. Примерами природных эффектов являются водопады, туман, дождь и т.д. Больше всего природных эффектов я создал в Gears of War 4, где мы работали над многопользовательскими картами и должны были заботиться о влиянии эффектов на производительность, потому что от игры требовалось работать в 1080p при 60 fps.

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

Года полтора назад я выкладывал на Хабр цикл видеолекций с моим видением того как работает мозг и каковы возможные пути создания искусственного интеллекта. За прошедшее с тех пор время удалось существенно продвинуться вперед. Что-то получилось глубже понять, что-то удалось смоделировать на компьютере. Что приятно, появились единомышленники, активно участвующие в работе над проектом.

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