[prog.c++] Альфа-версия обновленной поддержки CMake в SObjectizer

Задышала первая версия обновленных CMake-скриптов для SObjectizer-5.5.20. Взять и попробовать можно вот из этого архива. Взять и попробовать очень желательно, ибо сами мы не местные CMake в своей работе не используем. Поэтому на своих повседневных задачах проверить правильность сделанных CMake-скриптов не можем. А вот тем, кто использует SObjectizer именно через CMake наши изменения могут помочь. Или навредить :)

Итак, что было сделано? Было сделано так, чтобы SObjectizer можно было через CMake собрать, затем выполнить make install, затем задействовать у себя в проекте посредством find_package.

Попробую пояснить на пальцах. Для Unix-подобных систем, т.к. там проще.

Скачиваем архив с SObjectizer-ом, распаковываем его: unzip so-5.5.20-alpha2-201711251230.zip и заходим в образовавшийся каталог so-5.5.20-alpha2-201711251230. Там выполняем следующие действия:

mkdir cmake_build
cd cmake_build
cmake ../dev
cmake --build . --config Release
cmake --build . --config Release --target install

Будет скомпилирован только SObjectizer в виде статической и динамической библиотек. После этого он будет установлен в стандартных для вашего Unix-а путях (например, в /usr/local/include, /usr/local/lib).

Если у вас CMake-3.8 или более новый, то для того, чтобы использовать SObjectizer в своем CMake проекте вы пишете что-то вроде:

cmake_minimum_required(VERSION 3.1) project(hello_world) find_package(so_5 5.5.20 REQUIRED) add_executable(hello_world_static hello_world.cpp) target_link_libraries(hello_world_static so_5::StaticLib)

Тут строится приложение hello_world_static, которое линкуется к статической версии SObjectizer-а.

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

cmake_minimum_required(VERSION 3.1) project(hello_world) find_package(so_5 5.5.20 REQUIRED) add_executable(hello_world_shared hello_world.cpp) target_link_libraries(hello_world_shared so_5::SharedLib)

Ну и компилируете это обычным образом.

Если же вы под Windows или не хотите гадить в своем уютненьком Unix-е в стандартные пути для размещения библиотек, то можно поступить, например, так (предполагаем, что ~ -- это ваш рабочий каталог, в рамках которого вы хотите оставаться, и в который вы уже скачали so-5.5.20-alpha2-201711251230.zip):

~$ unzip so-5.5.20-alpha2-201711251230.zip
~$ cd so-5.5.20-alpha2-201711251230
~/so-5.5.20-alpha2-201711251230$ mkdir cmake_build
~/so-5.5.20-alpha2-201711251230$ cd cmake_build
~/so-5.5.20-alpha2-201711251230/cmake_build$ cmake -DCMAKE_INSTALL_PREFIX=target -G "Visual Studio 12 2013" ../dev
~/so-5.5.20-alpha2-201711251230/cmake_build$ cmake --build . --config Release
~/so-5.5.20-alpha2-201711251230/cmake_build$ cmake --build . --config Release --target install
~/so-5.5.20-alpha2-201711251230/cmake_build$ cd ~/hello_world
~/hello_world$ mkdir cmake_build
~/hello_world/cmake_build$ cmake -DCMAKE_PREFIX_PATH=~/so-5.5.20-alpha2-201711251230/cmake_build/target -G "Visual Studio 12 2013" ..
~/hello_world/cmake_build$ cmake --build . --config Release

Для Unix-а, естественно, придется поменять значение в -G (либо вообще -G не указывать, т.к. под Unix-ами обычно имеется всего один тулсет).

Если у вас более старый CMake, чем CMake-3.8, то придется выполнить в своих CMakeLists.txt дополнительные действия: нужно указать, что вам требуется C++11. Например, это можно сделать в вашем главном CMakeLists.txt:

cmake_minimum_required(VERSION 3.1) set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) project(hello_world) find_package(so_5 5.5.20 REQUIRED) add_executable(hello_world_shared hello_world.cpp) target_link_libraries(hello_world_shared so_5::SharedLib)

Пример того, как можно подключать SObjectizer через find_package, можно увидеть в этом репозитории (см. dev/CMakeLists.txt).

---

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

~/your_project_root
  `- so_5/
  `- timertt/
  `- your_another_project/
  `- your_main_project/
  ...
  CMakeLists.txt

И вот в своем главном CMakeLists.txt вы имеете возможность сделать просто add_subdirectory(so_5) и все. Далее вы должны получить возможность использовать so_5::StaticLib и so_5::SharedLib в своих CMake-овских командах target_link_libraries.

Пример того, как можно подключать SObjectizer через add_subdirectory, можно увидеть в этом репозитории (см. dev/CMakeLists.txt).

---

В общем, еще раз просьба к тем, кто использует SObjectizer совместно с CMake: попробуйте новую версию. Любой фидбек нам будет полезен и поможет сделать поддержку CMake более удобной.

[prog.c++] Шаблоны против копипасты 7: вывод нужных типов из указателей на методы

В коде решения для Highload Cup-а Коли Гродзицкого обнаружился интересный способ использования C++ных шаблонов для того, чтобы избавится от копипасты. Насколько я понимаю, суть проблемы была в следующем:

