Удивлен, что ссылки на Advent of Code до сих пор не видно на Хабре.



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

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

От переводчика:

Данная публикация является продолжением материала «Как происходит рендеринг кадра в GTA V». Теперь автор рассматривает вопросы детализации, освещения и пост-обработки кадра. Приятного чтения.

Уровень детализации

Если мы говорим об абсолютных преимуществах Rockstar над конкурентами, то показатели уровня детализации продуктов компании, определенно, выше всяких похвал. Лос-Сантос – это целая плеяда всевозможных сцен разной степени детализации/полигональности, причем все данные транслируются в режиме реального времени и это ни на минуту не блокирует экран загрузки. Просто дух захватывает!

Огни ночного города

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

Именно с таким заявлением Аарон Гарбут, один из основателей и арт-директоров Rockstar North, выступил незадолго до релиза игры на PS3.

Так ли это? Давайте рассмотрим вот такую ночную сцену:


Огоньки «До»
Осторожно! Трафик!

Молодой программист, едва закончивший или ещё даже не закончивший ВУЗ, готов свернуть горы, учиться, учиться и ещё раз учиться и ему близлежащее будущее кажется таким:



Но более опытные товарищи знают, что на самом деле на его пути давно уже заботливо разложены грабли и путь от Junior'а к Senior'у выглядит как-то так:



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

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

Главный враг раздолбайства — план.

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

С планом тесно связан прототип. Это может быть что угодно: черновик новой игры на салфетках, накарябанный от руки в блокноте макет указателя в метро, детальная схема процессов или же CAD-файл, например, для выкладки магазина.

Подобный подход рождает несколько довольно странных выводов. Например, если речь идёт о новом сайте – явно, что все тексты должны быть готовы до начала работ по дизайну. При работе с игрой виртуальные прототипы (в симуляциях) работают только на последних этапах балансировки, вначале же куда важнее быстро собрать на бумаге. Если уж говорить шире, то мы знаем, что новый XCOM (и XCOM2) тестировали и тестируются как настолки, а потом уже гонятся на компьютер.

Может показаться, что прототипировать — это вроде как не очень нужно. Херак-херак — и в продакшн. На самом деле, это чертовски важно в любом процессе; например, по заветам юзабелистов — это 70% работы. Вопрос только в том, как это можно делать.

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

Вступление

В чем прелесть XML? Он реализован под все платформы, «человекочитаемый», для него созданы схемы данных (условно человекочитаемые). Открывая 25-мегабайтный файл в браузере сразу замечаешь недостатки этого текстового формата, и начинаешь задумываться. Делаем мы это, конечно, не часто, но все же — чем бы заменить XML?

Добавление самопальных бинарных контейнеров в проект заканчивается провалом, когда к вам приходят партнеры и просят подключить их к этому каналу данных. Google Protobuf поначалу выглядит хорошо, но вскоре понимаешь, что это не замена для XML, не хватает функциональности. BSON в 5 раз медленнее Protobuf, уступает в компактности и для него не реализованы схемы данных.

Разработаем же еще один бинарный формат.

Если коротко, то суть статьи можно можно проиллюстрировать так:



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

В нашем блоге мы много внимания уделяем вопросам алгоритмической и автоматизированной торговли на бирже, рассматривая, как теоретические аспекты, вроде выбора языка программирования, так и практические — например, реализацию системы событийно-ориентированного бэктестинга на Python.

Сегодня мы представляем вашему вниманию подборку сред программирования и инструментов для создания торговых роботов.

Грубо говоря, у ФП и ООП схожие возможности в выражении сложных конструкций и инкапсуляции программ на мелкие куски, которые можно комбинировать между собой.

Самая большая разница между двумя этими «философиями» состоит в том, как данные соотносятся с операциями над данными.

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

При ООП подходе программист составляет новые объекты и расширяет существующие путём добавления к ним методов.

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

При ФП подходе программист пишет новые функции.

1. Введение

В этой статье я попытаюсь исследовать и развенчать пять популярных мифов про C++:

1. Чтобы понять С++, сначала нужно выучить С
2. С++ — это объектно-ориентированный язык программирования
3. В надёжных программах необходима сборка мусора
4. Для достижения эффективности необходимо писать низкоуровневый код
5. С++ подходит только для больших и сложных программ

Если вы или ваши коллеги верите в эти мифы – эта статья для вас. Некоторые мифы правдивы для кого-то, для какой-то задачи в какой-то момент времени. Тем не менее, сегодняшний C++, использующий компиляторы ISO C++ 2011, делает эти утверждения мифами.

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

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

В современной математике комплексное число является одним из фундаментальнейших понятий, находящее применение и в «чистой науке», и в прикладных областях. Понятно, что так было далеко не всегда. В далекие времена, когда даже обычные отрицательные числа казались странным и сомнительным нововведением, необходимость расширения на них операции извлечения квадратного корня была вовсе неочевидной. Тем не менее, в середине XVI века математик Рафаэль Бомбелли вводит комплексные (в данном случае точнее сказать, мнимые) числа в оборот. Собственно, предлагаю посмотреть, в чем была суть затруднений, доведших в итоге солидного итальянца до подобных крайностей.

Введение

Сравнивая две различные технологии параллельного программирования: потоки POSIX и потоки C++11, можно заметить, что в последних отсутствует аналог типа barrier_t из библиотеки pthread.

