Часть 1

4.2 Разделённое владение shared_ptr

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

void startup() 
{ 
  sync_queue* p = new sync_queue{200}; // опасность! 
  thread t1 {task1,iqueue,p}; // task1 читает из *iqueue и пишет в *p 
  thread t2 {task2,p,oqueue}; // task2 читает из *p и пишет в *oqueue 
  t1.detach(); 
  t2.detach(); 
} 

О конструкторе Makeblock я узнал уже после того, как завершилась его кампания на кикстартере. А жаль, поскольку был шанс приобрести наборы конструктора по достаточно низкой цене. После удачной кампании авторы продолжили развивать свои идеи и создали набор для плоттера — XY-Plotter Robot Kit v2.0. Мне он обошелся в $300 с бесплатной доставкой через EMS в рамках акции «накупи на $500».

Плоттер заинтересовал меня по двум причинам: возможность рисовать ручкой Circuit Scribe с токопроводящими чернилами и возможность проапгрейдить плоттер лазерным резаком. В этой статье я расскажу о своих впечатлениях от плоттера в его оригинальной конфигурации.

последняя редакция статьи доступна на сайте makeloft.xyz

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

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

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

Введение

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

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

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

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

Перевод статьи Джефа Прешинга Atomic vs. Non-Atomic Operations. Оригинальная статья: http://preshing.com/20130618/atomic-vs-non-atomic-operations/

В Сети уже очень много написано об атомарных операциях, но в основном авторы рассматривают операции чтения-модификации-записи. Однако, существуют и другие атомарные операции, например, атомарные операции загрузки (load) и сохранения (store), которые не менее важны. В этой статье я сравню атомарные загрузки и сохранения с их неатомарными аналогами на уровне процессора и компилятора C/C++. По ходу статьи мы также разберемся с концепцией «состояния гонок» с точки зрения стандарта C++11.

*Эта статья впервые была опубликована в журнале Forbes от 27 Июня 2014 года. На Хабре публикуется её полная версия.

Вот уже 9 лет я занимаюсь интернет-бизнесом и за это время успел создать и вывести на прибыльность 5 собственных стартапов. Кроме того, один из основных моих бизнесов – это заказная веб-разработка, куда часто приходят клиенты, которые хотят разработать свой интернет-стартап и поэтому я все 9 лет каждый день сталкиваюсь с разными проектами, многие из которых являются стартапами в полном смысле этого слова.

На протяжении довольно долгого времени я и мои коллеги, участники Русскоязычной поддержки Wolfram Mathematica, занимались разработкой и коллекционированием полностью бесплатных и качественных ресурсов на русском языке, которые позволили бы любому желающему научиться программировать на языке Wolfram Language (Mathematica) самостоятельно.

Думаю, что пришла пора рассказать об этом на Хабрахабре, создав статью о разрабатываемой коллекции ресурсов, которая будет постоянно расширяться и пополняться, и будет служить, по сути, русскоязычным аналогом страницы "Where can I find examples of good Mathematica programming practice?" на сайте Mathematica at StackExchange.com.

Исключения и связанная с ними раскрутка стека – одна из самых приятных методик в C++. Обработка исключений интуитивно понятно согласуется с блочной структурой программы. Внешне, обработка исключений представляется очень логичной и естественной.

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

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

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

При реализации логгирования, задачи для себя были поставлены следующие:

• Решить задачу на «мета-уровне», чтобы быть отвязанным от конечной реализации
• Фронтенд апи для логгирования должен быть простым и прозрачным
• Иметь возможность выключать ненужные уровни логгирования на этапе компиляции одной константой; например: все что выше LOG_NOTICE не должно попасть в результирующий бинари

Фронтенд выглядит так:

1. В конструкторе CConnection мы логгируем:

TestLog::Log<LOG_NOTICE>() << *this << "connection created";

2. Где CConnection унаследован от

public TLogHeader<'c', CConnection>

3.Который, используя CRTP, знает, что в CConnection есть такое:

	using this_t = CConnection;
	int m_id;           using m_id_t = TParamAccessor<this_t, decltype(this_t::m_id), &this_t::m_id>;
	std::string m_name; using m_name_t = TParamAccessor<this_t, decltype(this_t::m_name), &this_t::m_name>;
    char m_state;       using m_state_t = TParamAccessor<this_t, decltype(this_t::m_state), &this_t::m_state>;
	using log_header_param_list_t = std::tuple<m_id_t, m_name_t, m_state_t>;

4. И превращает эти данные в строчку лога:

c:23:test_conn 1:a:connection created

Где через двоеточие перечислены: с — первый параметр шаблона TLogHeader, и далее значения m_id, m_name, m_state

В моем случае все это дальше пишется в rsyslog и там разбирается в соответствующие поля для MongoDB (в зависимости от типа заголовка, т.е. первый параметр до двоеточия).

Сейчас этот подход у меня в продакшене на высоконагруженной системе, так что любые конструктивные камни будут в пику, или лучше под кат. А если лень, то вот работающий пример на http://coliru.stacked-crooked.com/ т.к. под катом кода на 250 строк, но очень много букв в описании.

Стандарт C++11 привнес в язык такую вещь, как пользовательские литералы^[1]. Конкретно — дюжину вариантов для определения оператора "", добавляющих небольшой синтаксический сахар, всех, за исключением одного — шаблонного варианта:

template <char...> type operator "" _op();

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

Например:

auto x = 10001000100011001001001010001000_b;

Однако при разработке стандарта было допущено небольшое упущение — шаблонный вариант пользовательского литерала позволяет работать только с числовыми аргументами, несмотря на то, что парсинг их осуществляется посимвольно.
Такое упущение, конечно же, не могло остаться не замеченным, и на этапе согласования стандарта C++14 было предложено решение для строковых аргументов^[2]

