C++ Русия: как беше

Ако в началото на пиесата казвате, че на стената висява код на C++, то в края той непременно трябва да ви стреля в крака.

Бярне Строуструп

От 31 октомври до 1 ноември в Санкт Петербург се проведе конференцията C++ Russia Piter – едно от мащабните събития по програмиране в Русия, организирано от JUG Ru Group. Сред поканените лектори са членове на комитета по стандартизация на C++, докладчици от CppCon, автори на книги от издателство O’Reilly, както и поддържатели на проекти като LLVM, libc++ и Boost. Конференцията е насочена към опитни разработчици на C++, които искат да задълбочат експертизата си и да обменят опит в жива комуникация. Студентите, аспирантите и преподавателите в университетите получават много приятни отстъпки.

Московското издание на конференцията може да бъде посещавано още през април следващата година, а междувременно нашите студенти ще разкажат какво интересно узнали на преминалото събитие. 

Снимка от албума на конференцията

За нас

По този пост работиха две студентки от НИУ ВШЭ – Санкт Петербург:

• Лиза Василенко – студентка от 4-ти курс бакалавриат, изучаваща направление „Езици за програмиране“ в програмата „Приложна математика и информатика“. Запознавайки се с езика C++ още на първата година в университета, по-късно придобила опит с него на стажове в индустрията. Увлечението по езици за програмиране като цяло и функционалното програмиране в частност повлияло на избора на теми за докладите на конференцията.
• Даня Смирнов – студент от 1-ви курс магистратура „Програмиране и анализ на данни“. Още в училище решавал задачи от олимпиади на C++, а след това, така се случи, че езикът постоянно се появявал в учебната му дейност и в крайна сметка станал основният работен инструмент. В конференцията решил да участва, за да подобри знанията си и да научи за новите възможности.

В разпространението ръководството на факултета често споделя информация за образователни събития, свързани с нашата специалност. През септември видяхме информация за C++ Russia и решихме да се регистрираме като слушатели. Това е нашият първи опит в участия в подобни конференции.

Структура на конференцията

• Доклади

В течение на два дни експертите прочетоха 30 доклада, обсъждайки много актуални теми: остроумните приложения на функциите на езика за решаване на практически задачи, предстоящите актуализации на езика във връзка с новия стандарт, компромисите при дизайна на C++ и мерките за безопасност при работа с техните последствия, примери за интересна архитектура на проекти, както и някои задкулисни детайли на инфраструктурата на езика. Паралелно се провеждаха по 3 изказвания, като по-често две на руски и едно на английски език.

• Зони за обсъждане

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

• Lightning Talks и неформални дискусии

Ако желаете да направите кратка презентация, можете да се запишете на маркерната дъска за вечерния Lightning Talk и ще имате пет минути за разказване на всичко, свързано с темата на конференцията. Например, бързо въведение в sanitizers за C++ (за някои оказа новост) или история за бъг в генерирането на синусоида, който може да бъде чут, но не и видян.

Другият формат е панелна дискусия „С комитета по душите“. На сцената са някои членове на комитета по стандартизация, на проектора — камина (официално — за създаване на уютна атмосфера, но причината „защото ВСИЧКО Е В ОГЪН“ изглежда по-забавна), въпросите са за стандарта и общото виждане за C++, без бурни технически обсъждания и холивари. Оказа се, че в комитета също има живи хора, които могат в нещо да не са напълно уверени или нещо да не знаят.

За любителите на холиварите по същество остава третото събитие — BOF-сесия „Go срещу C++“. Взимаме любител на Go, любител на C++, преди началото на сесията те заедно подготвят 100500 слайда по темата (като например проблемите с пакетите в C++ или отсъствието на генерични типове в Go), а след това оживено дискутират помежду си и с аудиторията, а залата се опитва да разбере едновременно две гледни точки. Ако започне холивар без причина — модераторът намесва и помирява страните. Такъв формат затегля: след няколко часа след началото бяха прекарани само половин слайд. Краят трябваше да бъде значително ускорен.

• Павилиони на партньорите