Довольно странно, что такой важный примитив синхронизации отсутствует в стандартной библиотеке. В этой статье пойдёт речь о том, как сделать барьер с использованием только библиотек, входящих в набор стандарта C++11.

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

Начнём создавать свой барьер, с блэкджеком и ...

Время от времени вдруг начинает хотеться именованных параметров в C++. Не так давно была статья, да и сам какое-то время назад писал на эту тему. И вот что удивительно — со времен той своей статьи я участвую в новом проекте без необходимости тащить за собой старый код, и как-то удивительным образом всего этого описанного собой же не использую. Т.е. в вопросе разобрался, восхитился перспективами… и продолжил работать по-старинке! Как же так? Лень? Инерция? Ответ постараюсь дать под катом.

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

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

В тексте выше ключевое слово «если». Что, если компилятор знает, какую функцию на самом деле надо вызывать?

Автор оригинальной статьи Ali Mese добавил ещё 100 новых бесплатных сервисов. Все 400 потрясающих сервисов доступны здесь. И еще подборку +500 инструментов от 10 марта 2017 г. смотрите здесь.

A. Бесплатные Веб-Сайты + Логотипы + Хостинг + Выставление Счета

• HTML5 UP: Адаптивные шаблоны HTML5 и CSS3.
• Bootswatch: Бесплатные темы для Bootstrap.
• Templated: Коллекция 845 бесплатных шаблонов CSS и HTML5.
• Wordpress.org | Wordpress.com: Бесплатное создание веб-сайта.
• Strikingly.com Domain: Конструктор веб-сайтов.
• Logaster: Онлайн генератор логотипов и элементов фирменного стиля (new).
• Withoomph: Мгновенное создание логотипов (англ.).
• Hipster Logo Generator: Генератор хипстерских логотипов.
• Squarespace Free Logo: Можно скачать бесплатную версию в маленьком разрешении.
• Invoice to me: Бесплатный генератор счета.
• Free Invoice Generator: Альтернативный бесплатный генератор счета.
• Slimvoice: Невероятно простой счет.

Данная статья входит в получившийся цикл статей о системе документирования Doxygen:

1. Документируем код эффективно при помощи Doxygen
2. Оформление документации в Doxygen
3. Построение диаграмм и графов в Doxygen

Это вторая статья из упомянутого цикла, последовавшая за вводной статьёй, посвященной системе документации Doxygen (если вы не знакомы с данной системой, то советую обратить внимание на указанную статью и познакомиться с ней хотя бы в общих чертах). В комментариях к ней был поднят важный вопрос об оформлении документации в Doxygen, и этот вопрос актуален, поскольку зачастую используется стандартное оформление, которое хоть и практичное, но достаточно невзрачное.

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

В прошлом топике (1 ) мы говорили о числах с плавающей точкой/запятой, нормализованных в соответствии со стандартом IEEE754. Там же были рассмотрены денормализованные числа, искусственное введение которых в стандарте привело к чудовищным программно-аппаратным затратам, тормозящим процессы компьютерной обработки чисел в десятки и сотни раз. Но, так уж ли нужна эта самая нормализация и тем более оправдано ли введение экзотического класса денормализованных чисел в компьютерную арифметику? Попробуем разобраться с этим вопросом.

Перевод поста Giorgia Fortuna "2 Pi or Not 2 Pi?".
Выражаю огромную благодарность Кириллу Гузенко за помощь в переводе.

---

Три месяца назад мир (или по крайней мере мир гиков) праздновал день Пи (03.14.15...). Сегодня (6/28 — 28 июня 2015 г.) другой математический день — день 2π, или день Тау (2π = 6.28319...).

Некоторые говорят, что день тау действительно является днём для празднования, и что τ (= 2π), а не π, должен быть самой важной константой. Все началось в 2001 году со вступительного слова знаменитого эссе Боба Пале, математика из университета Юты:

“Я знаю, что некоторые сочтут это богохульством, но я считаю, что π — это ошибка”.

Это вызвало в некоторых кругах празднование дня тау — или, как многие говорят, единственного дня, в который можно съесть два пи(рога) (2pies≈2π — игра слов в англ. языке).

Однако правда ли то, что τ — константа получше? В современном мире это довольно просто проверить, а Wolfram Language делает эту задачу ещё проще (действительно, недавний пост в блоге Майкла Тротта о датах в числе пи, вдохновлённый постом Стивена Вольфрама о праздновании векового дня числа пи, весьма активно задействовал Wolfram Language). Я начала с рассмотрения 320000 препринтов на arXiv.org чтобы посмотреть, сколько в действительности формул содержат 2π по сравнению с теми, что содержат просто π или π с другими сомножителями.

Вот облако из некоторых формул, построенное с помощью функции WordCloud, содержащих 2π:

0х01. Работа не мечта

// Code is Poetry

Джон Касти как-то сказал: «Физика — это частный случай биологии», я считаю — программирование частным случаем поэзии. Здесь так же важно соблюдать структуру, как соблюдается рифма, знать своего пользователя как знать своего читателя, быть одновременно переводчиком и историком, чтобы кто-то, придя из другой сферы смог прочесть написанное тобой. Но сам программист — сочетание характеров писателя, изобретателя и испытателя. Код соединяет несоединяемое: творчество тысяч людей сливаются в один проект, словно десятки художников, со свойственными только им стилями, красками и предпочтениями, берутся за рисование одного полотна. Одно ясно: унификация не удел программиста.