C++ Русия: как се случи

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

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

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

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

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

За нас

На тази длъжност са работили двама студенти от Националния изследователски университет „Висше училище по икономика“ – Санкт Петербург:

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

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

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

• Доклади

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

• Дискусионни зони

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

• Светкавични разговори и неформални дискусии

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

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

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

• Партньорски стойки

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

Технически детайли на отчетите

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

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

Слайд от представяне

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

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

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

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

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

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

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

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

Слайд от представяне

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

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

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

Слайд от представяне

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

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

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

материали:

• Слайдове от C++ Русия - ["Генератори, съпрограмми и други сладости за развиване на мозъка"]
• Видеозапис на репортажа от CppCon 2019

C++ трикове от Yandex.Taxi, Антон Полухин

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

Може би най-интересният пример беше прилагането на модела от указател към изпълнение (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 файла: имаме нужда от предварителна декларация на опакования 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<kImplSize, kImplAlign> data_; 
};

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

~FastPimpl() noexcept { 
    validate<sizeof(T), alignof(T)>(); 
    Ptr()->~T(); 
}

template <std::size_t ActualSize, std::size_t ActualAlignment>
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++ трикове от Taxi"]

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

В този разговор Бьорн Фалер показва няколко различни начина за борба със стилистичния недостатък на многократните проверки на състоянието:

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

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

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

За да се справите с нефиксиран брой проверки, незабавно трябва да използвате променливи шаблони и изрази за сгъване. Да приемем, че искаме да проверим равенството на няколко променливи спрямо елемента state_type на enum. Първото нещо, което идва на ум е да напишем помощна функция is_any_of:

enum state_type { IDLE, CONNECTED, DISCONNECTED };

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

Този междинен резултат е разочароващ. Засега кодът не става по-четлив:

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

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

template <state_type ... states>
bool is_any_of(state_type t) { 
    return ((t == states) | ...); 
}
	
assert(is_any_of<IDLE, DISCONNECTING, DISCONNECTED>(state)); 

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

template <auto ... alternatives, typename T>
bool is_any_of(const T& t) {
    return ((t == alternatives) | ...);
}

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

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

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

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

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

Накрая не забравяйте да го излъскате:

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

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

• Докладвайте слайдове: [Съвременни техники за поддържане на вашия код СУХ]
• Изходен код в github
• Статия в блога на автора

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

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

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

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

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