C++ *

Здравствуйте!

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

И вот на тебе! Пробка… А ехать еще и ехать. Путь не близкий, с учетом пробки — это не менее 3 часов до дома.
Ну, соответственно: подбадриваю себя, что, мол, дома ужин, чай, снег за окном. И вроде настроение возвращаться начинает, как внезапно с правой полосы Toyota Prius (ну, знаете такой — на батарейках весь), включает левый поворот и лезет прямо перед моей машиной… «Хорошо, дружище! Езжай, все равно вместе стоять 3 часа.» Встроился, проехал два метра и встал. Как положено на дороге в пробке, зафиксировался тормозом.

Это третья статья в цикле «Теория категорий для программистов».

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

Кому нужны типы?

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

Привет всем!

Несколько лет назад меня начал беспокоить вопрос создания статических (создаваемых и изменяемых до процесса компиляции) перечислений. Перечислений я хотел не простых, которые реализованы в С/С++, а с набором дополнительных возможностей, в том числе и ассоциированными столбцами данных произвольного типа, своего рода статическая база данных с доступом по уникальному идентификатору.

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

Часть 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(); 
} 

Недавний релиз Qt 5.4, помимо прочего, предоставил в распоряжение разработчиков один, на мой взгляд, очень любопытный инструмент. А именно, разработчики Qt сделали QQuickRenderControl частью публичного API. Занятность данного класса заключается в том, что теперь появилась возможность использовать Qml в связке с любым другим фреймворком, если он предоставляет возможность получить (или задать) указатель на используемый OpenGL контекст.
С другой стороны, в процессе работы над одним из своих проектов, я столкнулся с необходимостью отрисовывать QML сцену на CALayer (Mac OS X), без малейшей возможности получить доступ к родительскому окну. Недельный поиск возможных вариантов решения проблемы показал, что самым адекватным решением будет как раз использование QQuickRenderControl из Qt 5.4, благодаря удачному совпадению, получившего статус релиза одновременно с возникновением вышеупомянутой задачи.
Изначально я предположил что задача плевая, и будет решена в течении пары вечеров, но как же я сильно заблуждался — задача заняла порядка полумесяца на исследования, и еще пол месяца на реализацию (которая все еще далека от идеала).

1. Введение

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

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

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

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

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

Хочу рассказать как мы использовали списки базовых типов для обработки сообщений. Сообщения представляют собой структуры, унаследованные от небольших базовых структур. Вся полезная информация хранится в базовых структурах. Для обработки нужно знать от каких базовых структур было унаследовано обрабатываемое сообщение. Все что нужно для работы со списками типов мы нашли в Boost.MPL. В качестве списка типов выбрали boost::mpl::vector. Для прохода по списку типов boost::mpl::for_each.

В этой статье я хотел бы рассказать о некоторых неудобствах, с которыми столкнулся при работе с системой переводов в Qt, а также поделиться способами борьбы с этими неудобствами.

Для начала кратко напомню о том, как работает система переводов в Qt.

Намедни решил написать свою библиотеку для работы с FITS-файлами. Да, я знаю, что есть CCFITS, но хотелось изобрести свой велосипед с… сами знаете.

Одна из возможностей формата — данные можно записывать разных типов в массивы разных размерностей.
Очевидный способ это реализовать это определить что-то типа того:

void setBytePix(int value);
void setAxisSize(const std::vector<int> &axis );

Однако данная конструкция не слишком удобна. Простой тестовый пример:

std::vector srcVector;
srcVector.push_back(1024);
srcVector.push_back(1024);
setAxisSize(srcVector);

Если бы вместо std::vector был бы QVector из Qt, все выглядело бы гораздо симпатичнее.

Предновогодний привет всем читающим нас хабражителям!

2014 год был для нас насыщенным и во многом сложным, но при этом — еще и самым инновационным и поучительным.

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



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

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

Естественно, вышесказанное касается как проработки профессиональных навыков, так и так называемых soft skills: например, все те, кому было важно научиться доходчиво доносить свою мысль до коллег и подчиненных, прошли курс ораторского мастерства.

На какой-либо индивидуальный внешний курс или тренинг от Зептолаб можно попасть двумя путями:

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

В этой статье я расскажу о небольшом how to о разработке для Arduino в CLion www.jetbrains.com/clion.
CLion — новая IDE для C/C++ от JetBrains. По стилю и поведению очень похожа на IDEA (IDE для Java). А так как я пишу на Java под IDEA с использованием «фишек» это IDE, то хотелось бы все эти «фишки» и use case разработки перенести на разработку для Arduino.

В этой статье я хочу сделать две вещи: рассказать, почему макросы — зло и как с этим бороться, а так же продемонстрировать пару используемых мной макросов C++, которые упрощают работу с кодом и улучшают его читаемость. Трюки, на самом деле, не такие уж и грязные:

• Безопасный вызов метода
• Неиспользуемые переменные
• Превращение в строку
• Запятая в аргументе макроса
• Бесконечный цикл

Заранее предупреждаю: если Вы думаете увидеть под катом что-то крутое, головоломное и сногсшибательное, то ничего такого в статье нет. Статья про светлую сторону макросов.

