C++ Venemaa: kuidas see oli

Kui näidate näidendi alguses, et seinal on kood C++ jaoks, siis peab see kindlasti lõpus teile jalga laskma.

Bjarne Stroustrup

31. oktoobrist kuni 1. novembrini toimus Peterburis C++ Russia Piter konverents – üks suurimaid programmeerimiskonverentse Venemaal, mille korraldas JUG Ru Group. Külalislektorite seas on C++ standardimise komitee liikmed, CppCon'i ettekandjad, O'Reilly väljaande autorid ja ka selliste projektide hooldajad nagu LLVM, libc++ ja Boost. Konverents on suunatud kogenud C++ arendajatele, kes soovivad süvendada oma ekspertiisi ja vahetada kogemusi elavas suhtluses. Üliõpilastele, doktorantidele ja ülikoolide õppejõududele on pakutavad väga head allahindlused.

Moskva konverentsi väljaannet saab külastada juba järgmise aasta aprillis, kuid meie üliõpilased räägivad, millest huvitavast nad eelmisel üritusel teada said. 

Fotod konverentsi albumist

Meist

Selle postituse eest vastutasid kaks HSE üliõpilast – Peterburist:

• Lisa Vasilenko on 4. kursuse bakalaureuseüliõpilane, kes õpib programmeerimiskeelte suunda „Rakendusmatemaatika ja informaatika“ programmis. Tutvudes C++ keelega ülikooli esimesel kursusel, omandas ta hiljem selle kasutamise kogemuse praktikal töötades. Kirg programmeerimiskeelte, eriti funktsionaalse programmeerimise vastu on mõjutanud ka tema valikuid konverentsidel esitlemiseks.
• Danya Smirnov on 1. aasta magistrant programmeerimise ja andmeanalüüsi erialal. Juba koolis lahendas ta C++ keeles olümpiaadiülesandeid, ja edaspidi seisis see keel pidevalt tema õpingutes, kuni sellest sai tema peamine tööriist. Ta otsustas konverentsist osa võtta, et oma teadmisi täiendada ja tutvuda uute võimalustega.

Fakulteedi uudiskirjas jagatakse tihti teavet haridusürituste kohta, mis on seotud meie erialaga. Septembris nägime C++ Russia kohta teavet ja otsustasime registreeruda kuulajateks. See on meie esimene kogemus sarnastes konverentsides osalemiseks.

Konverentsi struktuur

• Ettekanded

Kahe päeva jooksul lugesid eksperdid ette 30 ettekannet, kajastades palju põletavaid teemasid: keele funktsioonide nutikad rakendused praktiliste ülesannete lahendamiseks, tulevased keeuudised seoses uue standardiga, C++ disaini kompromissid ja ettevaatusabinõud nende tagajärgedega tegelemiseks, huvitava projekt arhitektuuri näited ning mõned keele infrastruktuuri sisemised detailid. Samal ajal toimusid 3 ettekannet, enamasti kaks vene keeles ja üks inglise keeles.

• Arutelualad

Esitluse järel kanti kõik vastamata küsimused ja lõpetamata arutelud spetsiaalsetesse suhtlusaladele esinejatega, mis olid varustatud markeritahvlitega. Hea viis veeta paus ettekannete vahel meeldivas vestluses.

• Välgatusettekanded ja mitteformaalsed arutelud

Kui soovid teha lühikese ettekande, saad registreeruda markerite tahvlil õhtusele Lightning Talk'ile ja saad viie minuti jooksul rääkida kõigest, mis seondub konverentsi teemaga. Näiteks kiire sissejuhatus C++ sanitizers’itesse (mille kohta oli paljudele uut) või lugu sinusoidi genereerimise veast, mille saab vaid kuulda, aga mitte näha.

Teine formaat on paneeldiskussioon „Komiteega hingede üle“. Lavale tulevad mõned standardimise komitee liikmed, projektoril on kamin (ametlikult - hingelise õhkkonna loomiseks, kuid põhjus „sest KÕIK ON TULES“ tundub huvitavam), küsimused on standardi ja C++ üldise visiooni kohta, ilma ägedate tehniliste arutelute ja konfliktideta. Selgus, et komitees on ka elavaid inimesi, kes ei pruugi mõnedes asjades olla täielikult kindlad või midagi mitte teada.

