Введение

Я математик-программист. Самый большой скачок в своей карьере я совершил, когда научился говорить:«Я ничего не понимаю!» Сейчас мне не стыдно сказать светилу науки, что мне читает лекцию, что я не понимаю, о чём оно, светило, мне говорит. И это очень сложно. Да, признаться в своём неведении сложно и стыдно. Кому понравится признаваться в том, что он не знает азов чего-то-там. В силу своей профессии я должен присутствовать на большом количестве презентаций и лекций, где, признаюсь, в подавляющем большинстве случаев мне хочется спать, потому что я ничего не понимаю. А не понимаю я потому, что огромная проблема текущей ситуации в науке кроется в математике. Она предполагает, что все слушатели знакомы с абсолютно всеми областями математики (что абсурдно). Признаться в том, что вы не знаете, что такое производная (о том, что это — чуть позже) — стыдно.

Но я научился говорить, что я не знаю, что такое умножение. Да, я не знаю, что такое подалгебра над алгеброй Ли. Да, я не знаю, зачем нужны в жизни квадратные уравнения. К слову, если вы уверены, что вы знаете, то нам есть над чем поговорить! Математика — это серия фокусов. Математики стараются запутать и запугать публику; там, где нет замешательства, нет репутации, нет авторитета. Да, это престижно говорить как можно более абстрактным языком, что есть по себе полная чушь.

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

Copy elision (пропуск копии) — оптимизация, заключающаяся в том, что компилятор может избавиться от вызова «лишних» конструкторов копирования.

Язык С++ по сей день является одним из самых востребованных и гибких языков программирования. Но иногда возможностей языка не хватает, несмотря на то что стандарт развивается и расширяется. С такой проблемой столкнулся и я в процессе разработки 2D движка для игр. Я стоял перед необходимостью решения несколько нетривиальных задач, таких как сериализация, анимирование и связка с редактором. Для этого отлично подходит рефлексия. Готовые решения из сети, к сожалению, мне не подошли, поэтому пришлось конструировать свой велосипед.

Далее описаны детали реализации и демо проект. Кому интересно — добро пожаловать под кат.

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

• — приведу алгоритм,
• — расскажу, как его интерпретирует «Автор»,
• — покажу, во что он превращается,
• — немного расскажу про автоматическое самообучение и ИИ,
• — посмеюсь над собой.

Шаблонный метод

Когда приходится спрашивать человека, какие паттерны проектирования ему доводилось использовать, почему-то мало кто называет паттерн «Шаблонный метод» (Template Method). Вероятно, это связано с пробелом в знании номенклатуры паттернов, ибо лично я с трудом представляю себе, чтобы более-менее опытный программист ни разу не использовал такой удобный и полезный паттерн. Предлагаю ещё раз взглянуть на него поближе.

Итак, шаблонный метод.

В интерпретаторе «Автор» существует три отличных от других, классических, языков типа данных, про которых я хочу рассказать в этой статье, а именно «digit», «graf» и «program». Они отвечают, соответственно, за астрономические числа без плавающей точки, универсальный граф и дерево операторов и вызовов функций с переменными и константами.

Следующий пример демонстрирует основное отличие типа «digit» от типа «int».

К сожалению, все самообучающиеся алгоритмы достаточно сложны и объёмны. Логика самообучения алгоритма по-прежнему остаётся задачей программиста. Но, не смотря на это, я приведу пример классической задачи на самообучение.
Задача состоит в том, чтоб дать ответ, является ли заданное число простым. На первый взгляд ничего особенного. Но проблема заключается в том, что для того, чтобы дать правильный ответ, нужно найти заданное число в ряде простых чисел. Другого способа просто не существует. А этот ряд бесконечный. Разумеется, мы можем задать в памяти только ограниченный отрезок ряда, и получается, что как не крути, а заданное число может превышать ограничение. Конечно, вы скажите, что ряд легко продолжить. Да, вы абсолютно правы. Но с точки зрения оптимизации работы программы, по времени, неудобно каждый раз вычислять одно и тоже, а лучше сохранять массив простых чисел, каждый раз при дополнении его. Собственно в этом и заключается мера обучения этой классической задачи. С точки зрения классического программирования нам нужно организовать хранилище для содержания массива известных простых чисел, например в отдельном файле, или в базе данных. Но опираясь на возможность языка «Автор» вносить изменения программ в собственный код можно сделать такое хранилище прямо внутри кода программы.

9 февраля компания Amazon представила и выложила в открытый доступ бета-версию своего 3D-движка Lumberyard.

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

Если вы регулярно пишете на C++ с использованием сторонних библиотек (окромя boost) и вам надоело постоянно прописывать пути до папок с заголовочниками и lib-ами, то под катом вы найдете один из способов несколько это дело автоматизировать.