Есть класс database_t, который нужно наполнить экземплярами структур user_t, location_t и visit_t. Структуры же эти вычитываются из JSON-файлов. Т.е. есть файлик вроде users_1.json, из которого нужно прочитать все JSON-объекты, преобразовать их в экземпляры user_t и запихнуть все эти экземпляры в database_t. Тоже самое нужно сделать с visits_1.json (структуры visit_t) и locations_1.json (структуры location_t).

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

[prog.c++] Что и как следует улучшить в CMake-овских скриптах для SObjectizer?

Благодаря помощи Алексея Сырникова в SObjectizer уже несколько лет есть поддержка CMake. Сейчас, по ходу разработки очередной версии, мы хотим улучшить эту поддержку. Посему обращаемся ко всем, кто пытался использовать SO-5 и CMake с вопросами:

Что вам мешало в существующих CMake-скриптах для SO-5?

Чего вам не хватает в существующих CMake-скриптах для SO-5?

Что вам хотелось бы видеть в CMake-скриптах для SO-5?

К счастью, сами-то мы не настоящие сварщики пользуемся CMake, поэтому нам самим сложно судить о том, насколько удобны или неудобны существующие скрипты. Соответственно, нужна помощь тех, кто попробовал воспользоваться CMake для SO-5 и столкнулся с какими-либо сложностями/проблемами/недостатками.

[prog.thoughts] В догонку к докладу на GECon-2017

В презентации к докладу на GECon-2017 почти 90 слайдов. При этом довелось выбросить еще с десяток слайдов, которые могли бы сделать изложение более интересным и плавным, что ли. Все-таки временные рамки в 40 минут на доклад дали о себе знать.

При этом осталось впечатление, что если не ограничиваться 40 минутами, а исходить хотя бы из часа-полутора, то на базе этого доклада можно было бы сделать неплохую лекцию о том, как C++ появился, почему оказался востребованным, почему его востребованность снизилась, почему при этом C++ так и не закопали (и не закопают), где и как можно (нужно) применять C++ в современных условиях, насколько сильна конкуренция со стороны других языков и почему тут все далеко не так однозначно (даже в случае с Rust-ом).

В общем, если кто-то заинтересуется такой лекцией, то дайте знать. Я сам пока не очень понимаю, зачем это лично мне (наверное, просто потому, что могу). Но, если будут интересные идеи, то почему бы и не сотворить что-нибудь? В конце-концов, не думаю, что у нас в РБ так уж много действующих C++ разработчиков, использующих C++ на протяжении 25 лет.

[prog] Краткие впечатления от участия в GECon-2017

18-го ноября 2017-го в Гомеле EPAM провел очередную большую и бесплатную ИТ-конференцию GECon-2017. Для нашего небольшого города событие, прямо скажем, далеко не рядовое. Мне довелось поучаствовать в конференции в качестве докладчика (насколько я понял, в качестве единственного не-EPAM-овского докладчика).

В целом мне очень понравилось. В этом году мне довелось поучаствовать в нескольких конференциях, могу сказать, что подготовка к GECon-у была одной из самых серьезных. Может быть даже жестче и строже, чем подготовка к C++Russia. Так что в качестве результата сомневаться не приходилось изначально. На фоне этого мне даже удивительно, что на конференцию заявилось всего 300 человек, а не в 2-3 раза больше. Высокий уровень подготовки, докладчики, имеющие опыт работы на очень серьезных проектах, бесплатность и место проведения прям в центре Гомеля... Как по мне, так глупо упускать шанс принять участие в таком мероприятии.

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

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

Слайды доклада лежат здесь. Ссылку на видео добавлю когда организаторы конференции зальют видео выступлений на какой-нибудь публичный ресурс.

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

Во-первых, организаторам надо бы более четко определиться с тем, какова основная цель конференции. У меня сложилось ощущение, что сами организаторы не очень понимали, какую именно цель они преследуют. Если цель в том, чтобы "прорекламировать" ЕПАМ, рассказать, насколько это крутая компания, насколько хорошо для ИТ-специалиста в ней работать, какие перспективы там ждут классных специалистов, то это одно. Если цель в том, чтобы создать площадку для независимого обмена опытом, типа "у нас в ЕПАМе есть куча опыта, вокруг ЕПАМа есть куча другого опыта, давайте соберемся и обменяемся этим опытом", то это другое. Если цель в том, чтобы организовать обмен опытом между сотрудниками самого ЕПАМа (а их много, компания ведет тысячи разнообразных проектов, поэтому даже сотрудники одного регионального офиса ЕПАМа могут иметь совершенно разный опыт), то это третье.

На этой конференции мне временами мешало то, что в докладах всплывала какая-то внутренняя ЕПАМовская специфика, которую не понимали люди извне. При этом какая-то важная информация не могла быть озвучена (например, имена заказчиков, для которых выполнялись те или иные работы, параметры нагрузки и другая интересная информация). В результате складывалось такое ощущение: "мы хотим прорекламировать себя, но сделать под видом обмена опытом, но без учета того, что может быть интересно людям не из ЕПАМа".

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

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

---

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