В залите бяха представени партньорите на конференцията — на павилионите разказваха за текущите проекти, предлагаха стажове и работа, провеждаха викторини и малки състезания, както и раздаваха приятни награди. Освен това някои компании дори предлагаха да преминат начален етап на интервюта, което може да е полезно за тези, които са дошли не само за да слушат доклади.

Технически подробности на докладите

Слушахме докладите и двата дни. Понякога беше трудно да се избере един доклад от паралелно протичащите — договорихме се да се разделим и да обменяме придобитите знания в почивките. И дори така изглежда, че много е останало пропуснато. Тук бихме искали да разкажем за съдържанието на някои от докладите, които ни се сториха най-интерсни.

Изключения в C++ през призмата на компилаторните оптимизации, Роман Русяев

Слайд от презентацията

Както личи от заглавието, Роман разглежда работата с изключения на примера на LLVM. Дори и за тези, които не използват Clang в работата си, докладът все пак може да предостави представа за начина, по който кодът потенциално може да бъде оптимизиран. Това е така, защото разработчиците на компилатори и съответните стандартни библиотеки си взаимодействат помежду си и много успешни решения могат да съвпадат.

Следователно, за обработка на изключение е необходимо да се извършат множество действия: да се извика код за обработка (ако има такъв) или да се освободят ресурсите на текущото ниво и да се изкачи стека нагоре. Всичко това води до факта, че за потенциално предаващите изключения извиквания, компилаторът добавя допълнителни инструкции. Следователно, дори когато изключението в действителност не бъде предизвикано, програмата все пак ще извършва ненужни действия. За да се намалят разходите, в LLVM има няколко христики за определяне на ситуации, в които не трябва да се добавя код за обработка на изключения или където може да се намали броят на "излишните" инструкции.

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

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

• при разработване на библиотеки трябва да се откажете от изключенията като цяло;
• ако изключенията все пак са необходими, то навсякъде, където е възможно, трябва да се добавят модификатори noexcept (и const), за да може компилаторът да оптимизира колкото се може повече.

Като цяло, докладчикът потвърди мнението, че изключенията е най-добре да се използват в минимално количество или изобщо да се откажат.

Слайдове от доклада са налични на следния линк: [«Исключения C++ через призму компиляторных оптимизаций LLVM»]

Generators, coroutines and other brain-unrolling sweetness, Adi Shavit

Слайд от презентацията

Един от многото доклади на тази конференция, посветени на нововъведенията в C++20, запомни не само с красочно оформената презентация, но и с ясното обозначение на съществуващите проблеми с логиката на обработка на колекции (цикъл for, callback-и).

Adi Shavit отделя следните: съществуващите в момента методи преминават през цялата колекция и в същото време не дават достъп до някакво вътрешно междинно състояние (или дават в случай на callback-ове, но с много неприятни странични ефекти, като т.нар. Callback Hell). Изглежда, че има итератори, но и с тях всичко не е толкова гладко: няма общи точки за вход и изход (begin → end срещу rbegin → rend и така нататък), не е ясно колко именно ще итерираме? Започвайки от C++20, тези проблеми се решават!

Първият вариант: ranges. С помощта на обвивката над итераторите получаваме общ интерфейс за началото и края на итерацията, както и възможност за композиция. Всичко това позволява лесно изграждане на пълноценни конвейери за обработка на данни. Но не всичко е толкова гладко: част от логиката на изчисленията се намира вътре в конкретната реализация на итератора, което може да усложни кода за възприемане и отстраняване на грешки.

Слайд от презентацията

В такъв случай в C++20 са добавени корутини (функции, чието поведение е подобно на генераторите в Python): изпълнението може да бъде отложено, като се върне текуща стойност с запазване на междинното състояние. Така постигаме не само работа с данни както се появяват, но и инкапсулираме цялата логика в конкретната корутина.

Но има и тъга: в момента те са само частично поддържани от наличните компилатори и са реализирани не толкова добре, колкото бихме искали: например, все още не се препоръчва да се използват референции и времеви обекти в корутини. Плюс, има някои ограничения относно това какво може да бъде корутина, и constexpr функции, конструктори/деструктори, както и main не влизат в този списък.

