ProHoster > Блог > интернет мэдээ > C++ Орос: энэ нь хэрхэн болсон

C++ Орос: энэ нь хэрхэн болсон

Жүжгийн эхэнд хананд C++ код өлгөөтэй байна гэвэл төгсгөлд чинь хөл рүү чинь буудах нь дамжиггүй.

Бжарне Строструп

31-р сарын 1-ээс XNUMX-р сарын XNUMX-ний хооронд C++ Russia Piter бага хурал Санкт-Петербург хотод болсон - JUG Ru группээс зохион байгуулсан Орос дахь томоохон хэмжээний програмчлалын бага хурлын нэг. Зочин илтгэгчид нь C++ Стандартын Хорооны гишүүд, CppCon илтгэгчид, O'Reilly номын зохиогчид, LLVM, libc++, Boost зэрэг төслүүдийн хөтлөгчид багтдаг. Энэхүү бага хурал нь туршлагаа гүнзгийрүүлэх, амьд харилцааны талаар туршлага солилцох хүсэлтэй туршлагатай C++ хөгжүүлэгчдэд зориулагдсан юм. Оюутан, аспирант, их дээд сургуулийн багш нарт маш сайхан хөнгөлөлт үзүүлж байна.

Чуулганы Москва дахь хэвлэлийг ирэх оны XNUMX-р сард үзэх боломжтой боловч энэ хооронд манай оюутнууд сүүлийн арга хэмжээн дээр ямар сонирхолтой зүйл сурснаа танд хэлэх болно. 

C++ Орос: энэ нь хэрхэн болсон

авсан зураг хурлын цомог

Бидний тухай

Энэ бичлэг дээр Санкт-Петербург хотын Үндэсний судалгааны их сургуулийн Эдийн засгийн дээд сургуулийн хоёр оюутан ажилласан.

  • Лиза Василенко нь Хэрэглээний математик, компьютерийн шинжлэх ухааны хөтөлбөрийн хүрээнд Програмчлалын хэлээр суралцаж буй бакалаврын 4-р курсын оюутан юм. Би их сургуульд эхний жилдээ С++ хэлтэй танилцсаны дараа тухайн салбартаа дадлага хийснээр энэ хэлтэй ажиллах туршлага хуримтлуулсан. Миний ерөнхийдөө програмчлалын хэл, ялангуяа функциональ програмчлалын хүсэл эрмэлзэл бага хурлын илтгэлүүдийг сонгоход өөрийн мөрөө үлдээсэн.
  • Даня Смирнов бол "Програмчлал ба мэдээллийн дүн шинжилгээ" магистрын хөтөлбөрийн 1-р курсын оюутан юм. Сургуульд байхдаа С++ хэл дээр олимпиадын бодлого бичдэг байсан бөгөөд дараа нь энэ хэл нь боловсролын үйл ажиллагаанд байнга гарч ирж, эцэст нь үндсэн ажлын хэл болсон юм. Би мэдлэгээ дээшлүүлэхийн зэрэгцээ шинэ боломжуудын талаар суралцахын тулд хуралд оролцохоор шийдсэн.

Мэдээллийн товхимолд факультетийн удирдлага манай мэргэжилтэй холбоотой боловсролын арга хэмжээний талаар мэдээлэл солилцдог. Есдүгээр сард бид ОХУ-ын C++-ийн талаарх мэдээллийг хараад сонсогчоор бүртгүүлэхээр шийдсэн. Ийм чуулганд оролцож байгаа анхны туршлага маань энэ юм.

Хурлын бүтэц

  • Тайлангууд

Хоёр өдрийн турш шинжээчид олон халуун сэдвийг хамарсан 30 илтгэлийг уншлаа: хэрэглээний асуудлуудыг шийдвэрлэхийн тулд хэлний онцлогийг ухаалаг ашиглах, шинэ стандарттай холбогдуулан удахгүй гарах хэлний шинэчлэлтүүд, C++ дизайн дахь буулт, тэдгээрийн үр дагавартай ажиллахдаа урьдчилан сэргийлэх арга хэмжээ, жишээнүүд. сонирхолтой төслийн архитектур, түүнчлэн хэлний дэд бүтцийн зарим нарийн ширийн зүйлс. Гурван тоглолт нэгэн зэрэг явагдсан бөгөөд ихэнхдээ хоёр нь орос хэл дээр, нэг нь англи хэл дээр байв.

  • Хэлэлцүүлгийн бүсүүд