Arutelu fännide seas kestis kolmas üritus – BOF-seminar "Go versus C++". Võtame Go armastaja ja C++ armastaja, enne sessiooni algust valmistavad nad koos 100500 slaidi teema üle (nt C++ paketeerimise probleemid või Go generikate puudumine), seejärel arutavad nad elavalt üksteisega ja publikuga, samal ajal kui publik püüab mõista kahte seisukohta. Kui arutelu muutub ebaoluliseks, sekkub moderaator ja lepitab pooled. See formaat venib: mitu tundi pärast algust oli läbida vaid pool slaididest. Lõppu tuli tõsiselt kiirendada.

• Partnerite stendid

Käiguteedes olid esindatud konverentsi partnerid – stendidel räägiti käimasolevatest projektidest, pakuti praktikakohti ja tööleasumise võimalusi, korraldati viktoriine ja väikeseid võistlusi ning loosi anti meeldivaid auhindu. Samuti pakkusid mõned ettevõtted võimalust läbida esimesed vestlusetapid, mis võib olla kasulik neile, kes tulid mitte ainult ettekandeid kuulama.

Ettekannete tehnilised üksikasjad

Kuulasime ettekandeid kogu päeva. Mõnikord oli raske valida ühte ettekannet samal ajal toimuvate seast – leppisime kokku, et jagame vahel oma teadmisi. Ja isegi nii tundub, et palju jäi puudu. Siin tahaksime rääkida mõnest ettekandest, mis tundusid meile kõige huvitavamad.

C++ erandid kompilaatori optimeerimise vaatenurgast, Roman Rusajev

Slide esitluses

Nagu pealkirjast selgelt näha, käsitles Roman exceptionide töötlemist LLVM näitel. Samas võib see ettekande anda mõningast arusaamist ka neile, kes ei kasuta oma töös Clang'i, kuidas kood võiks potentsiaalselt olla optimeeritud. See on nii, sest kompilaatiorite ja vastavate standardraamatukogude arendajad suhtlevad omavahel ja paljusid häid lahendusi võivad kasutada erinevad meeskonnad.

Seega, erandi käsitlemiseks on vaja teha mitmeid toiminguid: kutsuda välja töötlemiskood (kui see on olemas) või vabastada ressursid käimasolevas tasemes ja kerida stekki ülespoole. Kõik see viib selleni, et potentsiaalselt erandeid tekitavate kõnede jaoks lisab kompilaator täiendavaid instruktsioone. Seega, kui erand ei toimu, hakkab programm ikkagi täitma tarbetuid toiminguid. Ühenduse kulude vähendamiseks on LLVM-is mitmeid heuristilisi meetodeid, et määrata olukordi, kus erandite töötlemise koodi ei ole vaja lisada või mille puhul võib vähendada „ülemääraste“ instruktsioonide arvu.

Ettekandja uurib umbes kümmet neist ning näitab, kuidas situatsioonid, kus need aitavad programmi täitmist kiirendada, ning neid, kus need meetodid ei ole rakendatavad.

Seega toob Roman Russaiev kuulajate ette järelduse, et kood, mis sisaldab töötlemist eranditega, ei pruugi alati olla teostatav nullkulusid kandva operatsioonina ning annab järgmised näpunäited:

• teeksite raamatukogude arendamisel põhimõtteliselt loobuda eranditest;
• kui erandid on siiski vajalikud, siis tuleks võimaluse korral igal pool lisada modifikaatoreid noexcept (ja const), et kompilator saaks võimalikult palju optimeerida.

Kokkuvõttes kinnitas ettekandja arvamust, et erandeid tuleks kasutada võimalikult vähe või neist üldse loobuda.

Ettekande slaidid on saadaval lingil: [«C++ erandid LLVM kompilaatori optimeerimise prismast»]

Generators, coroutines ja muud aju avardavad meeldimised, Adi Shavit

Slide esitluses

Üks paljusid konverentsi ettekandeid, mis käsitlevad C++20 uuendusi, jääb meelde mitte ainult värvikalt kujundatud esituse, vaid ka selge probleemide määratlemise tõttu kogu kollektsioonide töötlemise loogikas (for tsükkel, tagasiside-d).

Adi Shavit toob välja järgmised: praegu kasutatavad meetodid läbivad kogu kogumi ning ei pruugi anda juurdepääsu teatud sisemisele vaheolekule (või annavad seda callback-ide kaudu, kuid koos paljude ebameeldivate kõrvalmõjudega, nagu Callback Hell). Tundub, et iteratoore on olemas, kuid ka nendega ei ole kõik nii sujuv: pole üldisi sisse- ja väljapääsukohasid (begin → end versus rbegin → rend jne), ebaselge on, kui palju me üldse iteratsiooni peame? Alates C++20 lahendatakse need probleemid!

