C++ Venemaa: kuidas see oli

Kui näidatakse näidendis, et seinal ripub C++ kood, peab see lõpus kindlasti teile jalga tulistama.

Bjarne Stroustrup

31. oktoobrist 1. novembrini toimus Peterburis C++ Russia Piter konverents – üks suurimatest programmistide konverentsidest Venemaal, mida korraldab JUG Ru Group. Kutsutud esinejate seas on C++ standardimise komitee liikmed, CppCon'i ettekandjad, O'Reilly raamatute autorid, samuti LLVM, libc++ ja Boost projektide hooldajad. Konverents on suunatud kogenud C++ arendajatele, kes soovivad süvendada oma ekspertiisi ja vahetada kogemusi elavas suhtluses. Üliõpilastele, aspirantidele ja ülikoolide õppejõududele pakutakse väga meeldivaid allahindlusi.

Moskva väljaanne konverentsist on võimalik külastada juba järgmise aasta aprillis, kuid seni jagavad meie üliõpilased, mida huvitavat nad möödunud üritusel õppisid. 

Fotod konverentsi albumist

Meist

Selle postituse kallal töötasid kaks HSE üliõpilast – Peterburis:

• Lisa Vasilenko – neljanda kursuse bakalaureuseõppe üliõpilane, kes uurib programmeerimiskeelte suunda rakendusmatemaatika ja informaatika programmi raames. Tutvudes C++ keelega ülikooli esimesel kursusel, omandas ta hiljem kogemusi sellega tööstuses praktikal. Huvi programmeerimiskeelte, sealhulgas funktsionaalse programmeerimise vastu mõjutas tema konverentsil valitud ettekandeid.
• Danya Smirnov – esimese aasta magistrant programmide ja andmete analüüsi valdkonnas. Juba koolis lahendas ta C++ keeles olümpiaaditeemasid, ning edasi juhtus nii, et keel ilmnes pidevalt tema õppetegevuses ja muutus lõpuks peamiseks töökeeleks. Otsustas konverentsist osa võtta, et oma teadmisi täiendada ning uutest võimalustest teada saada.

Kursuse juhatus jagab sageli meie erialaga seotud haridusürituste teavet. Septembris nägime teavet C++ Russia kohta ja otsustasime registreeruda kuulajatena. See on meie esimene kogemus sarnastes konverentsides osalemiseks.

Konverentsi struktuur

• Ettekanded

Kaks päeva kestnudüritusel lugesid eksperdid 30 ettekannet, kajastades mitmeid kuumi teemasid: keele omaduste nutikad rakendused rakenduslike probleemide lahendamiseks, keele uued uuendused seoses uue standardiga, kompromissid C++ disainis ja ettevaatusabinõud nende tagajärgedega töötamisel, näited huvitavatest projektide arhitektuuridest ning mõned keele infrastruktuuri tagaküljed. Samal ajal toimusid kolm ettekannet, enamasti kaks vene keeles ja üks inglise keeles.

• Arutelualad

Ettekannete järel kanti kõik vastamata küsimused ja lõpetamata arutelud üle spetsiaalselt tähistatud suhtlemisaladeks, varustatud markeritahvlitega. Hea võimalus veeta paus ettekannete vahel meeldivas vestluses.

• Äkilised ettekanded ja mitteformaalsed arutelud

Kui soovi tekkis teha lühike ettekande, sai registreeruda markeritahvlile õhtusele äkilisele ettekandele, et rääkida viis minutit ükskõik millest konverentsi teemal. Näiteks kiire sissejuhatus C++ sanitiseerijatesse (mõne jaoks oli see uus) või lugu veast sinusoidi genereerimisel, mida saab ainult kuulda, kuid mitte näha.

Teine formaat — paneeldiskussioon „Komitee hingeelust“. Lavale on kutsutud mõned standardimiskomitee liikmed, projektoris on kamin (ametlikult — hingesooja atmosfääri loomiseks, kuid põhjus „sest KÕIK ON TULES“ tundub naljakam), küsimused on seotud standardiga ja C++ üldise visiooniga, ilma tormikate tehniliste arutelude ja vaidlusteta. Selgus, et komitees on ka elavad inimesed, kes võivad mõnes osas pole olla täiesti kindlad või midagist teada.