template <typename CharT, CharT ...String> type operator "" _op();

В скором времени было реализовано в компиляторах GCC^[3] и clang (GNU extension). Однако в финальную редакцию стандарта C++14 так и не попало. Впрочем, не будем отчаиваться, есть надежда, что нас обрадует C++17. А пока посмотрим, как можно будет применять новый тип пользовательских литералов.

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

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

Я отклонил это заманчивое предложение и благополучно забыл о нем. Но на следующей неделе я снова встретился с этим психологом. Сначала она сидела на диване и разглядывала каталоги. А потом села неподалеку с видом «я здесь если тебе понадобится помощь». Через какое-то время, мне это надоело и я сказал, что я об этом думаю.

Ниже — вольный пересказ книги Running Lean, автор — Ash Maurya. Рейтинг Амазона — 4.8 из 5. Книга, насколько я знаю, на русский язык еще не переведена.

Здесь изложена суть книги в объеме меньшем 1% объема книги, по моей оценке. Все вопросы освещены так, как я их понял, что необязательно совпадает с тем, как их хотел донести автор.

Допускаю, что нарушаю чьи-то права: пересказ лицензии не требует, но иллюстрации взяты из книги. Автору я писал в попытке прояснить этот вопрос, но ответа не получил.

Блог автора кгиги: practicetrumpstheory.com.

Структура пересказа

• Введение в процесс Running Lean
  • Три важнейших методологии
  • Roadmap
• Описание процесса Running Lean
  
  • Составьте «План А»
    
    • Определите кто клиенты
    • Создайте бизнес-модели
    • Ранжируйте бизнес-модели
  • Протестируйте и измените план
    
    • Подготовьтесь к проведению экспериментов
    • Категории рисков и четыре фазы тестирования плана
      
      • Фаза 1. Поймите проблему
      • Фаза 2. Найдите решение
      • Фаза 3. Валидируйте качественно
      • Фаза 4. Верифицируйте количественно
• Три стадии стартапа
  
  • Соотношение трех стадий стартапа и четырех фаз тестирования плана
  • Держите правильный фокус
  • Привлекайте финансирование вовремя
  • Масштабируйте правильно

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

Собственно через регулярные выражения я к ним и пришёл.

Целью данной работы является получение кода, сгенерированного бэк-эндом компилятора LLVM MSP430

Введение

CLANG — это просто фронт-энд компилятора С для LLVM. LLVM — это фреймворк для разработки фронт-эндов, бэк-эндов компиляторов для разных целевых платформ. Этот фреймворк облегчает анализ путем приведения всех фронт-эндов к промежуточному представлению (IR). Все бэк-энды оперируют с этим общим представлением.

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

Текущая поддержка MSP430 весьма ограничена. Я надеюсь, что смогу помочь кому-нибудь, кто слишком фейс-палмит, сохранить лицо. ¹

Поехали

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

Несколько дней назад Бьёрн Страуструп опубликовал предложение N4174 комитету по стандартизации С++ названное "Call syntax: x.f(y) vs. f(x,y)". Вот вкратце его суть: объявить выражение x.f(y) (вызов для объекта х метода f с аргументом y) эквивалентным выражению f(x,y) (вызов функции f с аргументами x и y). Т.е.

x.f(y) означает:

1. Попробовать вызвать x.f(y): если класс объекта х содержит метод f, который может принять аргумент y — используем этот метод.
2. Если пункт №1 не удался — проверяем, существует ли функция f, которая может принять аргументы x и y. Если это так — используем её.
3. Если не найдено ни того, ни другого — генерируем ошибку.

f(x,y) означает ровно то же самое:

1. Попробовать вызвать x.f(y): если класс объекта х содержит метод f, который может принять аргумент y — используем этот метод.
2. Если пункт №1 не удался — проверяем, существует ли функция f, которая может принять аргументы x и y. Если это так — используем её.
3. Если не найдено ни того, ни другого — генерируем ошибку.

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

Полное оригинальное название статьи: «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) позволяют привнести в язык сильные статические гарантии и сделать программы на нём эффективными и безопасными, как по памяти, так и по времени.

Лицензия: CC-BY, автор Chris Morgan.

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

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

Rust это «подвижная мишень», тем не менее, язык становится стабильней. Код из статьи работает с версией 0.12. Если что-то сломается, пожалуйста, свяжитесь со мной. Касательно кода на Python, он будет работать как в двойке, так и в тройке.

Пенсия для ITшника.
Тут нужно было бы писать «а что делать в старости?», «на государство недёжи никакой», «в наше время каждый должен...» и прочее бла-бла-бла и би-би-би. Но мне лень, потому — сразу к делу.

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

А еще?
А еще золото двигается в противофазе с рынком акций. То есть, когда в экономике тайфун — все инвесторы бегут в золото, как самый надежный актив. Ну и наоборот, естественно… Это делает золото идеальным инструментом для построения «портфеля простака».

Мы все привыкли к словосочетанию «технический прогресс». Уже довольно много лет назад смена поколений всевозможных устройств и гаджетов стала таким же привычным явлением, как смена времён года. И никого не удивляет, по большей части. Мы привыкли, к метаморфозам мобильных телефонов, домашних телевизоров, компьютерных мониторов, теперь вот подтянулись часы и даже очки. Однако есть некий немногочисленный класс устройств, о которых многие слышали, их опасаются, но в живую видели единицы. Речь идёт о скиммерах.

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

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

Минимальная цена на младшую модель, с Intel® Celeron, составляла 250 долларов США. Но теперь есть возможность купить систему за 130 долларов США.