Үг хэлсний дараа бүх асуугаагүй асуулт, дуусаагүй хэлэлцүүлгийг илтгэгчтэй харилцах тусгайлан заасан хэсгүүдэд шилжүүлж, тэмдэглэгээний самбараар тоноглогдсон. Яриа хоорондын завсарлагаатай сайхан яриа өрнүүлэх сайхан арга.

  • Lightning Talks болон албан бус хэлэлцүүлэг

Хэрэв та богино хэмжээний илтгэл тавихыг хүсвэл оройн "Аянгын яриа"-нд самбар дээр бүртгүүлж, хурлын сэдвээр ямар ч зүйлийг ярих таван минутын цаг авах боломжтой. Жишээлбэл, C++-д зориулсан ариутгагч бодисын тухай товч танилцуулга (зарим хүмүүсийн хувьд энэ нь шинэ байсан) эсвэл зөвхөн сонсогдох боловч харагдахгүй синус долгион үүсгэх алдааны тухай түүх.

Өөр нэг хэлбэр нь "Зүрхнээс зүрхэнд хүрэх хороо" хэлэлцүүлэг юм. Тайзан дээр стандартчиллын хорооны зарим гишүүд, проектор дээр задгай зуух (албан ёсоор - чин сэтгэлийн уур амьсгалыг бий болгох гэж байгаа боловч "БҮХ ЗҮЙЛ ГҮЙЦЭТГЭЭД БАЙГАА болхоор" нь илүү инээдтэй юм шиг санагддаг), C++-ийн стандарт, ерөнхий төсөөллийн талаархи асуултууд. , халуухан техникийн хэлэлцүүлэг, holiwars ямар ч. Энэ хороонд ямар нэгэн зүйлд бүрэн итгэлтэй биш, мэдэхгүй байж магадгүй амьд хүмүүс ч багтдаг болох нь тогтоогдсон.

Холиваруудын шүтэн бишрэгчдийн хувьд гурав дахь үйл явдал болох BOF хуралдаан "Go vs. C++" дээр үлдлээ. Бид Go-д дурлагч, C++-д дурлагсдыг авч, хичээл эхлэхээс өмнө тэд хамтдаа сэдвээр 100500 слайд бэлтгэдэг (C++ хэл дээрх багцуудтай холбоотой асуудал эсвэл Go-д ерөнхий мэдээлэл байхгүй гэх мэт), дараа нь тэд хоорондоо идэвхтэй хэлэлцүүлэг өрнүүлдэг. үзэгчидтэй хамт, үзэгчид хоёр үзэл бодлыг нэг дор ойлгохыг хичээдэг. Холивар контекстээс гадуур эхэлбэл модератор хөндлөнгөөс оролцож, талуудыг эвлэрүүлдэг. Энэ формат нь донтуулдаг: эхэлснээс хойш хэдэн цагийн дараа слайдын зөвхөн хагас нь дууссан. Төгсгөлийг нь маш их хурдасгах хэрэгтэй болсон.

  • Түнш зогсож байна

Хурлын хамтрагчдыг танхимд төлөөлсөн - стэндүүд дээр тэд одоо хэрэгжүүлж буй төслүүдийн талаар ярилцаж, дадлага хийх, ажилд зуучлах, асуулт хариулт, жижиг тэмцээн зохион байгуулж, сайхан шагналуудыг гардуулав. Үүний зэрэгцээ зарим компаниуд ярилцлагын эхний үе шатыг давахыг санал болгосон нь зөвхөн тайлан сонсохоор ирсэн хүмүүст ашигтай байж болох юм.