Vaidluste armastajatele jäi kolmas üritus — BOF-sessioon „Go C++ vastu“. Võtame Go armastaja, C++ armastaja, enne sessiooni teevad nad koos 100500 slaidi teemal (näiteks probleemid C++ paketihalduses või geneerikute puudumine Go-s), seejärel vaidlustavad nad elavalt üksteisega ja publikuga, kes püüab mõista kaht erinevat vaatenurka. Kui algab vaidlus, mis ei ole asjakohane, sekkub moderaator ja lepib pooled kokku. Selline formaat venib: paar tundi pärast algust oli läbitud vaid pool slaididest. Lõppu tuli kiirustada.

• Partnerite stendid

Konverentsi partnerite tutvustamiseks olid saalides välja pandud stendid, kus räägiti praegustest projektidest, pakuti praktika- ja töövõimalusi, korraldati viktoriine ja väikeseid võistlusi ning loositi meeldivaid auhindu. Samuti pakkusid mõned ettevõtted võimalust läbida esialgseid vestluse etappe, mis võib olla kasulik neile, kes tulid mitte ainult ettekandeid kuulama.

Tehnilised üksikasjad ettekannetest

Kuulasime ettekandeid mõlemal päeval. Mõnikord oli raske valida ühte ettekannet paralleelselt toimuvate seast – leppisime kokku, et jaguneme ja vahetame saadud teadmisi pauside ajal. Ja isegi sedasi tundub, et palju on jäänud tähelepanuta. Siin soovime rääkida mõnede ettekannete sisust, mis tundusid meile kõige huvitavamad

Erandid C++-s kompilatsiooni optimeerimise kaudu, Roman Rusjaev

Slaidist esitlusest.

Nagu pealkirjast selgelt nähtub, käsitles Roman eranditega töötamist LLVM näitel. Selle samas kohtumises võib ettekanne siiski anda teavet ka neile, kes ei kasuta oma töös Clang'i, kuidas koodi potentsiaalselt optimeerida. See on nii, et kompilaatorite ja vastavate standardteekide arendajad suhtlevad omavahel ja paljud head lahendused võivad kattuda.

Nii et erandi töötlemiseks on vajalik teostada palju toiminguid: kutsuda esile töötluskood (kui see on olemas) või vabastada ressursid praegusel tasemel ja tõsta teed kõrgemale. Kõik see viib selleni, et kompilaator lisab potentsiaalselt erandeid tekitavate kõnede jaoks täiendavaid juhiseid. Seega, kui erand tegelikult ei juhtu, hakkab programm ikkagi sooritama tarbetuid toiminguid. Nende kulude vähendamiseks on LLVM-is mitu heuristikat, mis määravad olukordi, kus erandi töötlemise koodi lisamine ei ole vajalik või saab vähendada

Ettekandja käsitleb umbes kümmet neist ja näitab, kuidas olukorrad, kus need aitavad kiirendada programmi täitmist, samuti neid, kus neid meetodeid ei saa rakendada.

Nii et Roman Rusjaev juhib kuulajad järeldusele, et kood, mis sisaldab eranditega töötamist, ei ole alati võimalik täita nullkuludega, ning annab järgmised nõuanded:

• Raamatukogude arendamisel tuleks põhimõtteliselt loobuda eranditest;
• kui erandeid siiski on vaja, tuleks võimalusel igale poole lisada modifikaatoreid noexcept (ja const), et kompilaator saaks maksimaalselt optimeerida.

Kokkuvõttes kinnitas esineja arvamust, et erandeid on kõige parem kasutada minimaalselt või nendest täielikult loobuda.

Küpsised esitlusmaterjalid on saadaval lingil: [„C++ erandid läbi LLVM kompilaatori optimeerimise prisma“]

Generaatorid, korutiinid ja muud ajude sammutamise magusused, Adi Shavit

Slaidist esitlusest.