Введение

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

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

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

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

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

Давайте посмотрим на пример:

createArray(10, 20); // Что это значит? Что за "10" ? Что за "20" ?
createArray(length=10, capacity=20); // О, вот теперь понятнее!
createArray(capacity=20, length=10); // И наоборот тоже работает.

И еще один пример на выдуманном псевдо-языке:

window = new Window {
   xPosition = 10,
   yPosition = 20,
   width = 100,
   height = 50
};

Этот подход особенно полезен для функций с большим количеством опциональных параметров, при вызове которых нужно изменить лишь некоторую часть дефолтных значений. Некоторые языки программирования поддерживают именованные параметры (C#, Objective-C, ...), но не С++. В этом посте мы рассмотрим пару классических способов эмуляции именованных параметров в С++, ну и попробуем придумать что-то новое.

The Powder Toy является песочницей со свободной физикой, которая имитирует давление и скорость воздуха, тепла, тяжести и бесчисленное количество взаимодействий между различными веществами. Игра предоставляет различные строительные материалы, жидкости, газы и электронные компоненты, которые могут быть использованы для построения сложных машин, оружия, бомб, реалистичной местности и почти всего, что угодно. Вы можете просматривать и воспроизводить тысячи различных сделанных построек. Вот только в игре оказалось не всё так замечательно: для небольшого проекта размером в ~350 файлов было получено довольно много предупреждений статического анализатора. В этой статье будут описаны наиболее интересные места.

Всем добрый день!

Недавно передо мной встала довольно интересная задача, сделать интерфейс пользователя для общения с одной железкой. Связь с ней осуществлялась посредством COM-порта. Так как работа предполагалась с системой реального времени (эта самая железка) в операционной системе Windows, для того, чтобы GUI не тормозил, было решено работу с COM-портом вынести в отдельный поток. Так как требования к самой системе постоянно менялись, для минимизации и ускорения исправлений также было решено писать используя паттерн проектирования MVP. В качестве среды разработки был выбран Qt. Просто потому, что мне нравится данная среда и ее возможности. Так и получилась связка Qt+MVP+Qthread. Кому интересно, что из этого всего вышло и по каким граблям я ходил, прошу под кат.

Потоки ввода-вывода в стандартной библиотеке C++ просты в использовании, типобезопасны, устойчивы к утечке ресурсов, и позволяют простую обработку ошибок. Однако, за ними закрепилась репутация «медленных». Этому есть несколько причин, таких как широкое использование динамической аллокации и виртуальных функций. Вообще, потоки — одна из самых древних частей стандартной библиотеки (они начали использоваться примерно в 1988 году), и многие решения в них сейчас воспринимаются как «спорные». Тем не менее, они широко используются, особенно когда надо написать какую-то простую программу, работающую с текстовыми данными.

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

Сегодня в комментариях у посту возникло обсуждение о медленности iostreams. В частности, freopen пишет

Забавно смотреть на ваши оптимизации, расположенные по соседству со считыванием через cin :)

а aesamson даёт такую рекомендацию

Можно заменить на getchar_unlocked() для *nix или getchar() для всех остальных.
getchar_unlocked > getchar > scanf > cin, где ">" означает быстрее.

В этом посте я развею и подтвержу некоторые мифы и дам пару рекомендаций.

Примерно год назад было принято решение о запуске нового телеканала высокой чёткости. Встал вопрос о техническом оснащении имеющейся аппаратной по выпуске SD каналов новым оборудованием. И первое что приходило в голову — расширить имеющийся комплекс Skylark, «докупив» оборудование. Посчитав примерные затраты, руководство пришло в лёгкий шок — цены кусались. И вот тут-то у меня родилась идея, построить эфирный комплекс на Linux.

Я думаю, большинство людей, кто застал времена DOS и ранних Windows 9x, играли или хотя-бы слышали о такой замечательной игре, как Supaplex. Лично для меня — это игра-легенда. Я до сих пор с трепетом вспоминаю долгие зимние вечера, проведённые в попытке пройти какой-нибудь сложный уровень на стареньком 286-м.

Так сложилось, что я программист. И не просто программист, а программист компьютерных игр. Так что, где-то в 2008 году я занялся написанием движка-«убийцы крузиса» (или что там было круто на тот момент, я уже не помню). Примерно через год меня настигло прозрение, что моих человеко-часов на проект уровня Unreal Engine не хватит. И я решил сделать легкую, «казуальную», версию движка и написать на ней пару простеньких игрушек.

Мой выбор пал на клон Supaplex. Правда, на тот момент уже существовало несколько клонов под Windows и другие платформы, поэтому просто писать все с нуля было неинтересно. Зато в мою голову заползла крамольная мысль: а что, если дизассемблировать оригинальный Supaplex и сделать игру с логикой, «идентичной натуральной». Такая задача казалась крайне заманчивой, и я взялся за её осуществление. Я заказал 3D-модельки у одного хорошего знакомого фрилансера и, пока он был занят моделлингом, я приступил к изучению пациента. Сразу предупреждаю, что я уже не помню многих деталей и могу что-то забыть или приврать, всё-таки это было довольно давно.