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

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

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

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

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

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

За нас

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

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

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

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

• Лекции

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

• Зони за дискусии

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

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

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

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

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

• Щандовете на партньорите

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

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

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

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

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

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

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

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

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

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

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

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

Генератори, корутини и друга сладост със замъгляване на мозъка, Ади Шавит

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

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

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

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

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

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

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

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

Материали:

• Слайдове от C++ Русия — [«Генератори, корутини и друга сладост за разширяване на мозъка»]
• Видеозапис от доклада на 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);

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

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

За обработка на неопределен брой проверки се предлага да се използват вариадични шаблони и fold изрази. Да предположим, че искаме да проверим равенството на няколко променливи с елемент от 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)); 

Малко подобрение на ситуацията могат да предоставят параметрите на шаблона без тип. С тяхна помощ ще преместим изброените елементи от enum’a в списъка на параметрите на шаблона: 

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

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

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 и поглеждаме неговия неподреден синтаксис, свързан с параметричния пакет в замиквания на лямбди;
• Даваме на компилатора повече възможности за оптимизация с условен noexcept; 
• Погрижете се за по-разбираем изход на грешки в шаблони чрез явни върнати стойности от лямбди. Това ще накара компилатора да извършва повече проверки преди действителното извикване на шаблонната функция – на етапа на проверка на типовете. 

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

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

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

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

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

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

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