Üks paljusid konverentsi ettekandeid, mis käsitlevad C++20 uuendusi, jäi meelde mitte ainult värvikalt kujundatud esituse, vaid ka selge probleemide määratlemise poolest, mis on seotud kogumite töötlemise loogikaga (for-tsükkel, callback'id).

Adi Shavit toob välja järgmised: praegused meetodid läbivad kogu kogumi ja ei anna samas ligipääsu mõnele sisemisele ajutisele olekule (või annavad selle callback'ide puhul, kuid suure arvu ebameeldivate kõrvaltoimetega, nagu Callback Hell). Tundub, et iteratoore on olemas, kuid ka nendega ei ole kõik sujuv: puuduvad ühenduspunktid sisse- ja väljapääsu jaoks (begin → end vastupidiselt rbegin → rend jne), ebaselge on, kui kaua me üldse iteratsiooniga tegeleme? Alates C++20 lahendatakse need probleemid!

Esimene variant: ranges. Iteraatorite peale mähkimise abil saame ühise liidese iteratsiooni alguseks ja lõpuks ning ka koostamise võimaluse. Kõik see võimaldab hõlpsasti ehitada täielikke andmete töötlemise konveiere. Kuid mitte kõik ei ole nii sujuv: osa arvutuste loogikast asub konkreetse iteratsiooni rakenduses, mis võib muuta koodi arusaadavamaks ja silumiseks keerukamaks.

Slaidist esitlusest.

Mis puutub sellesse, siis on C++20-sse lisatud korutiinid (funktsioonid, mille käitumine sarnaneb generaatoritega Pythonis): täitmine saab edasi lükata, tagastades mõne praeguse väärtuse, säilitades samal ajal ajutise oleku. Seega saavutame mitte ainult andmete töötlemise nende ilmumise ajal, vaid ka kapseldame kogu loogika konkreetse korutiini sisse.

Kuid on ka üks negatiivne aspekt: praegu toetavad neid vaid osaliselt olemasolevad kompilaatorid ja implementeerimine ei ole nii hoolikas, nagu sooviks. Näiteks ei tohiks korutiinide puhul kasutada viiteid ja ajutisi objekte. Lisaks on teatud piirangud selle osas, mis võib olla korutiinideks, ja constexpr-funktsioonid, konstruktorid/destuktorid ning main ei kuulu selle nimekirja.

Seega lahendavad korutiinid märkimisväärse osa andmete töötlemise loogika lihtsuse probleemidest, kuid nende praegune rakendus vajab täiendavat arendust.

Materjalid:

• C++ Russia slaidid — [„Generators, coroutines and other brain-unrolling sweetness“]
• Videomaterjal 2019. aasta CppCon konverentsilt

C++ nipp Yandex.Taksist, Anton Poluhin

Oma ametialases tegevuses tuleb vahel luua puhtalt abistavaid asju: vahekiht sisemise liidese ja mingi raamatukogu API vahel, logimine või parsimine. Sel juhul ei ole tavaliselt vajalik mingisugune täiendav optimeerimine. Aga mis siis, kui neid komponente kasutatakse ühes populaarseimas teenuses Venemaal? Sellisel juhul tuleb hallata tera- ja terabaiti üksnes logide jaoks! Iga millisekund on tähtis ja seepärast tuleb kasutada erinevaid nippe — just neist rääkis Anton Poluhin.

Võib-olla oli kõige huvitavamaks näiteks rakendamine mustri 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_; 
};

Antud näite puhul sooviks kõigepealt vabaneda väliste raamatukogude pealkirjadest — nii compileerimine läheb kiiremini ja saab end kaitsta võimalike nimestruktuuri konfliktide ja muu sarnase eest. 

Hästi, tõstsime #include .cpp-faili: vajalik on forward-declaration ümberpööratud API-le, samuti std::unique_ptr. Nüüd on meil dünaamilised allot; ja teised ebameeldivad asjad, nagu andmete laialijagamine kuhja ja garanteeritud vähendamine. Kõigele sellele aitab kaasa 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_; 
};

Ainus probleem: peame iga vahepaketi jaoks määrama suuruse ja joondamise — muudame meie pimpl šablooniks parameetritega , kasutame mingite suvaliste väärtustega ja lisame destruktoris kontrolli, et oleksime kõik õigesti määranud: 

~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"
    ); 
}

Kuna T destruktorit töödeldakse, on T juba määratletud, seetõttu ilmnevad selle koodi käitamisel kompilatsiooni ajal õiged suuruse ja joondamise väärtused. Nii saame ühe täiendava kompileerimisseansi hinnaga loobuda dünaamilisest mälu eraldamisest, peidame API .cpp-faili, kus implementatsioon asub, ja saavutame CPU poolt paremini vahetatava struktuuri.

Logimise ja parsimise tõhusus ei paistnud silma, mistõttu neid ei käsitleta selles ülevaates.

Küpsised esitlusmaterjalid on saadaval lingil: [„C++ nipid Taksi“]

Modernsed tehnikad, et hoida teie kood kuivana, Björn Fahller