Тайлангийн техникийн дэлгэрэнгүй мэдээлэл

Бид хоёр өдөр мэдээлэл сонссон. Заримдаа зэрэгцээ илтгэлүүдээс нэг тайланг сонгоход хэцүү байсан - бид хуваагдаж, завсарлагааны үеэр олж авсан мэдлэгээ солилцохоор тохиролцсон. Тэгсэн мөртлөө их зүйл орхигдсон бололтой. Энд бид хамгийн сонирхолтой гэж үзсэн зарим тайлангийн агуулгын талаар ярихыг хүсч байна

Хөрвүүлэгчийн оновчлолын призмээр C++ хэл дээрх үл хамаарах зүйлүүд, Роман Русяев

C++ Орос: энэ нь хэрхэн болсон
-аас гулсуулна уу презентации

Гарчигнаас нь харахад Роман жишээ болгон LLVM-ийг ашиглан үл хамаарах зүйлүүдтэй ажиллахыг авч үзсэн. Үүний зэрэгцээ, Clang-г ажилдаа ашигладаггүй хүмүүсийн хувьд тайлан нь кодыг хэрхэн оновчтой болгох талаар тодорхой ойлголт өгөх боломжтой хэвээр байна. Энэ нь хөрвүүлэгч болон холбогдох стандарт номын сангуудыг хөгжүүлэгчид хоорондоо харилцаж, олон амжилттай шийдлүүд давхцаж чаддагтай холбоотой юм.

Тиймээс, үл хамаарах зүйлийг зохицуулахын тулд та маш олон зүйлийг хийх хэрэгтэй: зохицуулах код (хэрэв байгаа бол) эсвэл одоогийн түвшинд үнэгүй нөөцийг дуудаж, стекийг илүү өндөрт эргүүлээрэй. Энэ бүхэн нь хөрвүүлэгч нь үл хамаарах зүйлүүдийг хаях боломжтой дуудлагын нэмэлт зааварчилгааг нэмэхэд хүргэдэг. Тиймээс, хэрэв үл хамаарах зүйл бодитоор хөндөгдөөгүй бол програм нь шаардлагагүй үйлдлүүдийг хийх болно. Нэмэлт зардлыг бууруулахын тулд LLVM нь онцгой тохиолдлын кодыг нэмэх шаардлагагүй эсвэл "нэмэлт" зааврын тоог багасгах нөхцөл байдлыг тодорхойлох хэд хэдэн эвристиктэй байдаг.

Илтгэгч тэдгээрийн арав орчимыг судалж, програмын гүйцэтгэлийг хурдасгахад тусалдаг нөхцөл байдал, эдгээр аргуудыг ашиглах боломжгүй нөхцөл байдлыг хоёуланг нь харуулав.

Тиймээс Роман Русяев оюутнуудад онцгой тохиолдлын зохицуулалт бүхий кодыг үргэлж тэг ачаалалтайгаар гүйцэтгэх боломжгүй гэсэн дүгнэлтэд хүргэж, дараах зөвлөгөөг өгдөг.

  • номын санг хөгжүүлэхдээ зарчмын хувьд үл хамаарах зүйлээс татгалзах нь зүйтэй;
  • хэрэв үл хамаарах зүйлүүд шаардлагатай хэвээр байгаа бол хөрвүүлэгч аль болох оновчтой болгохын тулд аль болох noexcept (болон const) хувиргагчийг хаа сайгүй нэмэх нь зүйтэй.

Ерөнхийдөө илтгэгч үл хамаарах зүйлийг хамгийн бага хэмжээнд ашиглах эсвэл бүрмөсөн орхих нь зүйтэй гэсэн үзэл бодлыг баталжээ.

Тайлангийн слайдыг дараах холбоосоор үзэх боломжтой. [“LLVM хөрвүүлэгчийн оновчлолын линзээр дамжуулан C++ үл хамаарах зүйлүүд”]

Генераторууд, корутинууд болон бусад тархи тайлах амттан, Ади Шавит