Esimene variant: ranges. Iteraatorite kohal oleva ümbriku abil saame üldise liidese iteratsiooni alguse ja lõpu jaoks, samuti võimaluse kompositsiooniks. Kõik see võimaldab kergesti ehitada täislahendusega andmetöötluse torujuhtmeid. Kuid mitte kõik ei ole nii sujuv: osa arvutuste loogikast võib paikneda konkreetse iteratori rakenduses, mis võib muuta koodi mõistmise ja silumise keerulisemaks.

Slide esitluses

Noh, selleks on C++20-sse lisatud korutiinid (funktsioonid, mille käitumine sarnaneb Pythonis kasutatavatele generaatoritele): täitmine saab olla edasi lükatud, tagastades mõningase praeguse väärtuse ja säilitades samal ajal vaheoleku. Nii saavutame mitte ainult andmetega töötamise nende saabumisel, vaid ka kogu loogika kapseldamise konkreetse korutiini sisse.

Kuid on ka negatiivne külg: praegu toetavad neid vaid osaliselt olemasolevad kompilaatorid ja need on teostatud mitte nii hoolikalt, nagu sooviks: näiteks ei tasu korutiinides kasutada viiteid ja ajutisi objekte. Pluss, on mõned piirangud, mis võivad olla korutiinid, ja constexpr-funktsioonid, konstruktorid/destruktorid ning ka main ei kuulu sellesse nimekirja.

Seega lahendavad korutiinid märkimisväärse osa andmete töötlemise loogika lihtsustamise probleemidest, kuid nende praegused teostused vajavad täiendavat tööd.

Materjalid:

• C++ Russia slaidid — [«Generators, coroutines and other brain-unrolling sweetness»]
• Dokumendi video salvestus CppCon 2019-st

C++ trikid Yandex.Taxis, Anton Poluhhin

Oma professionaalses tegevuses peab vahel tegelema puhtalt abifunktsioonidega: rakendama mingi teegi sisemise liidese ja API vahel, logimist või parsimist. Sel juhul ei ole tavaliselt vajalik mingisugune täiendav optimeerimine. Aga mis siis, kui neid komponente kasutatakse mõnedes populaarseimates teenustes Ruunetis? Sellises olukorras tuleb töödelda terabaitide kaupa logisid tunnis! Siis on iga millisekund oluline ja seetõttu tuleb kasutada erinevaid nippe — just neist rääkis Anton Poluhin.

Võib-olla oli kõige huvitavam näide pointer-to-implementation (pimpl) mustri rakendamine. 

#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_; 
};

Selles näites tahaks esialgu vabaneda väliste raamatukogude pealkirjafailidest — see kiirendab kompileerimist ja samuti kaitseb võimalike nimede konfliktide ja teiste sarnaste vigade eest. 

Hästi, viisime #include cpp-faili: vajalik on edasine dekleerimine ümbritsetud API-st ning std::unique_ptr. Nüüd on meil dünaamilised allokatsioonid ja muud ebameeldivad asjad, nagu laiali hajutatud andmed põhjas ja vähenenud garantii. Kõik selle jaoks võib aidata 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: iga ümbriku jaoks tuleb määrata suurus ja joondamine — teeme meie pimpl mallina parameetritega , kasutame mõningate suvaliste väärtuste jaoks ja lisame destruktorisse kontrolli, et kõik oleks õigesti ära arvatud: 

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

template 
static void validate() noexcept { 
    static_assert(
        Size == ActualSize, 
        "Suurus ja sizeof(T) ei ühti"
    ); 
    static_assert(
        Alignment == ActualAlignment, 
        "Joondamine ja alignof(T) ei ühti"
    ); 
}

Kuna T on destruktori töötlemisel juba määratletud, töötab see kood õigesti ja kompilatsioonietapis kuvab vajalikud suuruse ja joondamise väärtused, mis tuleb kirjutada. Nii saame ühe täiendava kompileerimise hinnaga vabaneda juurdehindlusest pakendatud klasside dünaamilise eraldamise eest, peidame API .cpp-faili rakendusse ning saame protsessorile paremini vahemälu sobiva struktuuri.

Logimine ja analüüs tundusid vähem muljetavaldavad, seega ei mainita neid selles ülevaates.

Ettekande slaidid on saadaval lingil: [«C++ trikid Taksi»]