Selles ettekandes tutvustab Björn Fahller mitmeid erinevaid viise, kuidas võidelda selliste stiililiste puudustega nagu korduvad tingimuste kontrollid:

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

Kas see on tuttav? Kasutades mõningaid võimsaid C++ tehnikaid, mis on ilmunud hiljutistes standardites, saab sama funktsionaalsuse elegantsemalt teostada ilma jõudluse kaotamiseta. Võrrelge:   

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

Kuna töödelda tuleb muutumatut hulka kontrolle, tuleb kasutada variadic templates ja fold expressions. Eeldame, et soovime kontrollida mitme muutuja võrdsust enum’i state_type elemendiga. Esimene asi, mis pähe tuleb – kirjutada abifunktsioon is_any_of:

enum state_type { IDLE, CONNECTED, DISCONNECTED };

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

Selline vahepealne tulemus on pettumustvalmistav. Praegu ei muutu kood loetavamaks:

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

Natuke olukorda parandavad non-type template parameetrid. Nende abil viime enum’i elemendid malliparameetrite nimekirja: 

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

Kasutades auto’t mitte-tüübi malliparametris (C++17), laieneb lähenemine mitte ainult state_type elementide, vaid ka primitiivsete tüüpide võrdlemisele, mida saab kasutada mitte-tüübi malliparametritena:

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

Järjestikeste täiustamise kaudu saavutatakse soovitud sujuv süntaks kontrollide jaoks:

template 
struct any_of : private std::tuple { 
// laisaksite ja pärime ehitajad tuple'ilt
        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);

Selles näites teenib deduktsioonigraafik soovitud malliparameetrite struktuuri näitamiseks kompilaatorile, kes teab konstruktoriga argumentide tüüpe. 

Edasi – huvitavam. Björn õpetab üldistama saadud koodi võrdlusoperaatorite jaoks lisaks ==, ja seejärel ka kõikvõimalike operatsioonide jaoks. Samal ajal tutvustatakse näiteks no_unique_address atribuuti (C++20) ja malliparameetreid lambdafunktsioonides (C++20). (Jah, nüüd on lambda-süntaks veelgi lihtsam meelde jätta – need on neli järjestikust paari sulu igasuguses vormis.) Lõplik lahendus funktsioonide kasutamisega nagu konstruktorite detailid soojendab tõeliselt mu hinge, rääkimata tüpist tuple parimates lambda-arvutuse traditsioonides.

Lõpus ärge unustage viimistleda:

• Tuletame meelde, et lambdad on constexpr tasuta; 
• Lisame perfektse edasikandmise ja vaatame selle inetu süntaks esinduspaketi korral lambdasulgudes;
• Anname kompilaatorile rohkem võimalusi optimeerimiseks tingimusliku noexcept'i abil; 
• Hoolitseme arusaadavamate vea teatiste eest mallide puhul tänu lambda-de selgetele tagastatavatele väärtustele. See paneb kompilaatori tegema rohkem kontrollimisi enne mallifunktsiooni tegelikku kutsumist – tüüpide kontrollimise etapis. 

Küsimuste korral pöörduge loengumaterjalide poole: 

• Ettekande slaidid: [Modern Techniques for Keeping Your Code DRY]
• Allikakood github'is
• Autori artikkel blogis

Meie muljed

Meie esimene osalemine C++ Russia jääb meelde oma rikkalikkuse poolest. C++ Russia avaldas muljet alsuse üritusena, kus õppe ja elava suhtlemise vaheline piir on peaaegu märkamatu. Kõik, alates esinejate meelestatusest kuni ürituse partnerite võistlusteni, kutsub esile elavaid arutelusid. Konverentsi sisuline osa, mis koosneb ettekannetest, hõlmab üsna laia teemapinda, sealhulgas C++ uuendusi, näiteid suurtest projektidest ja ideoloogilisi arhitektuurilisi arutlusi. Kuid oleks ebaaus tähelepanu pööramata ka ürituse sotsiaalsele küljele, mis aitab ületada keelebarjääre, mitte ainult C++ osas.

Täname konverentsi korraldajaid sellisel üritusel osalemise võimaluse eest!
Korraldajate postitust möödunud, oleviku ja tuleviku C++ Russia kohta olete võinud näha JUG Ru blogis.

Aitäh lugemise eest ja loodame, et meie sündmuste kokkuvõte oli kasulik!

Allikas: habr.com