Следователно, корутините решават значителна част от проблемите с простотата на логиката за обработка на данни, но техните текущи реализации изискват доработка.

Материали:

• Слайдове от C++ Russia — [„Генератори, корутини и други сладости за мозъка“]
• Видеозапис от доклада на CppCon 2019

C++ трикове от Яндекс.Такси, Антон Полухин

В професионалната си дейност понякога ми се налага да реализирам чисто спомагателни неща: обвивка между вътрешния интерфейс и API на някаква библиотека, логване или парсинг. При това обикновено няма нужда от допълнителна оптимизация. Но какво, ако тези компоненти се използват в някои от най-популярните услуги в Рунета? В такава ситуация ще трябва да обработвам терабайти на час само от логовете! Тогава всяка милисекунда е от значение и затова се налага да прибегна до различни трикове — за тях разказа Антон Полухин.

Може би най-интересният пример беше реализацията на шаблона pointer-to-implementation (pimpl). 

#include <third_party/json.hpp> //PROBLEMS! 
struct Value { 
    Value() = default; 
    Value(Value&& other) = default; 
    Value& operator=(Value&& other) = default; 
    ~Value() = default; 

    std::size_t Size() const { return data_.size(); } 

private: 
    third_party::Json data_; 
};

В този пример първо искам да се отърва от заглавните файлове на външните библиотеки — така и компилирането ще бъде по-бързо, и мога да се предпазя от възможни конфликти на имена и други подобни грешки. 

Добре, преместихме #include в .cpp файла: нужен е forward-declaration на обвивния API, а също и std::unique_ptr. Сега имаме динамично разпределение и други неприятни неща, като разпръснати по купчината данни и намалени гаранции. С всичко това може да помогне std::aligned_storage. 

struct Value { 
// ... 
private: 
    using JsonNative = third_party::Json; 
    const JsonNative* Ptr() const noexcept; 
    JsonNative* Ptr() noexcept; 

    constexpr std::size_t kImplSize = 32; 
    constexpr std::size_t kImplAlign = 8; 
    std::aligned_storage_t data_; 
};

Единственият проблем е, че за всяка обвивка трябва да зададем размер и подравняване — ще направим нашия pimpl шаблонен с параметри , ще използваме произволни стойности и ще добавим проверка в деструктора, за да видим дали всичко е на място: 

~FastPimpl() noexcept { 
    validate(); 
    Ptr().->~T(); 
}

template 
static void validate() noexcept { 
    static_assert(
        Size == ActualSize, 
        "Size and sizeof(T) mismatch"
    ); 
    static_assert(
        Alignment == ActualAlignment, 
        "Alignment and alignof(T) mismatch"
    ); 
}

Тъй като при обработка на деструктора T вече е определен, този код ще се анализира правилно и на етапа на компилация ще дава нужните стойности на размера и подравняването като грешки. По този начин, с цената на един допълнителен компилационен цикъл, избягваме динамичното алоциране на обвивни класове, скриваме API в .cpp файл с реализация, и получаваме конструкция, която е по-подходяща за кеширане от процесора.

Логването и парсинга изглеждат по-малко впечатляващи и затова в този обзор няма да бъдат споменати.

Слайдове от доклада са налични на следния линк: [„C++ трикове от Такси“]

Съвременни техники за поддържане на вашия код DRY, Björn Fahller

В този доклад Björn Fahller показва няколко различни начина за справяне с такъв стилистичен недостатък, като повтарящи се проверки на условия:

assert(a == IDLE || a == CONNECTED || a == DISCONNECTED);

Звучи познато? С използването на няколко мощни техники от C++, появили се в последните стандарти, може изящно да реализирате същата функционалност без никакви загуби на производителност. Сравнете:   

assert(a == any_of(IDLE, CONNECTED, DISCONNECTED));

За обработка на непостоянен брой проверки веднага е логично да се използват variadic templates и fold expressions. Да предположим, че искаме да проверим дали няколко променливи са равни на елемент от enum'a state_type. Първото, което идва наум – да напишем спомагателна функция is_any_of:

enum state_type { IDLE, CONNECTED, DISCONNECTED }; 

template 
bool is_any_of(state_type s, const Ts& ... ts) { 
    return ((s == ts) || ...); 
}

Тази междинна стъпка създава разочарование. До момента кодът не става по-четим:

assert(is_any_of(state, IDLE, DISCONNECTING, DISCONNECTED)); 

Малките подобрения в ситуацията ще ни помогнат non-type template parameters. С тях ще преместим елементите на enum'a в списъка с параметри на шаблона: 

template 
bool is_any_of(state_type t) { 
    return ((t == states) | ...); 
}
	
assert(is_any_of(state)); 

С използването на auto в не-типов параметър на шаблона (C++17), подходът просто се обобщава, за да сравнява не само с елементите на state_type, но и с примитивни типове, които могат да се използват като non-type template parameters:

template 
bool is_any_of(const T& t) {
    return ((t == alternatives) | ...);
}

С последователност от такива подобрения се постига желаният гладък синтаксис за проверки:

template 
struct any_of : private std::tuple { 
// поленимся и унаследуем конструкторы от tuple 
		using std::tuple::tuple;
		template 
		bool operator ==(const T& t) const {
			return std::apply(
				[&t](const auto& ... ts) {
					return ((ts == t) || ...);
				},
				static_cast<const std::tuple&>(*this));
		}
};

template 
any_of(Ts ...) -> any_of;
 
assert(any_of(IDLE, DISCONNECTING, DISCONNECTED) == state);

В този пример ръководството за извод служи за подсказка на компилатора какви желаеми шаблонни параметри има структурата, знаеща типовете на аргументите на конструктора. 

По-нататък става интересното. Бьорн учи как да обобщим получения код за оператори за сравнение, освен ==, а след това и за произволни операции. По време на примера се обясняват и функции като no_unique_address attribute (C++20) и шаблонни параметри в лямбда-функции (C++20). (Да, теперь синтаксис на лямбдите е дори по-лесен за запомняне – това са четири последователни двойки скоби от всякакъв вид.) Финалното решение, използващо функции като детайли на конструктора, лично мен много радва, да не говорим за израза tuple в най-добрите традиции на лямбда-изчислението.

В края не забравяме да придадем блясък:

• Нека припомним, че лямбда-изразите са constexpr напълно безплатно; 
• Добавяме perfect forwarding и разглеждаме уродливия му синтаксис със параметърния пакет в лямбда-изразите;
• Предоставяме на компилатора повече възможности за оптимизация с conditional noexcept; 
• Грижим се за по-разбираемото извеждане на грешки в шаблоните, благодарение на явните възвращаеми стойности на лямбда-изразите. Това ще накара компилатора да извършва повече проверки преди действителното повикване на шаблонната функция – на етапа на проверка на типовете. 

За подробности се обърнете към материалите на лекцията: 

• Слайдове от доклада: [Modern Techniques for Keeping Your Code DRY]
• Изходния код на github
• Авторска статия в блога

Нашите впечатления

Нашето първо участие в C++ Russia запомни с богатството си. Създаде се представата за C++ Russia като за душевно събитие, където границата между обучението и живото общуване почти не се усеща. Всичко, от настроението на лекторите до конкурсите организирани от партньорите на събитието, насърчава бурни обсъждания. Съдържателната част на конференцията, състояща се от доклади, обхваща доста широк спектър теми, включително нововъведенията в C++, примери от практиката на големи проекти и идеологически архитектурни разсъждения. Но би било несправедливо да не обърнем внимание и на социалната характеристика на събитието, спомагаща за преодоляване на езиковите бари и по отношение на не само C++.

Благодарим на организаторите на конференцията за възможността да участва в такова събитие!
Постът на организаторите за миналото, настоящето и бъдещето на C++ Russia сте могли да видите в блога JUG Ru.

Благодарим за прочитанeto, и се надяваме, че нашето резюме на събитията е било полезно!

Източник: habr.com