Рубрика «Блог компании Инфопульс Украина»

Один из пользователей компилятора Visual C++ привёл следующий пример кода и спросил, почему его цикл с условием выполняется бесконечно, хотя в какой-то момент условие должно перестать выполняться и цикл должен закончиться:

#include <windows.h>

int x = 0, y = 1;
int* ptr;

DWORD CALLBACK ThreadProc(void*)
{
  Sleep(1000);
  ptr = &y;
  return 0;
}

int main(int, char**)
{
 ptr = &x; // starts out pointing to x

 DWORD id;
 HANDLE hThread = CreateThread(nullptr, 0, ThreadProc, 0, &id);

 // Ждём, пока другой поток изменит значение по указателю ptr
 // на некоторое ненулевое число
 while (*ptr == 0) { }

 return 0;
}

Читать полностью »

Мой любимый файл в кодовой базе Chromium - 1Код Хромиума весьма обширен, там каждому найдётся что-то по вкусу. А я вот решил рассказать о своём любимом файле в нём (а у вас есть такой?). Этот файл отражает всё: боль, разочарование, надежду, упорство, силу воли, ответственность за чужие провалы и самопожертвование. Я иногда читаю его и плачу и проникаюсь пониманием, какая же огромная часть айсберга скрыта под водой. Это, в общем, даже не файл с кодом. Это файл с конфигом, описывающим баги видеокарт, которые Хромиуму приходится обходить для нормального отображения своих страниц на разных платформах. Вот он: https://cs.chromium.org/chromium/src/gpu/config/gpu_driver_bug_list.json

О чём вообще идёт речь? Давайте вспомним, как работает браузер: вы набираете какой-то адрес в адресной строке, браузер загружает контент и отображает его. Чуть детальнее об этом рассказывает хорошая статья «What happens when you type google.com into your browser and press enter?» (и сразу несколько её переводов на Хабре). В ней одним из последних пунктов упоминается, мол, «а теперь, когда всё готово, отрисовываем картинку на экране». Ага, вот так берём и отрисовываем, конечно.
Читать полностью »

Ну или начните делать это правильно.

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

«Нам нужно реализовать решение {Х}, несмотря даже на то, что есть значительно более простое и подходящее нам сейчас решение {Y}, ведь когда в будущем произойдёт {Z}, то {X} сработает гораздо лучше, чем {Y}».

При этом точной информации о вероятности наступления события {Z} нет и быть не может.

Вот пара примеров:

  • Нам нужно использовать kubernetes и docker! Да, с текущей нагрузкой отлично справляется один сервер и его легко настроить и поддерживать, но ведь когда нам нужно будет дюжина серверов — будет легче их разворачивать с kubernetes и docker.
  • Нам нужна архитектура распределенной обработки данных! Да, пока со всем справляется один средненький ПК, но когда у нас будет решение промышленного уровня и заказчики потребуют аптайм в пять девяток после запятой в SLA — мы будем к этому готовы.
  • Нам нужно нанять команду разработчиков и создать сайт с нуля, не смотря на то, что значительно быстрее было бы развернуть что-то на базе wordpress, ведь когда у нас будет в 100 раз больше клиентов, чем сейчас, то wordpress станет не так удобен.
  • Нам нужно использовать наследование вместо композиции, ведь через 5 лет кодовая база разрастётся так, что без этого будет никак.
  • Нам нужно написать вот этот код на С++, не смотря на то, что на Python это будет в разы быстрее, ведь спустя годы он будет обрабатывать терабайты данных и Python может здесь не справится.

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

Я боролся с соблазном назвать статью как-то типа «Ужасающая неэффективность алгоритмов STL» — ну, знаете, просто ради тренировки в мастерстве создания кричащих заголовков. Но всё же решил оставаться в рамках приличий — лучше получить от читателей комментарии по содержанию статьи, чем негодование по поводу её громкого названия.

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

Алгоритмы

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

Каждый раз, когда вам хочется написать очередной for — следует сначала вспомнить, нет ли в STL (или в boost) чего-то, что уже решает эту задачу в одну строку. Если есть — чаще лучше использовать это. Нам, однако, и в этом случае следует понимать, что за алгоритм лежит за вызовом стандартной функции, каковы его характеристики и ограничения.