C++ Орос: энэ нь хэрхэн болсон
-аас гулсуулна уу презентации

C++ 20-ийн инновацид зориулсан энэхүү бага хурлын олон илтгэлүүдийн нэг нь зөвхөн өнгөлөг илтгэлээрээ төдийгүй, цуглуулгын боловсруулалтын логиктой холбоотой асуудлуудыг (for loop, back calls) тодорхой тодорхойлсоноороо мартагдашгүй байлаа.

Ади Шавит дараахь зүйлийг онцлон тэмдэглэв: Одоогийн байгаа аргууд нь бүхэл бүтэн цуглуулгад хамрагдаж, зарим дотоод завсрын төлөвт нэвтрэх боломжийг олгодоггүй (эсвэл буцаан залгасан тохиолдолд ийм байдаг, гэхдээ дуудлагын там гэх мэт олон тооны таагүй гаж нөлөө үзүүлдэг) . Дахин давтагч байгаа юм шиг санагдаж байна, гэхдээ тэдэнтэй байсан ч бүх зүйл тийм ч жигд биш байна: нийтлэг орох, гарах цэг байхгүй (эхлэх → төгсгөл, rbegin → тайлах гэх мэт), бид хэр удаан давтах нь тодорхойгүй байна уу? C++ 20-ээс эхлээд эдгээр асуудлууд шийдэгдлээ!

Эхний сонголт: мужууд. Давталтуудыг боож өгснөөр бид давталтын эхэн ба төгсгөлд зориулсан нийтлэг интерфэйсийг олж авахаас гадна зохиох чадварыг олж авдаг. Энэ бүхэн нь бүрэн хэмжээний өгөгдөл боловсруулах дамжуулах шугамыг бий болгоход хялбар болгодог. Гэхдээ бүх зүйл тийм ч жигд биш юм: тооцооллын логикийн нэг хэсэг нь тодорхой давтагчийн хэрэгжилтийн дотор байрладаг бөгөөд энэ нь кодыг ойлгох, дибаг хийхэд хүндрэл учруулж болзошгүй юм.

C++ Орос: энэ нь хэрхэн болсон
-аас гулсуулна уу презентации

За, энэ тохиолдолд C++20-д корутин нэмсэн (зан төлөв нь Python дахь генераторуудтай төстэй функцууд): завсрын төлөвийг хадгалахын зэрэгцээ одоогийн утгыг буцаах замаар гүйцэтгэлийг хойшлуулж болно. Тиймээс бид өгөгдөлтэй харагдах байдлаар нь ажиллахаас гадна тодорхой корутин доторх бүх логикийг багтаасан болно.

Гэхдээ тосонд ялаа бий: одоогоор тэдгээрийг одоо байгаа хөрвүүлэгчид зөвхөн хэсэгчлэн дэмжиж байгаа бөгөөд бидний хүссэн шиг цэвэрхэн хэрэгжүүлээгүй байна: жишээлбэл, корутин дахь лавлагаа, түр зуурын объектуудыг ашиглах нь үнэ цэнэтэй зүйл биш юм. Дээрээс нь coroutines байж болох зарим хязгаарлалтууд байдаг бөгөөд constexpr функцууд, байгуулагч/устгагч, үндсэн функцууд энэ жагсаалтад ороогүй болно.

Тиймээс, корутинууд нь өгөгдөл боловсруулах логикийн энгийн байдлаас шалтгаалан асуудлын нэлээд хэсгийг шийддэг боловч одоогийн хэрэгжилт нь сайжруулалтыг шаарддаг.

Материал:

Yandex.Taxi, Антон Полухин нарын C++ заль мэх

Мэргэжлийн үйл ажиллагаандаа заримдаа би зөвхөн туслах зүйлсийг хэрэгжүүлэх шаардлагатай болдог: дотоод интерфэйс болон зарим номын сангийн 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++ заль мэх"]

Таны кодыг DRY байлгах орчин үеийн техник, Бьорн Фаллер