Kaasaegsed tehnikad oma koodi kuivana hoidmiseks, Björn Fahller

Selles ettekandes näitab Björn Fahller mitmeid erinevaid viise, kuidas võidelda selliste stilistiliste puudustega nagu korduvate tingimuste kontrollimine:

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

Kas see on tuttav? Kasutades mitmeid võimsaid C++ tehnikaid, mis on ilmunud hiljutistes standardites, saab sama funktsionaalsuse elegantsetel viisidel rakendada ilma igasuguste jõudluskadudeta. Võrdle:   

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

Ebakindla arvu kontrollide haldamiseks tahaksime kasutada variadic templates ja fold expressions. Oletame, et soovime võrrelda 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 <typename ... Ts>
bool is_any_of(state_type s, const Ts& ... ts) { 
    return ((s == ts) || ...); 
}

Selline vahepealne tulemus on pettumust valmistav. Kood ei muutu senimaani loetavamaks:

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

Non-type mallikparameetrite abil on võimalik veidi olukorda parandada. Nende abil edastame enum'ist loetletud elemendid malliparameetrite nimekirja: 

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

assert(is_any_of(state)); 

C++17 versioonis auto kasutamisega mitte-tüüpilise malliparameetri (non-type template parameter) kasutamine laiendab lähenemist nii, et saame võrrelda mitte ainult state_type elemente, vaid ka primitiivsete tüüpidega, mida saab kasutada mitte-tüüpiliste malliparameetrite jaoks:

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

Nende järjestikuste paranduste kaudu saavutatakse soovitud sujuv süntaks kontrollide jaoks:

template 
struct any_of : private std::tuple { 
// oleme laisad ja pärime tuple'ist konstruktorid 
        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 on deduktioonijuhend mõeldud kompilaatori jaoks soovitud malliparameetrite struktuuri näitamiseks, teades konstruktorite argumentide tüüpe. 

Edasi – on huvitavam. Björn õpetab kokku võtma tekkinud koodi võrreldes teiste võrdlusoperaatoritega peale ==, ja seejärel ka erinevate operatsioonidega. Samuti tutvustatakse näite kaudu selliseid omadusi nagu no_unique_address atribuut (C++20) ja malliparameetrid lambda-funktsioonides (C++20). (Jah, nüüd on lambda süntaks veel lihtsam meelde jätta – see on neli järjestikust sulgude paari kõikidest sortidest.) Lõpplahendus, mis kasutab funktsioone kui ehitusdetailideks, rõõmustab mind tõeliselt, rääkimata tupelise väljendi kasutamisest lambda-arvutuse parimate traditsioonide järgi.

Lõpus ei unusta me ilustamisega tegeleda:

• Kordame, et lambdad on - constexpr tasuta; 
• Lisame perfect forwarding’i ja vaatame selle koledat süntaksit seoses parameter pack’iga lambda sulgudes;
• Anname kompilaatorile rohkem võimalusi optimeerimiseks conditional noexcept’i abil; 
• Mugime selgeid tagastavaid väärtusi lambdade abil, et parandada vigade arusaadavust mallides. See sunnib kompilaatorit tegema rohkem kontrollimisi enne mallifunktsiooni väljakutset - tüübi kontrollimise etapis. 

Lisainformatsiooni saamiseks pöörduge loengumaterjalide poole: 

• Ettekande slaidid: [Modern Techniques for Keeping Your Code DRY]
• Allika kood GitHubis
• Autorite artikkel blogis

Meie muljed

Meie esimene osalemine C++ Russia jääb meelde oma sisukuse poolest. C++ Russia jätab mulje südamlikust üritusest, kus õppe ja elava suhtluse piir on peaaegu tajumatu. Kõik, alates ettekandjate meeleolust kuni ürituse partnerite korraldatud konkurssideni, kutsub esile elavaid arutelusid. Konverentsi sisu, mis koosneb ettekannetest, katab üsna laia teemaspektrit, sealhulgas C++ uuendusi, praktilisi näiteid suurematest projektidest ja ideoloogilisi arhitektuurilisi kaalutlusi. Kuid oleks ebaõiglane unustada ürituse sotsiaalset aspekti, mis aitab ületada keelebarjääre mitte ainult C++ osas.

Täname konverentsi korraldajaid sellise sündmuse korraldamise võimaluse eest!
Korraldajate postitus mineviku, oleviku ja tuleviku kohta C++ Russia oli nähtav JUG Ru blogis.

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

Allikas: habr.com