Как только я заинтересовался lock-free алгоритмами, меня стал мучить вопрос – а откуда взялась необходимость в барьерах памяти, в «наведении порядка» в коде?
Конечно, прочитав несколько тысяч страниц руководств по конкретной архитектуре, мы найдем ответ. Но этот ответ будет годен для этой конкретной архитектуры. Есть ли общий? В конце концов, мы же хотим, чтобы наш код был портабелен. Да и модель памяти C++11 не заточена под конкретный процессор.
Наиболее приемлемый общий ответ дал мне мистер Paul McKenney в своей статье 2010 года Memory Barriers: a Hardware View of Software Hackers. Ценность его статьи – в общности: он построил некоторую упрощенную абстрактную архитектуру, на примере которой и разбирает, что такое барьер памяти и зачем он был введен.
Вообще, Paul McKenney – известная личность. Он является разработчиком и активным пропагандистом технологии RCU, которая активно используется в ядре Linux, а также реализована в последней версии libcds в качестве ещё одного подхода к безопасному освобождению памяти (вообще, о RCU я хотел бы рассказать отдельно). Также принимал участие в работе над моделью памяти C++11.
Статья большая, я даю перевод только первой половины. Я позволил себе добавить некоторые комментарии, [которые выделены в тексте так].

Добрый день, Хабрахабр!
Решил написать этот топик на тему скриптов

Что нужно знать?

• С++ на приличном уровне (в уроке будут шаблоны — template)
• Lua, очень легкий скриптовый язык. Советую этот урок.

Почему писать диалоги игры в .cpp файле было большой ошибкой

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

Но есть способ, на голову выше — использование скриптов.

Построение lock-free структур данных зиждется на двух китах – атомарных операциях и способах упорядочения доступа к памяти. В этой статье речь пойдет об атомарности и атомарных примитивах.

Анонс. Спасибо за теплый прием Начал! Вижу, что тема lock-free интересна хабрасообществу, это меня радует. Я планировал построить цикл по академическому принципу, плавно переходя от основ к алгоритмам, попутно иллюстрируя текст кодом из libcds. Но часть читателей требует зрелищ не мешкая показать, как пользоваться библиотекой, особо не рассусоливая. Я согласен, в этом есть свой резон. В конечном счете, и мне не так интересно, что там внутри boost, — опишите, как его применять! Поэтому свой эпический цикл я разделю на три части: Основы, Внутри и Извне. Каждая статья эпопеи будет относится к одной из частей. В Основах будет рассказываться о низкоуровневых вещах, вплоть до строения современных процессоров; это часть для почемучек вроде меня. Внутри будет освещать интересные алгоритмы и подходы в мире lock-free, — это скорее теория о том, как реализовать lock-free структуру данных, libcds будет неисчерпаемым источником C++ кода. В Извне будут статьи о практике применения libcds, — программные решения, советы и FAQ. Извне будет питаться вашими вопросами/замечаниями/предложениями, дорогие хабражители.

А пока я судорожно готовлю начало Извне, — первая часть Основ. Статья во многом не о C++ (хотя и о нем тоже) и даже не о lock-free (хотя без atomic lock-free алгоритмы неработоспособны), а о реализации атомарных примитивов в современных процессорах и о базовых проблемах, возникающих при использовании таких примитивов.
Атомарность — это первый круг ада низкий уровень из двух.

Я надеюсь, что эта статья станет началом цикла заметок о lock-free структурах данных. Я хочу поделиться с хабрасообществом своим опытом, наблюдениям и размышлениями о том, что такое lock-free структуры данных, как их реализовывать, подходят ли концепции контейнеров стандартной библиотеки STL к lock-free контейнерам, и когда стоит (и стоит ли вообще) применять lock-free структуры данных.

На хабре много статей посвященных редактору Sublime Text 2. Обычно они рождают за собой множество комментариев, где сторонники ST2 и всевозможных других редакторов (а также полноценных IDE) предаются веселому процессу «достоинствометрии».
Однако, среди комментариев мне лично ни разу не встречалось упоминаний о плагине SublimeClang, который кардинально меняет работу C++ программиста в этом редакторе. Поиск по хабру выдал всего 4 упоминания плагина в комментариях.
Не знаю, чем вызвано такое игнорирование. Хорошие вещи не обсуждаются? ST2 не используют C и С++ разработчики? Своей статьей я хочу исправить ситуацию. Я расскажу о некоторых, возможно не очевидных, особенностях установки и настройки, а также поделюсь парой собственных приемов и скриптов.

О плагине