Энэ илтгэлдээ Бьорн Фаллер нөхцөл байдлын давтан шалгалтын хэв маягийн алдаатай тэмцэх хэд хэдэн өөр аргыг харуулж байна:

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

Танил сонсогдож байна уу? Сүүлийн үеийн стандартуудад нэвтрүүлсэн хэд хэдэн хүчирхэг C++ техникийг ашигласнаар та гүйцэтгэлийн торгуульгүйгээр ижил функцийг гоёмсог байдлаар хэрэгжүүлж чадна. Харьцуулах:   

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

Тогтворгүй тооны шалгалтуудыг зохицуулахын тулд та нэн даруй вариад загвар, нугалах илэрхийлэл ашиглах хэрэгтэй. Бид тооллын төрийн_төрлийн элементтэй хэд хэдэн хувьсагчийн тэгш байдлыг шалгахыг хүсч байна гэж бодъё. Хамгийн эхний зүйл бол туслах функцийг бичих явдал юм:


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) болон lambda функцууд дахь загвар параметрүүд (C++20) зэрэг функцуудыг ашиглалтын жишээн дээр тайлбарлав. (Тийм ээ, одоо ламбдагийн синтаксийг санахад илүү хялбар болсон - эдгээр нь бүх төрлийн дараалсан дөрвөн хос хаалт юм.) Функцуудыг бүтээгчийн дэлгэрэнгүй болгон ашигласан эцсийн шийдэл нь ламбдагийн шилдэг уламжлалууд дахь илэрхийлэлийн tuple-ийг дурдахад миний сэтгэлийг үнэхээр дулаацуулж байна. тооцоо.

Төгсгөлд нь өнгөлөхөө бүү мартаарай:

  • Lambdas constexpr үнэгүй гэдгийг санаарай; 
  • Төгс дамжуулалтыг нэмж, lambda хаалтын параметрийн багцтай холбоотойгоор түүний муухай синтаксийг харцгаая;
  • Хөрвүүлэгчид нөхцөлт noexcept-тай оновчлол хийх илүү боломжуудыг өгье; 
  • Ламбдагийн өгөөжийн тодорхой утгын ачаар загварт илүү ойлгомжтой алдаа гаргахад анхаарцгаая. Энэ нь хөрвүүлэгчийг загвар функцийг жинхэнэ ёсоор дуудахаас өмнө төрөл шалгах үе шатанд нэмэлт шалгалт хийхийг албадах болно. 

Дэлгэрэнгүйг лекцийн материалаас үзнэ үү: 

Бидний сэтгэгдэл

ОХУ-ын C++ хэл дээрх бидний анхны оролцоо эрчимтэй байснаараа мартагдашгүй байлаа. Би C++ ОХУ-ын сургалт, шууд харилцааны хоорондох зааг бараг үл анзаарагдам, чин сэтгэлийн үйл явдал мэт сэтгэгдэл төрүүлэв. Илтгэгчдийн сэтгэл санааны байдлаас эхлээд арга хэмжээний хамтрагч нарын тэмцээн зэрэг бүх зүйл халуун яриа өрнүүлэхэд таатай байна. Илтгэлүүдээс бүрдсэн бага хурлын агуулга нь C++ инноваци, томоохон төслүүдийн жишээ судалгаа, үзэл суртлын архитектурын асуудлууд зэрэг нэлээд өргөн хүрээний сэдвүүдийг хамардаг. Гэхдээ зөвхөн C++-тэй холбоотой хэлний бэрхшээлийг даван туулахад тусалдаг үйл явдлын нийгмийн бүрэлдэхүүн хэсгийг үл тоомсорлох нь шударга бус хэрэг болно.

Ийм арга хэмжээнд оролцох боломж олгосон хурлын зохион байгуулагчдад баярлалаа!
Та C++ Оросын өнгөрсөн, одоо, ирээдүйн тухай зохион байгуулагчдын постыг харсан байх JUG Ru блог дээр.

Уншсанд баярлалаа, бидний үйл явдлын талаар дахин ярих нь тус болсон гэж найдаж байна!

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх