Ef þú segir í upphafi leiksins að það sé C++ kóði hangandi á veggnum, þá hlýtur hann að skjóta þig í fótinn í lokin.
Bjarne Stroustrup
Dagana 31. október til 1. nóvember var C++ Russia Piter ráðstefnan haldin í Sankti Pétursborg - ein af umfangsmiklum dagskrárráðstefnum í Rússlandi, á vegum JUG Ru Group. Meðal gestafyrirlesara eru meðlimir C++ staðlanefndar, CppCon fyrirlesarar, O'Reilly bókahöfundar og umsjónarmenn verkefna eins og LLVM, libc++ og Boost. Ráðstefnan er ætluð reyndum C++ forriturum sem vilja dýpka sérþekkingu sína og skiptast á reynslu í lifandi samskiptum. Nemendum, útskriftarnemum og háskólakennurum er veittur mjög góður afsláttur.
Hægt verður að heimsækja Moskvuútgáfu ráðstefnunnar strax í apríl á næsta ári, en á meðan munu nemendur okkar segja þér hvaða áhugaverða hluti þeir lærðu á síðasta viðburði.
Mynd frá
um okkur
Tveir nemendur frá National Research University Higher School of Economics - St. Petersburg unnu að þessari færslu:
- Liza Vasilenko er 4. árs grunnnemi sem stundar nám í forritunarmálum sem hluti af hagnýtri stærðfræði og tölvunarfræði. Eftir að hafa kynnst C++ tungumálinu á fyrsta ári í háskóla öðlaðist ég í kjölfarið reynslu af því að vinna með það í gegnum starfsnám í greininni. Ástríða mín fyrir forritunarmálum almennt og hagnýtri forritun sérstaklega setti mark sitt á val á skýrslum á ráðstefnunni.
- Danya Smirnov er 1. árs nemandi í meistaranáminu „Forritun og gagnagreining“. Á meðan ég var enn í skólanum skrifaði ég ólympíudæmi í C++ og þá gerðist það einhvern veginn að tungumálið kom stöðugt upp í fræðslustarfi og varð að lokum aðal vinnumálið. Ég ákvað að taka þátt í ráðstefnunni til að bæta þekkingu mína og einnig læra um ný tækifæri.
Í fréttabréfinu miðlar forysta deildarinnar oft upplýsingum um fræðsluviðburði sem tengjast sérgrein okkar. Í september sáum við upplýsingar um C++ Rússland og ákváðum að skrá okkur sem hlustendur. Þetta er fyrsta reynsla okkar af þátttöku í slíkum ráðstefnum.
Ráðstefnuskipulag
-
Skýrslur
Á tveimur dögum lásu sérfræðingar 30 skýrslur, þar sem fjallað var um mörg heitt efni: sniðug notkun tungumálaeiginleika til að leysa beitt vandamál, væntanlegar tungumálauppfærslur í tengslum við nýja staðalinn, málamiðlanir í C++ hönnun og varúðarráðstafanir þegar unnið er með afleiðingar þeirra, dæmi af áhugaverðum arkitektúr verkefnisins, auk nokkurra smáatriða um tungumálainnviðina. Þrjár sýningar fóru fram samtímis, oftast tvær á rússnesku og ein á ensku.
-
Umræðusvæði
Eftir ræðuna voru allar óspurðar spurningar og óloknar umræður fluttar á þar til gerð svæði til samskipta við fyrirlesarana, búin merkjatöflum. Góð leið til að gera hlé á milli ræðna með skemmtilegu spjalli.
-
Lightning Tals og óformlegar umræður
Ef þú vilt gefa stutta skýrslu geturðu skráð þig á töfluna fyrir Lightning Talk kvöldsins og fengið fimm mínútna tíma til að tala um hvað sem er um ráðstefnuefnið. Til dæmis, stutt kynning á hreinsiefnum fyrir C++ (fyrir suma var það nýtt) eða saga um galla í sinusbylgjumyndun sem aðeins heyrist en sést ekki.
Annað snið er pallborðsumræður "Með hjarta til hjarta nefndarinnar." Á sviðinu eru nokkrir meðlimir staðlanefndar, á skjávarpanum er arinn (opinberlega - til að skapa einlægt andrúmsloft, en ástæðan “því ALLT ER Í BELD” virðist fyndnari), spurningar um staðalinn og almenna sýn á C++ , án heiftarlegra tækniumræðna og holiwars. Í ljós kom að í nefndinni er líka lifandi fólk sem er kannski ekki alveg viss um eitthvað eða veit ekki eitthvað.
Fyrir aðdáendur holivars var þriðji viðburðurinn áfram í gangi - BOF fundurinn „Go vs. C++“. Við tökum Go elskhuga, C++ elskhuga, áður en lotan hefst undirbúa þeir saman 100500 glærur um efni (eins og vandamál með pakka í C++ eða skort á almennum lyfjum í Go), og síðan eiga þeir líflegar umræður sín á milli og með áhorfendum og áhorfendur reyna að skilja tvö sjónarmið í einu. Ef holivar byrjar úr samhengi grípur stjórnandi inn í og gerir aðila í sátt. Þetta snið er ávanabindandi: nokkrum klukkustundum eftir ræsingu var aðeins helmingur glæranna lokið. Það þurfti að flýta mjög fyrir endalokunum.
-
Partner stendur
Samstarfsaðilar ráðstefnunnar áttu fulltrúa í salnum - á áhorfendapöllunum ræddu þeir um núverandi verkefni, buðu upp á starfsnám og atvinnu, efndu til spurningakeppni og smákeppni og drógu einnig út veglega vinninga. Jafnframt buðust sum fyrirtæki jafnvel til að fara í gegnum upphafsstig viðtala, sem gæti nýst þeim sem komu ekki bara til að hlusta á skýrslur.
Tæknilegar upplýsingar um skýrslurnar
Við hlustuðum á skýrslur báða dagana. Stundum var erfitt að velja eina skýrslu af þeim samhliða - við komumst að samkomulagi um að skipta okkur upp og skiptast á þekkingu sem aflað var í hléum. Og þrátt fyrir það virðist sem margt sé útundan. Hér langar okkur að tala um innihald sumra þeirra skýrslna sem okkur þótti áhugaverðastar
Undantekningar í C++ í gegnum prisma þýðanda hagræðingar, Roman Rusyaev
Renndu frá
Eins og titillinn gefur til kynna leit Roman á að vinna með undantekningar með því að nota LLVM sem dæmi. Á sama tíma, fyrir þá sem ekki nota Clang í starfi sínu, getur skýrslan samt gefið nokkra hugmynd um hvernig kóðinn gæti mögulega verið fínstilltur. Þetta er svo vegna þess að þróunaraðilar þýðenda og samsvarandi staðlaðra bókasöfn hafa samskipti sín á milli og margar árangursríkar lausnir geta farið saman.
Svo, til að takast á við undantekningu, þarftu að gera ýmislegt: hringja í meðhöndlunarkóðann (ef einhver er) eða ókeypis auðlindir á núverandi stigi og snúa upp staflanum hærra. Allt þetta leiðir til þess að þýðandinn bætir við viðbótarleiðbeiningum fyrir símtöl sem hugsanlega valda undantekningum. Þess vegna, ef undantekningin er ekki raunveruleg, mun forritið samt framkvæma óþarfa aðgerðir. Í því skyni að draga einhvern veginn úr kostnaði hefur LLVM nokkra heuristic til að ákvarða aðstæður þar sem ekki þarf að bæta við undantekningarmeðhöndlunarkóða eða fækka „auka“ leiðbeiningum.
Ræðumaður skoðar um tugi þeirra og sýnir bæði aðstæður þar sem þær hjálpa til við að flýta fyrir framkvæmd forrita og þær þar sem þessar aðferðir eiga ekki við.
Þannig leiðir Roman Rusyaev nemendur að þeirri niðurstöðu að kóða sem inniheldur undantekningarmeðferð er ekki alltaf hægt að framkvæma með núll kostnaður og gefur eftirfarandi ráð:
- þegar verið er að þróa bókasöfn er í grundvallaratriðum þess virði að yfirgefa undantekningar;
- ef undantekningar er enn þörf, þá er það þess virði að bæta við noexcept (og const) breytum alls staðar þegar það er mögulegt, svo að þýðandinn geti hagrætt eins mikið og mögulegt er.
Ræðumaður staðfesti almennt þá skoðun að best væri að nota undantekningar í lágmarki eða horfið frá með öllu.
Skýrsluglærurnar eru aðgengilegar á eftirfarandi hlekk:
Rafalar, kórótínur og önnur sætleiki sem dregur úr heilanum, Adi Shavit
Renndu frá
Ein af mörgum skýrslum á þessari ráðstefnu sem helguð var nýjungum í C++20 var eftirminnileg, ekki aðeins fyrir litríka framsetningu, heldur einnig fyrir skýra auðkenningu á núverandi vandamálum með innheimtuvinnslurökfræði (fyrir lykkju, endurhringingar).
Adi Shavit leggur áherslu á eftirfarandi: aðferðirnar sem nú eru tiltækar fara í gegnum allt safnið og veita ekki aðgang að einhverju innra milliástandi (eða þær gera það þegar um svarhringingar er að ræða, en með miklum fjölda óþægilegra aukaverkana, eins og Callback Hell) . Það virðist sem það séu endurteknir, en jafnvel með þeim er allt ekki svo slétt: það eru engir sameiginlegir inngangs- og útgöngustaðir (byrjun → lok á móti rbegin → rend og svo framvegis), það er ekki ljóst hversu lengi við munum endurtaka? Frá og með C++20 eru þessi vandamál leyst!
Fyrsti valkostur: svið. Með því að vefja endurtekningar fáum við sameiginlegt viðmót fyrir upphaf og lok endurtekningar, auk þess sem við fáum hæfileika til að semja. Allt þetta gerir það auðvelt að byggja upp fullgildar gagnavinnsluleiðslur. En ekki er allt svo slétt: hluti af útreikningsrökfræðinni er staðsettur inni í útfærslu tiltekins endurtekningar, sem getur flækt kóðann til að skilja og kemba.
Renndu frá
Jæja, í þessu tilviki bætti C++20 við kóróútínum (aðgerðir sem hegðun er svipuð og rafala í Python): hægt er að fresta framkvæmd með því að skila einhverju núverandi gildi á meðan millistig er varðveitt. Þannig náum við ekki aðeins að vinna með gögn eins og þau birtast, heldur einnig að hylja alla rökfræði inni í tiltekinni coroutine.
En það er fluga í smyrslinu: í augnablikinu eru þau aðeins studd að hluta til af núverandi þýðendum og eru heldur ekki útfærð eins snyrtilega og við viljum: til dæmis er ekki þess virði að nota tilvísanir og tímabundna hluti í coroutines. Auk þess eru nokkrar takmarkanir á því hvað getur verið coroutines, og constexpr aðgerðir, smiðir/destructors og main eru ekki með á þessum lista.
Þannig leysa coroutines verulegan hluta vandamálanna með einfaldleika gagnavinnslurökfræðinnar, en núverandi útfærslur þeirra krefjast úrbóta.
Efni:
- Glærur frá C++ Rússlandi -
C++ brellur frá Yandex.Taxi, Anton Polukhin
Í atvinnustarfsemi minni þarf ég stundum að innleiða eingöngu aukahluti: umbúðir á milli innra viðmótsins og API einhvers bókasafns, skráningar eða þáttunar. Í þessu tilviki er yfirleitt engin þörf á frekari hagræðingu. En hvað ef þessir íhlutir eru notaðir í sumum af vinsælustu þjónustunum á RuNet? Í slíkum aðstæðum verður þú að vinna terabæt á klukkustund af annálum einum! Þá skiptir hver millisekúnda máli og því þarf að grípa til ýmissa bragða - Anton Polukhin talaði um þau.
Kannski áhugaverðasta dæmið var útfærslan á bendill-til-útfærslu (pimpl) mynstrinu.
#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_;
};Í þessu dæmi vil ég fyrst losna við hausskrár ytri bókasöfna - þetta mun safna saman hraðar og þú getur verndað þig fyrir hugsanlegum nafnaátökum og öðrum svipuðum villum.
Allt í lagi, við færðum #include í .cpp skrána: við þurfum framsendingaryfirlýsingu um vafða API, sem og std::unique_ptr. Nú erum við með kraftmikla úthlutun og aðra óþægilega hluti eins og gögn á víð og dreif um fullt af gögnum og minni ábyrgðir. std::aligned_storage getur hjálpað við þetta allt.
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_;
};Eina vandamálið: þú þarft að tilgreina stærð og röðun fyrir hverja umbúðir - við skulum búa til bólusniðmátið okkar með breytum , notaðu nokkur handahófskennd gildi og bættu ávísun við eyðileggjandinn að við höfum allt rétt:
~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"
);
}Þar sem T er þegar skilgreint þegar unnið er með eyðileggjandinn, verður þessi kóði þáttaður rétt og á samantektarstigi mun hann gefa út nauðsynleg stærð og jöfnunargildi sem þarf að slá inn sem villur. Þannig losum við okkur við kraftmikla úthlutun umbúða flokka á kostnaði við eina samantektarkeyrslu til viðbótar, felum API í .cpp skrá með útfærslunni og fáum líka hönnun sem hentar betur fyrir skyndiminni af örgjörvanum.
Skráning og þáttun virtist minna áhrifamikill og verður því ekki minnst á þessa umfjöllun.
Skýrsluglærurnar eru aðgengilegar á eftirfarandi hlekk:
Nútíma tækni til að halda kóðanum þínum DRY, Björn Fahller
Í þessu erindi sýnir Björn Fahller nokkrar mismunandi leiðir til að berjast gegn stílgalla endurtekinna ástandsskoðunar:
assert(a == IDLE || a == CONNECTED || a == DISCONNECTED);Hljómar kunnuglega? Með því að nota nokkrar öflugar C++ aðferðir sem kynntar hafa verið í nýlegum stöðlum, geturðu innleitt sömu virknina á glæsilegan hátt án nokkurrar frammistöðurefsingar. Bera saman:
assert(a == any_of(IDLE, CONNECTED, DISCONNECTED));Til að takast á við ófastan fjölda athugana þarftu strax að nota breytileg sniðmát og fellingartjáningar. Gerum ráð fyrir að við viljum athuga jafnræði nokkurra breyta við state_type frumefni enum. Það fyrsta sem mér dettur í hug er að skrifa hjálparaðgerð er_hvað sem er:
enum state_type { IDLE, CONNECTED, DISCONNECTED };
template <typename ... Ts>
bool is_any_of(state_type s, const Ts& ... ts) {
return ((s == ts) || ...);
}
Þessi milliniðurstaða veldur vonbrigðum. Enn sem komið er er kóðinn ekki að verða læsilegri:
assert(is_any_of(state, IDLE, DISCONNECTING, DISCONNECTED)); Ógerð sniðmátsbreytur munu hjálpa til við að bæta ástandið aðeins. Með hjálp þeirra munum við flytja ótal þætti enum á listann yfir sniðmátsfæribreytur:
template <state_type ... states>
bool is_any_of(state_type t) {
return ((t == states) | ...);
}
assert(is_any_of<IDLE, DISCONNECTING, DISCONNECTED>(state)); Með því að nota sjálfvirkt í sniðmátsfæribreytu sem ekki er gerð (C++17), er nálgunin einfaldlega alhæf yfir samanburði, ekki aðeins við state_type þætti, heldur einnig við frumstæðar gerðir sem hægt er að nota sem sniðmátsbreytur sem ekki eru gerðar:
template <auto ... alternatives, typename T>
bool is_any_of(const T& t) {
return ((t == alternatives) | ...);
}Með þessum endurbótum næst æskilegri reiprennandi setningafræði fyrir athuganir:
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);
Í þessu dæmi þjónar frádráttarleiðarvísirinn til að stinga upp á æskilegum sniðmátsbreytum fyrir þýðandann, sem þekkir tegundir smíðaröksemda.
Frekari - meira áhugavert. Björn kennir hvernig á að alhæfa kóðann sem myndast fyrir samanburðaraðgerðir umfram ==, og síðan fyrir handahófskenndar aðgerðir. Í leiðinni eru eiginleikar eins og engin_eigin_address eiginleiki (C++20) og sniðmátsfæribreytur í lambda aðgerðum (C++20) útskýrðar með notkunardæmum. (Já, nú er enn auðveldara að muna lambda setningafræðina - þetta eru fjögur samfelld pör af svigum af öllum gerðum.) Lokalausnin með því að nota föll sem smíði smáatriði yljar mér virkilega, svo ekki sé minnst á tjáninguna tuple í bestu hefðum lambda reikningur.
Í lokin, ekki gleyma að pússa það upp:
- Mundu að lambdas eru constexpr ókeypis;
- Bætum við fullkominni áframsendingu og skoðum ljóta setningafræði þess í tengslum við breytupakkann í lambda lokuninni;
- Við skulum gefa þýðandanum fleiri tækifæri til hagræðingar með skilyrtum noexcept;
- Við skulum sjá um skiljanlegri villuúttak í sniðmátum þökk sé skýrum skilagildum lambda. Þetta mun neyða þýðandann til að gera fleiri athuganir áður en sniðmátsaðgerðin er raunverulega kölluð - á tegundaskoðunarstigi.
Fyrir frekari upplýsingar, vinsamlegast vísa til fyrirlestrarefnisins:
- Tilkynna glærur:
Hughrif okkar
Fyrsta þátttaka okkar í C++ Rússlandi var eftirminnileg fyrir styrkleika. Mér fannst C++ Rússland vera einlægur atburður, þar sem mörkin milli þjálfunar og samskipta í beinni eru nánast ómerkjanleg. Allt, allt frá skapi ræðumanna til keppna frá samstarfsaðilum viðburðarins, stuðlar að heitum umræðum. Innihald ráðstefnunnar, sem samanstendur af skýrslum, nær yfir nokkuð breitt svið efnis þar á meðal nýjungar í C++, dæmisögur um stór verkefni og hugmyndafræðilegar byggingarfræðilegar skoðanir. En það væri ósanngjarnt að hunsa félagslega þætti viðburðarins, sem hjálpar til við að yfirstíga tungumálahindranir í tengslum ekki aðeins við C++.
Við þökkum skipuleggjendum ráðstefnunnar fyrir tækifærið til að taka þátt í slíkum viðburði!
Þú gætir hafa séð færslu skipuleggjenda um fortíð, nútíð og framtíð C++ Rússlands .
Takk fyrir lesturinn og við vonum að endursögn okkar af atburðum hafi verið gagnleg!
Heimild: www.habr.com