Итак, плагин обеспечивает автодополнение кода и проверку ошибок прямо по ходу написания программы. Для файлов C/C++/ObjC/ObjC++ плагин заменяет стандартное автодополнение редактора на свое собственное. Для этого, плагин в фоне прогоняет исходник через компилятор clang, который формирует AST. Полученную информацию плагин использует для интеллектуальных подсказок автодополнения.
Ближайший аналог, который я могу подобрать — это функция IntelliSense в MS Visual Studio.
Использование информации из первых рук — от компилятора — позволяет плагину правильно узнавать, какие переменные, функции, типы и т.п. доступны в данной конкретной точки программы. Так же, в какой-то мере работают Go to definition (alt + d, alt + d) и Go to implementation (alt + d, alt + i). Список остальных горячих клавиш доступен на странице проекта.

Рич Хикки произноситит классные, дающие пищу для размышления выступления. Считается, почти всем, если не поголовно, программистам надо их услышать и увидеть. Если вы не интересуетесь Clojure, лучше смотреть с конца.

• Are We There Yet? – 2009 -размышления о том, правилен ли текущий подход к реализации ООП. Обсуждается много вопросов о проектировании Clojure.

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

# Весь код в статье написан на языке Python

Основы

Пожалуй, лучшее описание динамики в одно предложение, которое я когда либо слышал:

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

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

«То, что мы называем хаосом — это всего лишь закономерности, которые мы не сумели распознать. То, что мы называем случайностями — это всего лишь закономерности, которые мы не в состоянии расшифровать.»
— Чак Паланик

Как насчет абстрактного подхода к разработке адвенчу? Или, хотя бы, для загадок в адвенчурах — это может оказаться полезным!

Списки книг

• 25 бесплатных книг по информатике
• Шпаргалки
• CodePlex: Список бесплатных книг
• Бесплатные технические книги
• Galileo Computing (Немецкий)
• How to Design Programs: An Introduction to Computing and Programming
• Microsoft Press: Бесплатные книги
• MindView Inc
• Проект O'Reilly's Open Books
• TechBooksForFree.com
• Theassayer.org
• Wikibooks: Программирование
• Неплохая подборка, редактируемая сообществом (JIghtuse)
• Книги на Русском (telteron)

Программирование графики

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

Я расскажу о следующем:

• что такое перекрестные ссылки;
• чем опасны безымянные shared_ptr;
• какие опасности подстерегают при использовании shared_ptr в многопоточной среде;
• о чем важно помнить, создавая свою собственную освобождающую функцию для shared_ptr;
• какие существуют особенности использования шаблона enable_shared_from_this.

Давно была идея собрать воедино интересные вопросы, касающиеся сетей.

Объединяет их то, что все они довольно простые, но мы подчас о них не задумываемся (я во всяком случае о них не задумывался).
В общем я их собрал, подбил, нашёл ответы.
Итак, блиц опрос:

Начнём с самых низких уровней и с самых простых вопросов

В1. Почему для витой пары выбран такой странный порядок: синяя пара на 4-5, разрывая зелёную, которая на 3, 6?

В2. В стандарте Ethernet между кадрами всегда имеется промежуток, называемый IFG (Inter Frame Gap) длиною 12 байтов. Для чего он нужен, и почему он присутствует в современных стандартах?

Введение

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

Матчасть

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

A( x1;y1 )
B( x2;y2 )
C( x3;y3 )

расстояния между точками находятся по теореме Пифагора

a^2 = b^2 + c^2 — 2*b*c*cos(ALPHA)
cos(ALPHA) = (b^+c^-a^) / 2*b*c

Зная косинус, величину угла легко можно вычислить.

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

1. Мы берем первую и последнюю точки каркасов фигур. Уже две есть, осталось отыскать третью ( для нахождения величины угла ).
2. Поиск третьей осуществляется перебором все последующих точек после первой. Решение включать точку в предполагаемый каркас фигуры принимается на основе двух анализов:
   
   • Попытка подставить точку в угол( в качестве третьей, заключительной ) и проверить его на соответствие величине того же угла в каркасе реальной фигуры.
   • Проверить отношение сторон получившегося угла с тем же отношением сторон угла в каркасе реальной фигуры.
   
   

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

Если, допустим, у нас есть несколько анализируемых каркасов, например, «8» и «6». И результат алгоритма распознавания: «8»-80%, «6» — 90%, то решение принимается в пользу той фигуры, в каркасе которой присутствует больше контрольных точек, т.е в пользу восьмерки.