Обычно, если наша проблема в точности совпадает с описанием алгоритма из STL, будет хорошей идеей взять и применить его «в лоб». Беда только в том, что данные не всегда хранятся в том виде, в котором их хочет получить реализованный в стандартной библиотеке алгоритм. Тогда у нас может возникнуть идея сначала преобразовать данные, а потом всё же применить тот же алгоритм. Ну, знаете, как в том анекдоте про математика «Затушить огонь из чайника. Задача сведена к предыдущей».
Читать полностью »

Фьютекс (futex — сокращение от «Fast userspace mutex») — это механизм, предложенный разработчиками Linux из IBM в 2002 году и вошедший в ядро в конце 2003 года. Основной идеей было предоставить более эффективный способ синхронизации пользовательских потоков с минимальным количеством обращений к ядру ОС.

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

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

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

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

История о подкастах

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

И вот вы решаете нанять людей, которые сделают для вас этот сайт. Вы пишете для них абсолютно чёткие требования:

  • Быстрая загрузка сайта в Северной Америке
  • Поддержка загрузки прошлых выпусков подкастов и трансляции в реальном времени текущих
  • Трансляция не должна падать или замирать в течении первых 15 минут для 99.99% пользователей. Желательно вообще никогда, но хотя бы так.
  • Интеграция с Google Adwords (а в будущем, возможно, и с аналогами)
  • Интеграция с трансляциями Facebook, поскольку там вы провожу свои передачи. Если можно создать альтернативное решение, которое будет позволять стримить более удобно — ещё лучше.

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

Читать полностью »

Введение

В этой статье мы попробуем разобраться чем на практике отличается механизм epoll от портов завершения (Windows I/O Completion Port или IOCP). Это может быть интересно системным архитекторам, проектирующим высокопроизводительные сетевые сервисы или программистам, портирующим сетевой код с Windows на Linux или наоборот.

Обе эти технологии весьма эффективны для обработки большого количества сетевых соединений.

Они отличаются от других методов по следующим пунктам:

  • Нет ограничений (кроме общих ресурсов системы) на общее количество наблюдаемых дескрипторов и типов событий
  • Масштабирование работает достаточно хорошо — если вы уже мониторите N дескрипторов, то переход к мониторингу N + 1 займёт очень мало времени и ресурсов
  • Достаточно легко задействовать пул потоков для параллельной обработки происходящих событий
  • Нет никакого смысла использовать при единичных сетевых соединениях. Все преимущества начинают проявляться при 1000+ соединений

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

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

В этой статье мы рассмотрим:

  • select()
  • poll()
  • epoll()
  • libevent

Читать полностью »

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

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

Читать полностью »

Недавно вышел Qt 5.11 и мне подумалось, что сейчас самое время обновить до него кое-какие мои проектики на Qt 1.0… Ладно, шучу :) На самом деле мне стало интересно, насколько хорошо за все эти годы развития фреймворка Qt нам удавалось сохранять обратную совместимость кода.

Qt гарантирует совместимость на уровне кода и бинарников при обновлении между минорными версиями фреймворка (и мы серьёзно относимся к этому обещанию). Вы не должны переписывать (или даже перекомпилировать) свой код при переходе на другую минорную версию Qt. Однако переходы между мажорными версиями требовали от нас идти на некоторые жертвы ради прогресса. С релиза Qt 1.0 в 1996 году мы ломали совместимость кода четыре раза: в версиях 2.0, 3.0, 4.0 (ох, это было болезненно!) и 5.0.

Мы старались даже в мажорных версиях сломать как можно меньше всего, но всё же это приходилось делать. Отсюда возникает вопрос: насколько сложно портировать приложение, написанное во времена Qt 1.0 до современного Qt 5.11?

Для ответа на этот вопрос я взял пример кода, который поставлялся с документацией на Qt 1.0 и постарался собрать его с помощью Qt 5. Наши публичные архивы содержат изменения начиная с версии 1.41, так что мне пришлось изрядно покопаться в дрейнейшей истории, пройти через логи четырёх разных систем контроля версий… но это я уже отвлекаюсь. Проект, который я планирую собрать, называется «t14» — поскольку это иллюстрация к 14-ой (и последней) главе оригинального руководства.

И вот, что мне пришлось проделать для его сборки.
Читать полностью »