Всякий раз, начиная небольшой проект ConsoleApplication в VisualStudio, дабы опробовать пришедшую в голову идею, я испытываю боль. Боль от постоянных настроек в разделах Properties->C/C++->General->Additional Include Directories и Properties->Linker->General->Additional Library Directories.

Если в Solution-е 1-3 проекта и пара сторонних библиотек, то все еще терпимо, но для >10 проектов и > 5 библиотек все выглядит по-другому. И когда однажды мое терпение лопнуло, я решил как-то это дело автоматизировать. Взяв за основу систему для boost-а, стал выпиливать свой велосипед. Что хотелось получить от решения:

1. Подключение сторонних библиотек путем прописывания 2-х уровневого include-a, включающего имя библиотеки, например

   #include <gtest/gtest.h>
   #include <vsqlite/connection.hpp>
   

   
   
2. Автоматическая линковка соответствующих *.lib файлов при подключении *.hpp файла
3. Поддержка x86/x64, Debug/Release, Static/Dynamic Runtime
4. Возможность быстрого переноса на другую машину

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

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

enum Suit { Spades, Hearts, Diamonds, Clubs };

Обычно решение данной задачи базируется на дублировании значений, например, внутри switch-а:

switch(value)
{
    case Spades:   return "Spades";
    case Hearts:   return "Hearts";
    case Diamonds: return "Diamonds";
    case Clubs:    return "Clubs";
    default:       return ""
};

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

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

Далее в статье я опишу способ, позволяющий организовать рефлексию для enum-ов. Кому интересно — добро пожаловать под кат.

Имеется типична ситуация:

• кем-то написанное приложение на Qt;
• пользователи жалуются, что программа во время работы жрем много CPU;
• профилировщик и strace указывают на то, что происходит насилование базы.

В такой ситуации хочется посмотреть что за запросы, их количество, время выполнения. Если в PostgreSQL есть pg_stat_statements и pgBadger, то для SQLite пришлось написать свой самокат. Самокат представляет из себя вызов sqlite3_profile для каждого соединения, запись полученной информации в журнал.

Многие считают, что неопределённое поведение программы возникает из-за грубых ошибок (например, запись за границы массива) или на неадекватных конструкциях (например, i = i++ + ++i). Поэтому для многих является неожиданностью, когда неопределенное поведение вдруг проявляет себя во вполне привычном и ничем не настораживающем коде. Рассмотрим один из таких примеров. Программируя на C/C++ никогда нельзя терять бдительность. Ад ближе чем кажется.

Выбор инструмента

Проблема профилировки рано или поздно встает перед любым проектом, претендующим на роль лучшего в своей области. Какой инструмент выбрать — всегда большой вопрос. Одни инструменты показывают одну часть картины, другие другую. И рано или поздно начинаешь писать свой тул (англ. tool — орудие\инструмент), который отвечает на насущные проблемы именно данного конкретного проекта. Однако время на написание своего «орудия» всегда приходится вычитать из времени отведенного на сам проект.
Поэтому серьезный профайлер написать не получается…

Но как получить все и сразу? (Тут мне почему то вспоминается песня Queen «I want it all»)

Unity продолжают совершенствовать технологию IL2CPP, а мы публикуем перевод статьи о том, как она работает.

17 сентября 2015 в Москве состоялась очередная ежегодная конференция Intel Software Conference. Программа конференции включала общие выступления (вступительное слово, обзор технологий компании для разработчиков, истории успеха клиентов Intel) и две параллельные сессии: первая была посвящена оптимизации кода и параллельным вычислениям, вторая касалась вопросов мобильной разработки и медиа.

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

Microsoft выложила в открытый доступ исходный код инструментов, которые используются в компании для ускорения разработок в области искусственного интеллекта: набор Computational Network Toolkit теперь доступен на Github. Разработчикам пришлось создать собственное решение, так как имеющиеся инструменты работали слишком медленно. Давайте же взглянем на результаты проверки этого проекта статическим анализатором кода.

В данной статье описывается стандарт JSON Schema и его использование для проверки соответствия заданному формату на языке C++ средствами библиотеки valijson.

Немного истории

Для начала вспомним, что привело к повсеместному вытеснению JSON-ом XML-а и что в этом было плохого. XML изначально создавался как метаязык разметки документов, позволяя использовать унифицированный код парсера и валидатора документов. Будучи первым стандартом такого рода, да еще и пришедшимся на период бурного внедрения цифровых корпоративных информационных систем, XML послужил основой для бесчисленного множества стандартов сериализации данных и протоколов взаимодействия, т.е. хранения и передачи структурированных данных. Тогда как создавался он прежде всего для разметки документов.

Здравствуйте, дорогие читатели!

У нас активно расходится третий доптираж крайне успешной книги «Изучаем C++ через программирование игр». Поэтому сегодня вашему вниманию предлагается перевод интересной статьи на одну из узких тем, связанных с программированием игр на C++. Также просим вас поучаствовать в опросе