Процент сходства набора точек с точками в каркасе высчитывается просто: суммируются все точки, которые сошлись с теми же точками в каркасе и находится отношение. Допустим, если в каркасе N контрольных точек, а у нас сошлось M, то процент сходства — M / N * 100

Проблемы git-flow

Повсюду путешествую, преподавая Git людям — и почти на каждом уроке и семинаре, недавно мною проведённом, меня спрашивали, что я думаю о git-flow. Я всегда отвечал, что думаю, что этот подход великолепен — он взял систему (Git), для которой могут существовать мириады возможных рабочих процессов, и задокументировал один проверенный и гибкий процесс, который для многих разработчиков годится при довольно простом употреблении. Подход этот также становится чем-то вроде стандарта, так что разработчики могут переходить от проекта к проекту и из компании в компанию, оставаясь знакомыми с этим стандартизированным рабочим процессом.

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба

Пару дней назад Mika Tuomi, известный как Trug, передал исходный код Second Reality в общественное достояние.



Second Reality — это демо, занявшее первое место на демопати Assembly '93. Оно было создано командой Future Crew, которая на тот момент состояла из 12-ти человек. Впоследствии ее члены основали такие компании как Futuremark и Remedy Entertainment. Считается, что это демо оказало огромное влияние на развитие демосцены.

Статья о Future Crew в Википедии (англ.)
Статья о Second Reality в Википедии
Бинарники
Исходный код на Гитхабе

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

Новая версия Java пытается “совершенствоваться” так, как понимает это слово Microsoft. Это означает кражу большой части вещей, о которых заботились другие фреймворки и языки, затем включение их в язык или runtime. В преддверии нового релиза, сообщество Java обсуждает Project Lambda, stream, functional interfaces и другие плюшки. Так давайте рассмотрим что хорошо, а что мы можем возненавидеть.

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

В то время пока выходят статьи о сущности и подводных камнях r-value ссылок (пример со ссылками на полезные источники habrahabr.ru/post/157961) подозреваю, что довольно многие не знают особенности обычных l-value ссылок. Суть этой статьи показать пример, когда время жизни объекта определяется временем жизни l-value ссылки на него, и как это можно использовать. Если заинтересовало, то добро пожаловать. Кстати, зная как можно больше особенностей про l-value ссылки, будет проще понять r-value.

Не так давно Скотт Майерс (англ. Scott Meyers) — эксперт по языку программирования C++, автор многих известных книг — опубликовал статью, описывающую подробности использования rvalue ссылок в C++11.
На Хабре эта тема еще не поднималась, и как мне кажется, статья будет интересна сообществу.
Оригинал статьи: «Universal References in C++11—Scott Meyers»

«Универсальные» ссылки в C++11

T&& не всегда означает “Rvalue Reference”

Автор: Scott Meyers

Возможно, наиболее важным нововведением в C++11 являются rvalue ссылки. Они служат тем фундаментом, на котором строятся «семантика переноса (англ. move semantics)» и «perfect forwarding». (Вы можете ознакомится с основами данных механизмов в обзоре Thomas’а Becker’а).

Синтаксически rvalue ссылки объявляются также, как и «нормальные» ссылки (теперь называемые lvalue ссылками), за исключением того, что вы используете два амперсанда вместо одного. Таким образом, эта функция принимает параметр типа rvalue-reference-to-Widget:

void f(Widget&& param);

Учитывая, что rvalue ссылки объявляются с помощью “&&”, было бы разумно предположить, что присутствие “&&” в объявлении типа указывает на rvalue ссылку. Но это не так:

Widget&& var1 = someWidget;         // здесь “&&” означает rvalue ссылку

auto&& var2 = var1;                 // здесь “&&” НЕ означает rvalue ссылку

template<typename T>
void f(std::vector<T>&& param);     // здесь “&&” означает rvalue ссылку

template<typename T>
void f(T&& param);                  // здесь “&&” НЕ означает rvalue ссылку

Думаю, практически все представители хабрасообщества понимают, как работает транзистор (да и не только он). Тем не менее, я предлагаю оценить объяснение работы транзистора (а также полупроводников и прочего), представленное пользователем YouTube 1vertiasium. Видео — англоязычное, но объяснение настолько красочное, что и так все понятно.

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

Как получить работу инженера?

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

# x = количество компаний, в которых ты проходил собеседования

# y = количество предложений о работе, которые ты получил

рейтинг = 100 * log(x) * y / x


Если твой рейтинг < 90, обязательно прочти это. Если > 120, возможно, тебе это не нужно, но, все равно прочти.