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

Ако на почетокот на претставата кажете дека на ѕидот виси шифра C++, тогаш до крајот е обврзана да ви пука во нога.

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

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

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

Фотографија од конференциски албум

за нас

Двајца студенти од високото економско училиште за националниот истражувачки универзитет - Санкт Петербург работеа на овој пост:

• Лиза Василенко е студентка на 4-та година на додипломски студии која студира програмски јазици како дел од програмата за применета математика и компјутерски науки. Откако се запознав со јазикот C++ во мојата прва година на универзитет, последователно стекнав искуство работејќи со него преку практиканти во индустријата. Страста кон програмските јазици воопшто и конкретно функционалното програмирање остави свој белег на изборот на извештаи на конференцијата.
• Дања Смирнов е студент во прва година на магистерската програма „Програмирање и анализа на податоци“. Уште додека бев на училиште пишував проблеми на Олимпијадата на C++, а потоа некако се случи јазикот постојано да се појавува во образовните активности и на крајот да стане главен работен јазик. Решив да учествувам на конференцијата за да го подобрам моето знаење и да научам за новите можности.

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

Конференциска структура

• Извештаи

Во текот на два дена, експертите прочитаа 30 извештаи, покривајќи многу жешки теми: генијална употреба на јазичните карактеристики за решавање применети проблеми, претстојни јазични ажурирања во врска со новиот стандард, компромиси во дизајнот на C++ и мерки на претпазливост при работа со нивните последици, примери на интересна проектна архитектура, како и некои детали под капакот на јазичната инфраструктура. Три претстави се одржаа истовремено, најчесто две на руски и една на англиски јазик.

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

По завршувањето на говорот, сите непоставени прашања и недовршени дискусии беа префрлени во специјално одредени области за комуникација со говорниците, опремени со табли за маркери. Добар начин да ја оддалечите паузата помеѓу говорите со пријатен разговор.

• Молња разговори и неформални дискусии

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

Друг формат е панел дискусијата „Со комисија од срце до срце“. На сцената се некои членови на комисијата за стандардизација, на проекторот е каминот (официјално - за да се создаде искрена атмосфера, но причината „бидејќи СЕ ГОРИ“ изгледа посмешна), прашања за стандардот и општата визија на C++ , без жестоки технички дискусии и холивари. Се испостави дека комитетот содржи и живи луѓе кои можеби не се целосно сигурни во нешто или можеби не знаат нешто.

За љубителите на холиварите, третиот настан остана на случајот - сесијата на БОФ „Оди наспроти C++“. Земаме Go lover, љубител на C++, пред почетокот на сесијата заедно подготвуваат 100500 слајдови на тема (како проблеми со пакетите во C++ или недостатокот на генерики во Go), а потоа имаат жива дискусија меѓу себе и со публиката, а публиката се обидува да разбере две гледишта одеднаш. Ако холиварот почне надвор од контекст, модераторот интервенира и ги помирува страните. Овој формат предизвикува зависност: неколку часа по почетокот, само половина од слајдовите беа завршени. Крајот мораше многу да се забрза.

• Партнер стои

Партнерите на конференцијата беа застапени во салите - на штандовите зборуваа за тековни проекти, нудеа практиканти и вработување, одржуваа квизови и мали натпревари, а наградуваа и убави награди. Во исто време, некои компании дури понудија да поминат низ почетните фази на интервјуа, што може да биде корисно за оние кои дојдоа не само да слушаат извештаи.

Технички детали за извештаите

Слушавме извештаи двата дена. На моменти беше тешко да се избере еден извештај од паралелните - се договоривме да се разделиме и да го размениме знаењето стекнато за време на паузите. И покрај тоа, се чини дека многу е изоставено. Овде би сакале да зборуваме за содржината на некои од извештаите кои ни се најинтересни

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

Лизгајте од презентација

Како што сугерира насловот, Роман гледал на работа со исклучоци користејќи го LLVM како пример. Во исто време, за оние кои не користат Clang во својата работа, извештајот сè уште може да даде одредена идеја за тоа како кодот потенцијално би можел да се оптимизира. Тоа е така затоа што развивачите на компајлери и соодветните стандардни библиотеки комуницираат едни со други и многу успешни решенија може да се совпаднат.

Значи, за да се справите со исклучок, треба да направите многу работи: повикајте го кодот за ракување (ако има) или бесплатни ресурси на тековното ниво и вртете го оџакот повисоко. Сето ова води до фактот дека компајлерот додава дополнителни инструкции за повици кои потенцијално фрлаат исклучоци. Затоа, ако исклучокот всушност не се подигне, програмата сепак ќе врши непотребни дејства. Со цел некако да ги намали трошоците, LLVM има неколку хеуристики за одредување ситуации кога кодот за ракување со исклучоци не треба да се додава или може да се намали бројот на „дополнителни“ инструкции.

Говорникот испитува околу десетина од нив и ги прикажува двете ситуации каде што помагаат да се забрза извршувањето на програмата и оние каде што овие методи не се применливи.

Така, Роман Русјаев ги наведува студентите до заклучок дека кодот што содржи ракување со исклучоци не може секогаш да се изврши со нула надземни трошоци и го дава следниот совет:

• кога се развиваат библиотеки, вреди да се напуштат исклучоците во принцип;
• ако сè уште се потребни исклучоци, тогаш секогаш кога е можно, вреди да се додаваат noexcept (и const) модификатори насекаде за да може компајлерот да оптимизира што е можно повеќе.

Генерално, говорникот го потврди ставот дека исклучоците најдобро се искористуваат на минимум или целосно се напуштаат.

Слајдовите од извештајот се достапни на следниот линк: [„Исклучоци од C++ преку објективот на оптимизациите на компајлерот на LLVM“]

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

Лизгајте од презентација

Еден од многуте извештаи на оваа конференција посветена на иновациите во C++20 беше запаметен не само по нејзината живописна презентација, туку и по јасното идентификување на постоечките проблеми со логиката за обработка на колекцијата (за јамка, повратни повици).

Ади Шавит го истакнува следново: моментално достапните методи минуваат низ целата колекција и не обезбедуваат пристап до некоја внатрешна средна состојба (или тие го прават во случај на повратни повици, но со голем број непријатни несакани ефекти, како што е Повратен повик пекол) . Се чини дека има итератори, но дури и со нив сè не е толку мазно: нема заеднички влезни и излезни точки (почеток → крај наспроти rbegin → rend и така натаму), не е јасно колку долго ќе повторуваме? Почнувајќи од C++20, овие проблеми се решени!

Прва опција: опсези. Со завиткување итератори, добиваме заеднички интерфејс за почетокот и крајот на итерацијата, а добиваме и можност за компонирање. Сето ова го олеснува изградбата на полноправни цевководи за обработка на податоци. Но, не е сè толку мазно: дел од логиката за пресметка се наоѓа во имплементацијата на специфичен итератор, што може да го комплицира кодот за разбирање и дебагирање.

Лизгајте од презентација

Па, за овој случај, C++20 додаде корутини (функции чие однесување е слично на генераторите во Python): извршувањето може да се одложи со враќање на некоја тековна вредност додека се зачува средната состојба. Така, постигнуваме не само да работиме со податоци како што изгледаат, туку и да ја инкапсулираме целата логика во одредена корутина.

Но, има мува во маст: во моментот тие се само делумно поддржани од постојните компајлери, а исто така не се имплементирани толку уредно како што би сакале: на пример, сè уште не вреди да се користат референци и привремени објекти во корутините. Плус, има некои ограничувања за тоа што може да биде корутини, а функциите на constexpr, конструкторите/деструкторите и главните не се вклучени во оваа листа.

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

Материјали:

• Слајдови од 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++ трикови од Такси“]

Современи техники за чување на вашиот код СУВО, Бјорн Фалер

Во овој говор, Бјорн Фалер покажува неколку различни начини за борба против стилскиот недостаток на повторените проверки на состојбата:

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)); 

Параметрите на шаблонот без тип ќе помогнат малку да се подобри ситуацијата. Со нивна помош, ќе ги пренесеме бројните елементи на енумот на списокот со параметри на шаблонот: 

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

Со користење на автоматско во параметар на шаблон што не е тип (C++17), пристапот едноставно се генерализира на споредбите не само со елементите од типот на состојба, туку и со примитивните типови кои можат да се користат како параметри на шаблоните што не се типови:

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) се објаснети со користење на примери за употреба. (Да, сега синтаксата ламбда е уште полесна за запомнување - ова се четири последователни пара загради од сите видови.) Конечното решение користејќи функции како детали за конструктор навистина ми ја загрева душата, а да не го спомнуваме изразот торка во најдобрите традиции на ламбда калкулус.

На крајот, не заборавајте да го полирате:

• Запомнете дека ламбдите се constexpr бесплатно; 
• Ајде да додадеме совршено препраќање и да ја погледнеме неговата грда синтакса во однос на пакетот параметри во ламбда затворањето;
• Да му дадеме на компајлерот повеќе можности за оптимизации со условно noexcept; 
• Ајде да се грижиме за поразбирлив излез на грешки во шаблоните благодарение на експлицитните повратни вредности на ламбда. Ова ќе го принуди компајлерот да направи повеќе проверки пред всушност да се повика функцијата на шаблонот - во фазата на проверка на типот. 

За детали, погледнете ги материјалите од предавањето: 

• Пријави слајдови: [Современи техники за чување на вашиот код на суво]
• Изворниот код на github
• Статија на блог на авторот

Нашите впечатоци

Нашето прво учество во C++ Русија беше незаборавно по својот интензитет. Добив впечаток за C++ Русија како искрен настан, каде што границата помеѓу обуката и комуникацијата во живо е речиси незабележлива. Сè, од расположението на говорниците до натпреварите од партнерите на настанот, е погодно за жестоки дискусии. Содржината на конференцијата, составена од извештаи, опфаќа прилично широк опсег на теми, вклучувајќи иновации во C++, студии на случај на големи проекти и идеолошки архитектонски размислувања. Но, би било неправедно да се игнорира социјалната компонента на настанот, што помага да се надминат јазичните бариери во однос не само со C++.

Им благодариме на организаторите на конференцијата за можноста да учествуваме на ваков настан!
Можеби сте ја виделе објавата на организаторите за минатото, сегашноста и иднината на C++ Русија на блогот JUG Ru.

Ви благодариме за читањето и се надеваме дека нашето прераскажување на настани беше корисно!

Извор: www.habr.com