Намедни был отчёт о CppCon, я решил напомнить, что у нас тоже жизнь кипит, пусть и не в таком масштабе.
Несколько раз я уже писал на Хабре про встречи C++ User Group. Многим в этом хабе я спамил в инбоксы приглашая их на встречи, надеюсь, без обид.
Скотт Мейерс — один из самых известных и признанных экспертов по C++, автор серии книг «Эффективное использование C++», которые читал почти каждый профессиональный разработчик на C++ и которые оказали заметное влияние на всю экосистему и качество использование языка.
Лично я стал почти его фанатом ещё студентом, когда в начале 2000-х читал статьи Скотта, лежащие в основе его книг (сами книги на тот момент в России ещё не были переведены, а на английские с Амазона у меня, как бедного студента, денег не было).
Поэтому, когда он некоторое время назад приехал в Яндекс, чтобы провести тренинг для наших разработчиков, я не мог не воспользоваться этим шансом, чтобы поговорить с ним. Разговор получился о том, каким он видит будущее C++ и программирования вообще, как отличаются разработчики в разных странах и в разных индустриях, и о нём самом.
Недавно в городе Белвью (штат Вашингтон) прошла одна из самых больших конференций С++ разработчиков — CppCon 2014. В течение пяти дней ведущие программисты таких компаний как Microsoft, Google, Dropbox, Citrix, Embarcadero, Ubisoft, разработчики стандарта языка, создатели компиляторов С++ и члены комьюнити opensource-продуктов представляли свои доклады, делились мнениями о будущем языка, предлагали новые идеи. Ниже я представлю выборку наиболее понравившихся мне видео с небольшими комментариями от себя. Хочется отметить, что вся конференция просто пропитана духом возрождения С++ в виду распространения стандартов С++11\14, люди рассказывают почему выбор С++ оказался для них верным, как они успешно мигрировали с C#\Java\Objective-C на С++ и не пожалели об этом и т.д.
Удачного просмотра!
Докладчики из Dropbox рассказывают о том, как они разрабатывают на С++ кроссплатформенные мобильные приложения.
Когда-то у Дропбокса были классические мобильные приложения: Java-код для Android и Objetive-C для iOs. Однако со временем команде разработчиков надоело писать одно и то же по 2 раза на разных языках и они пришли к выводу о необходимости создания общей кодовой базы на С++. Со временем оказалось, что какую бы архитектуру не имело приложение (MVC, MVVM или что-нибудь другое), фактически весь код кроме вьюх может быть вынесен в С++. Действительно, на С++ можно реализовать модель данных, контроллеры, бизнес-логику, вспомогательные библиотеки для работы с сетью, базами данных, парсингу и т.д. Всё, что остаётся на долю Java и Objective-C — нарисовать «родные» для данной платформы кнопки\списки\лейбы на вьюхах. И этот подход существенно более прагматичен, чем писать всё дважды.
Первое видео более обзорное, второе более практическое:
Этот текст можно рассматривать как обзор библиотеки Strutext, задуманной автором как набор эффективных алгоритмов лингвистической обработки текста на языке C++. Код библиотеки находится в репозитории на Github. Библиотека имеет открытый исходный код и поставляется под лицензией Apache License 2.0, т.е. может быть использована совершенно бесплатно без каких-либо существенных ограничений.
Разработка игр — постоянно актуальная тема: всем нравится играть в игры, их охотно покупают, поэтому их выгодно продавать. Но при разработке хороших игр следует обращать немало внимания на производительность. Никому не понравится игра, «тормозящая» или работающая рывками даже на не самых мощных устройствах.
В этой статье я покажу, как разработать простую футбольную 3D игру с использованием Microsoft DirectX и C++, хотя главным образом я занимаюсь разработкой на C#. В прошлом я довольно много работал с C++, но теперь этот язык для меня уже не столь прост. Кроме того, DirectX для меня является новинкой, поэтому эту статью можно считать точкой зрения новичка на разработку игр. Прошу опытных разработчиков простить меня за возможные ошибки.
В прошлый раз я описал начало моих отношений с обратной разработкой. Прошло еще немного времени и вот, в некоторой степени, результат моих исследований.
Я пытаюсь восстановить исходники по .dll-библиотеке и .pdb-базе. Использование IDA конечно принесло кое-какие результаты, но не удовлетворительные. Возможно я просто недостаточно усидчив. Поэтому я начал с другой стороны — с восстановления каркаса проекта библиотеки. Так как у меня есть .pdb-база я вполне могу это сделать. Теоретически. Теоретически, потому что в базу записывается информация с препроцессированых файлов, а не с исходников. А значит нужно работать дальше.
Несколько дней назад Бьёрн Страуструп опубликовал предложение N4174 комитету по стандартизации С++ названное "Call syntax: x.f(y) vs. f(x,y)". Вот вкратце его суть: объявить выражение x.f(y) (вызов для объекта х метода f с аргументом y) эквивалентным выражению f(x,y) (вызов функции f с аргументами x и y). Т.е.
x.f(y) означает:
Попробовать вызвать x.f(y): если класс объекта х содержит метод f, который может принять аргумент y — используем этот метод.
Если пункт №1 не удался — проверяем, существует ли функция f, которая может принять аргументы x и y. Если это так — используем её.
Если не найдено ни того, ни другого — генерируем ошибку.
f(x,y) означает ровно то же самое:
Попробовать вызвать x.f(y): если класс объекта х содержит метод f, который может принять аргумент y — используем этот метод.
Если пункт №1 не удался — проверяем, существует ли функция f, которая может принять аргументы x и y. Если это так — используем её.
Если не найдено ни того, ни другого — генерируем ошибку.
Таким образом мы получаем возможность писать методы расширения, о которых мечтали многие С++ программисты. Я считаю это предложение одним из самых важных в эволюции языка С++.
Если бы меня спросили, какая часть технической реализации игры «Цезарь» мне интересна больше других, я бы вспомнил о расчете одного «дня» городской жизни. Отдельные компоненты математической модели города тоже интересны в реализации, но эти «шестеренки» будут крутиться только в сборе. Большая часть игры проходит внутри «игрового цикла», в котором проводятся вычисления параметров компонентов, выполняются перемещения игровых объектов, создаются новые события и объекты. Если вам интересно узнать, как была устроена симуляция города в одной из лучших игр 1998 года — добро пожаловать под кат. Описания, псевдокод и схемы помогут вам лучше узнать об используемых алгоритмах.
Полное оригинальное название статьи: «Why your first FizzBuzz implementation may not work: an exploration into some initially surprising but great parts of Rust (though you still might not like them)»
tl;dr;-версия: На первый взгляд некоторые аспекты Rust могут показаться странными и даже неудобными, однако, они оказываются весьма удачными для языка, который позиционируется как системный. Концепции владения (ownership) и времени жизни (lifetime) позволяют привнести в язык сильные статические гарантии и сделать программы на нём эффективными и безопасными, как по памяти, так и по времени.
Почему ваша первая реализация FizzBuzz может не работать: исследование некоторых особенностей Rust, которые изначально шокируют, но в действительности являются его лучшими сторонами (хотя они всё равно могут вам не понравиться)
FizzBuzz предполагается как простое задание для новичка, но в Rust присутствуют несколько подводных камней, о которых лучше знать. Эти подводные камни не являются проблемами Rust, а, скорее, отличиями от того, с чем знакомо большиство программистов, ограничениями, которые на первый взгляд могут показаться очень жёсткими, но в действительности дают громадные преимущества за малой ценой.
Rust это «подвижная мишень», тем не менее, язык становится стабильней. Код из статьи работает с версией 0.12. Если что-то сломается, пожалуйста, свяжитесь со мной. Касательно кода на Python, он будет работать как в двойке, так и в тройке.
Не прошло и года, как я добрался до продолжения статьи про асинхронность. Эта статья развивает идеи той, самой первой статьи про асинхронность [1]. В ней обсуждается достаточно сложная задача, на примере которой будет раскрыта мощь и гибкость использования сопрограмм в различных нетривиальных сценариях. В заключение будут рассмотрены две задачи на состояние гонки (race-condition), а также небольшой, но очень приятный бонус.
Сегодня достаточно необычный день, не правда ли? Как часто на Хабре появляются статьи про персистентные структуры данных? И именно сегодня я желаю вам рассказать про незаслуженно забытую персистентную дерамиду по неявному ключу. Итак, начнем.
Мне предложили проверить библиотеки, входящие в Visual Studio 2013. Ничего особенно примечательного я не нашёл. Только несколько мелких ошибок и недочётов. Интригующую статью из этого не сделаешь, но я всё равно опишу замеченные недостатки. Надеюсь, это сделает библиотеки чуть лучше, и подвигнет авторов провести более тщательную проверку. У меня нет файлов проектов для сборки библиотек. Поэтому я проверял файлы кое-как, и много могло быть пропущено.
В качестве небольшой разминки перед статьёй хотелось бы, чтобы читатель задал себе следующий вопрос: нужно ли фотографу для получения качественных снимков знать, как работает фотоаппарат? Ну, по крайней мере, должен ли он знать понятие «диафрагма»? «Отношение сигнал-шум»? «Глубина резкости»? Практика подсказывает, что даже со знанием таких сложных слов снимки могут получиться у наиболее «рукастых» не особо лучше снятых на мобильник через 0.3-МПикс-дупло. И наоборот, по-настоящему хорошие снимки могут получаться благодаря исключительно опыту и наитию при полном незнании матчасти (хотя это, скорее, исключения из правил, но всё же). Однако вряд ли со мной кто-то будет спорить, что профессионалам, которые хотят выжать из своей техники всё (а не только количество мегапикселей на квадратный миллиметр матрицы), эти знания нужны в обязательном порядке, поскольку в противном случае ему и называться профессионалом-то нельзя. И верно это не только для отрасли цифровой фотографии, но и для практически любой другой.
Верно это и для программирования, а для программирования на языке С++ – вдвойне. В этой статье будет описано важное понятие языка, известное как «Виртуальный табличный указатель», что присутствует почти во всех сложных классах, и то, каким образом его можно случайно повредить. Это может, в свою очередь, вести к едва поддающимся отладке ошибкам. Сначала напомню, что это вообще такое, а затем и поделюсь своими соображениями по поводу того, как и что может там сломаться.
Приветствую Хабр! Многие из нас наверняка задумывались «а не написать ли мне игру самому». Сейчас я веду проект «Open tomb» — попытка создать переносимый движок для игры в первые 5 частей «Tomb raider», который выложен на sourceforge.com, однако, судя по своему опыту, многим будет интересна история с некоторыми деталями о том, как движок писался с нуля и с практически отсутствующими знаниями в этой области. Даже сейчас многих знаний не хватает, а иногда просто не хватает мотивации что-то сделать лучше, или правильнее, однако лучше перейти к тому, как все же проект оживал шаг за шагом.
Как-то, анализируя дефект в разрабатываемом продукте, я наткнулся на архитектурную особенность менеджера памяти, который мы использовали. Дефект приводил к увеличению времени создания некоторых объектов. Особенность архитектуры заключалась в использовании паттерна Singleton при работе с менеджером памяти (далее X allocator). Схематично это выглядит так:
Рисунок 1 – Структурная схема работы X allocator
Из схемы видно, что доступ к глобальной куче защищен мьютексом. Такая архитектура, при интенсивном создании однотипных объектов из нескольких потоков, может привести к тому, что потоки будут вставать в очередь на этом мьютексе. А ведь одна из главных особенностей продукта – это возможность его масштабирования за счет увеличения количества потоков обработки (потоков выполняющих одинаковые действия). Поэтому такой подход потенциально может стать узким местом.
Мой телеграм канал: https://t.me/winc0de.
В этой статье мы рассмотрим несколько видов взрывов в физическом движке Box2D.
Симуляция взрыва сводится к нахождению тел, которые находятся в радиусе действия взрывной волны и применении силы к ним, чтобы отбросить их от центра взрыва.
Мы расмотрим три вида взрывов разной сложности:
Нахождение тел в радиусе взрыва
Raycast – нахождения тел в радиусе лучей
Частицы – распространение многих маленьких тел от эпицентра взрыва
KDE (сокращение от K Desktop Environment) — среда рабочего стола, преимущественно для Linux и других UNIX-подобных систем. Если простым языком, то это та штука, которая отвечает за всё графическое оформление. Среда построена на основе кроссплатформенного инструментария разработки пользовательского интерфейса Qt. Разработкой занимаются несколько сотен программистов со всего мира, преданных идее свободного программного обеспечения. KDE предлагает полный набор приложений пользовательского окружения, который позволяет взаимодействовать с операционной системой в современном графическом интерфейсе. Давайте же посмотрим, что у KDE под капотом.
Хочу поделиться своим опытом разработки метасистемы для C++ и встраивания различных скриптовых языков.
Сравнительно недавно начал писать свой игровой движок. Разумеется, как и в любом хорошем движке встал вопрос о встраивании скриптового языка, а лучше даже нескольких. Безусловно, для встраивания конкретного языка уже есть достаточно инструментов (например, luabind для Lua, boost.python для Python), и свой велосипед изобретать не хотелось.
Folly — это открытая С++ библиотека, разрабатываемая Facebook и используемая им во внутренних проектах. С целью оптимизации расходов памяти и процессорных ресурсов библиотека включает собственные реализации некоторых стандартных контейнеров и алгоритмов. Одной из них является folly::fbvector — замена стандартного вектора (std::vector). Реализация от Facebook полностью совместима с оригинальным интерфейсом std::vector, изменения всегда не-негативны, почти всегда измеримы, часто — существенно, а иногда даже грандиозно влияют на производительность и\или расход памяти. Просто включите заголовочный файл folly/FBVector.h и замените std::vector на folly::fbvector для использования его в своём коде.
Пример
folly::fbvector<int> numbers({0, 1, 2, 3});
numbers.reserve(10);
for (int i = 4; i < 10; i++) {
numbers.push_back(i * 2);
}
assert(numbers[6] == 12);
Мотивация
std::vector — устоявшаяся абстракция, которую многие используют для динамически-аллоцируемых массивов в С++. Также это самый известный и самый часто используемый контейнер. Тем большим сюрпризом оказывается то, что его стандартная реализация оставляет достаточно много возможностей по улучшению эффективности использования вектора. Этот документ объясняет, как реализация folly::fbvector улучшает некоторые аспекты std::vector. Вы можете воспользоваться тестами из folly/test/FBVectorTest.cpp чтобы сравнить производительность std::vector и folly::fbvector.
FizzBuzz предполагается как простое задание для новичка, но в Rust присутствуют несколько подводных камней, о которых лучше знать. Эти подводные камни не являются проблемами Rust, а, скорее, отличиями от того, с чем знакомо большиство программистов, ограничениями, которые на первый взгляд могут показаться очень жёсткими, но в действительности дают громадные преимущества за малой ценой. 
Мне предложили проверить библиотеки, входящие в Visual Studio 2013. Ничего особенно примечательного я не нашёл. Только несколько мелких ошибок и недочётов. Интригующую статью из этого не сделаешь, но я всё равно опишу замеченные недостатки. Надеюсь, это сделает библиотеки чуть лучше, и подвигнет авторов провести более тщательную проверку. У меня нет файлов проектов для сборки библиотек. Поэтому я проверял файлы кое-как, и много могло быть пропущено.
В качестве небольшой разминки перед статьёй хотелось бы, чтобы читатель задал себе следующий вопрос: нужно ли фотографу для получения качественных снимков знать, как работает фотоаппарат? Ну, по крайней мере, должен ли он знать понятие «диафрагма»? «Отношение сигнал-шум»? «Глубина резкости»? Практика подсказывает, что даже со знанием таких сложных слов снимки могут получиться у наиболее «рукастых» не особо лучше снятых на мобильник через 0.3-МПикс-дупло. И наоборот, по-настоящему хорошие снимки могут получаться благодаря исключительно опыту и наитию при полном незнании матчасти (хотя это, скорее, исключения из правил, но всё же). Однако вряд ли со мной кто-то будет спорить, что профессионалам, которые хотят выжать из своей техники всё (а не только количество мегапикселей на квадратный миллиметр матрицы), эти знания нужны в обязательном порядке, поскольку в противном случае ему и называться профессионалом-то нельзя. И верно это не только для отрасли цифровой фотографии, но и для практически любой другой.
