Mikhail Matrosov ( mmatrosov ) adalah seorang insinyur pengembangan terkemuka di kantor Litbang Moskow Teknologi Align. Spesialisasi yang dimilikinya sangat tidak biasa - ia sedang mengembangkan sistem CAD khusus untuk desain peralatan ortodontik.
Mikhail telah berpartisipasi dalam C ++ Rusia sejak konferensi pertama. Tahun ini, di C ++ Russia 2019 Piter, ia akan memberikan presentasi tentang “Kualifikasi, Kualifikasi dan Templat” . Anda juga dapat mengenalnya di kursus dari Yandex "Dasar-Dasar Pengembangan C ++: Brown Belt" dan "Dasar-Dasar Pengembangan C ++: Sabuk Hitam" di Coursera, dalam penciptaan yang ditulis bersama oleh Michael.
Konferensi ini sudah dekat, tetapi untuk saat ini, ikuti wawancara dengan Mikhail, di mana kami membahas karyanya di Align Technology, migrasi kode lama, persiapan kursus dan laporan online, serta fitur C ++. Pertanyaan diajukan oleh Pavel Filonov (komite program C ++ Rusia) dan Oleg Chirukhin (jurnalis Grup JUG Ru).
Di persimpangan teknologi dan kedokteran
Pavel: Katakan padaku apa yang sedang dilakukan perusahaanmu.
Michael: Align Technology adalah pelopor dan pemimpin pasar dalam bidang ortodontik bersih. Ini adalah hal yang sedang dilakukan di seluruh dunia sekarang, bukan kawat gigi. Jika sebelumnya, kawat logam ditempatkan untuk meluruskan gigi, dan mereka berlari dengannya, sekarang alih-alih Anda memakai pelindung mulut plastik transparan (liner), yang dibuat secara terpisah untuk setiap pasien. Baru-baru ini saya menguji sendiri produk-produk perusahaan kami, perasaan yang sangat lucu!
Pavel: Jadi Anda punya dogfooding seperti itu, ya, ternyata?
Michael: Ya, semacam itu. Faktanya, jika Anda tidak tahu, sangat sulit untuk memperhatikan bahwa orang tersebut ada dalam barisan. Kecuali pada awalnya, karena kebiasaan, cacat bicara kecil muncul, tetapi bahkan mereka sulit untuk diperhatikan.
Pavel: Dan apa hubungannya C ++, yang akan kita bicarakan hari ini?
Michael: Pertanyaan yang bagus. Ketika perusahaan itu baru dalam masa pertumbuhan, dua orang Pakistan yang ceria mengambil beberapa plastik khusus (saya tidak tahu dari mana mereka menemukannya), yang seharusnya tidak beracun dan lembam dengan air liur dan zat lain di mulut.
Kemudian mereka mengambil model rahang pasien, yang mereka tahu bagaimana melakukannya untuk waktu yang sangat lama. Misalnya, untuk membuat mahkota, seseorang diberi gigitan seperti plastisin khusus. Ada gips gigi yang penuh dengan material. Jadi mereka mendapatkan salinan rahang, dan mereka menarik plastik (entah bagaimana mereka menghangatkannya), dan juru bicara siap. Artinya, seluruh pasar ini secara harfiah 20 tahun yang lalu sepenuhnya analog.
Sekarang volume produksi di wilayah 300-400 ribu liner per hari (silakan evaluasi skalanya). Ini adalah manufaktur raksasa, oleh karena itu mereka sepenuhnya otomatis.
Untuk membuat liner, kami mencetak pada cetakan printer 3D khusus. Faktanya, ini adalah salinan dari rahang pasien selama perawatan. Kami memodelkan bagaimana rahang akan terlihat dalam satu minggu, dua, bulan, tahun. Lalu kami memulai proses thermoforming - kami mengambil pita plastik, memanaskannya dan menariknya ke cetakan. Potong dan dapatkan liner plastik.
Saat ini, tidak ada seorang pun yang melakukan pengecoran terhadap pasien, dan mereka menggunakan pemindai intraoral tiga dimensi. Kami punya orang yang melakukan ini di kantor terdekat. Ini mungkin adalah bagian paling "wow" dari produksi kami. Di sana, secara real time, nosel khusus mengarah di sepanjang rahang dan membangun bentuknya. Informasi diunggah ke server perusahaan, diproses dan dikirim ke spesialis kami (teknisi). Mereka dapat mengedit pemindaian, menghilangkan noise.
Kemudian perawatan direncanakan dalam sistem CAD khusus. Ini adalah hal yang sangat rumit, karena tidak ada yang tahu apa gigitan yang tepat. Setiap dokter memiliki pandangannya sendiri tentang masalah ini. Kami saat ini bekerja untuk memformalkan pendekatan terhadap pengobatan, tetapi ini belum ada dalam prod.
Tetapi kembali ke C ++. Ada masalah seperti itu, misalnya. Cetakan dicetak pada printer 3D khusus menggunakan teknologi laser stereolithography. Ada tong besar dengan cairan photopolymer khusus. Mereka menyinari dengan laser dan mengeras. Pertama, mereka bersinar di bagian paling bawah dari model yang dicetak, kemudian sedikit lebih tinggi, bahkan lebih tinggi, dll. Jadi, di dalam fluida, model padat muncul dari bawah ke atas berlapis-lapis.
Mencetak satu per satu cetakan tidak praktis. Tong cukup besar dan Anda dapat memasukkan sekitar seratus cetakan ke dalamnya. Tetapi mereka harus diatur secara kompak. Bentuk cetakan mirip dengan tapal kuda - yaitu, non-cembung dan agak rumit. Dan mereka semua berbeda. Ternyata tugas yang menarik dari ubin persegi panjang dengan angka-angka yang kompleks.
Di sini, di video ini dari cap waktu yang ditentukan Anda dapat melihat tampilannya.
Ini hanya satu contoh, ada banyak tugas.
Pavel: Deskripsi Anda seperti perhitungan teknologi tinggi. Bahasa seperti Fortran secara historis berkinerja baik di dalamnya. Setidaknya Anda masih bisa melihat gema. Mengapa tepatnya C ++?
Michael: Ya, bukan Fortran, itu akan sangat kuat. Pada awal pengembangan, produk utamanya adalah sistem CAD yang sangat khusus ini - aplikasi desktop untuk Windows. Oleh karena itu, bahasa diperlukan untuk komputasi yang efisien dan pada saat yang sama untuk mengembangkan aplikasi itu sendiri. Tidak banyak pilihan saat itu - hanya C ++.
Sekarang kami memiliki kebun binatang bahasa: JavaScript dan TypeScript untuk web, Java untuk aplikasi mobile, Go untuk server, Python untuk otomatisasi, dan banyak hal kecil. Pada dasarnya, tumpukan standar. Dan dalam aplikasi yang kompleks sains dan komputasi, C ++ tetap ada.
Semakin tinggi posisinya, semakin lebar cakrawala.
Pavel: Anda menyebut posisi Anda sebagai insinyur kepala. Jadi saya melihat keanehan. Jika pengembang C ++ pemula dari perusahaan Anda ditanya apa yang ia lakukan, ia akan mengatakan bahwa ia sedang memutar beberapa jenis kerangka kerja super berdasarkan template yang didasarkan pada tingkat kenaikan yang melakukan penyeimbangan server, dan teknologi akan segera jatuh.
Ketika Anda ditanya apa yang dilakukan perusahaan Anda, seluruh cerita dimulai tentang bisnis: di mana uang itu, mengapa itu penting, dll. Apakah ini entah bagaimana berkorelasi dengan posisi Anda? Apa pandangan proses, teknologi, alat-alat ini?
Michael: Ya, mungkin. Tetapi selain itu, jika saya mulai segera memberi tahu tentang bagaimana saya menyeberang pohon (meskipun saya tidak melakukannya sendiri), itu tidak akan jelas bagi semua orang. Misalnya, dudes dari Yandex, Kaspersky Lab dapat memulai dengan teknologi, karena semua orang tahu produk mereka. Kita berbicara tentang liner, yang diketahui oleh sedikit orang. Karena itu, perlu dijelaskan apa itu.
Mengenai bagaimana ini berkorelasi dengan pos. Di kelas saya, saya setidaknya harus memahami elemen alur kerja kami dari sistem saat ini yang bekerja bersama. Lagi pula, jika ada perubahan, maka ini dapat memengaruhi produksi, situs dokter, antarmuka yang digunakan teknisi, dokter, dan analis bisnis. Ya, ada korelasi. Dengan pertumbuhan kelas, Anda perlu melihat dengan lebih baik apa yang terjadi di perusahaan.
Pavel: Apakah Anda berpikir bagaimana pengenalan teknologi baru, katakanlah, yang terkait dengan C ++, akan memengaruhi alur kerja? Hanya sedikit orang yang melihat fitur baru bahasa ini. Dan jika tidak, beri tahu kami bagaimana Anda baru-baru ini mengimplementasikan alat?
Michael: Saya tidak ingat tentang C ++ begitu saja. Jika kita mengambil alat, hal terakhir yang kita lakukan adalah sistem logging berbasis cloud. Kami secara khusus menggunakan Splunk untuk ini. Awalnya, platform berada di bawah desktop, dan migrasi ke cloud sekarang berjalan lancar. Oleh karena itu, kami mempercepat, khususnya, logging berbasis cloud. Manajer kami dengan cepat belajar membuat permintaan dan membuat dasbor yang indah, menampilkan grafik waktu nyata. Saya sangat senang. Saya mengirimkannya kepada semua orang dan berkata, lihat bagaimana kami memvariasikan waktu operasi dari algoritma yang sedemikian kompleks, apa alasannya? Mereka mulai mengerti, kami menyadari bahwa kami hampir tidak memiliki multithreading pada agen uji. Sesuatu terus-menerus diperkenalkan.
C ++, Legacy, cross-platform dan segalanya, segalanya, segalanya
Oleg: Apakah saya mengerti benar bahwa Anda telah merender di browser?
Michael: Ya, ada.
Oleg: Teknologi browser terus berubah. Apakah itu mempengaruhi? Sebagai contoh, JS baru, Bahasa Shading , sesuatu seperti itu.
Michael: Itu memengaruhi, tapi agak membosankan di sini. Dalam hal rendering, pemandangannya cukup sederhana. Kami tidak memiliki efek khusus yang luar biasa.
Pavel: Bagus. Tetapi Anda mengatakan bahwa Anda mulai dengan aplikasi desktop, di mana C ++ adalah solusi terbaik yang menggabungkan semua keunggulan. Ketika bisnis mulai tumbuh dengan produk, Anda mulai mengembangkan platform lain. Beberapa kode masuk ke browser, beberapa ke backend, beberapa ke ponsel. Apakah inti "positif" tetap ada di semua platform?
Michael: Gerakan ke platform lain dimulai dua tahun lalu, dan untuk skala kami ini adalah waktu yang singkat. Oleh karena itu, solusi cloud pertama kami adalah desktop monolith, dari mana, secara kasar, GUI dilemparkan. Sekitar satu setengah tahun yang lalu, kami mengisolasi kernel bersyarat dan mengikatnya, sehingga kami dapat mengkompilasi dan menjalankannya di Linux. Itu adalah terobosan besar. Linux penting bagi kami terutama karena mesin cloud Linux jauh lebih murah.
Sekarang kami ingin memisahkan inti komputasi dalam C ++, di mana semua perhitungan kompleks akan terjadi, dari logika bisnis yang menjelaskan apa yang harus dilakukan dan dalam urutan apa, dari mana asalnya, jenis produk apa, apa yang hak dokter untuk lakukan dan apa yang tidak, dan itu saja.
Pavel: Anda mungkin sudah memiliki peta jalan dari proses ini, karena Anda membicarakannya dengan baik.
Michael: Kami mencoba berkali-kali untuk membuat peta jalan. Kami memahami di mana kami bisa bergerak, dengan mempertimbangkan 20 tahun Legacy (Anda tidak bisa sampai di sana dengan setengah dolar, Anda harus memikirkannya).
Interaksi proyek positif sekarang dilakukan dengan cara yang sederhana. Dari semua ini, itu adalah antarmuka C ++ yang menonjol, jadi mereka hanya berkumpul untuk memastikan ada satu kompiler. Sebanyak sekitar 250 proyek, masing-masing pergi ke perpustakaan dinamis sendiri. Dan kami menggabungkannya dengan berbagai cara untuk tugas-tugas tertentu.
Sekitar 10 tim bekerja di sistem. Setiap tim merekrut sebagian dari proyek-proyek ini, biasanya 50-70. Sekarang kami bergerak ke arah beberapa layanan akan dibuat berdasarkan mereka. Kami mendefinisikan API ketat untuk layanan (berdasarkan protobuf atau yang lain), dan membuat skema standar interaksi antara layanan. Sulit untuk menyebut proses pemisahan komputasi dan logika, tetapi ini adalah upaya pertama pada komponenisasi.
Tim saya dan beberapa orang lainnya sudah mulai melakukan ini. Anda segera merasakan betapa lebih lucu ketika Anda mengumpulkan monolit dari tidak hanya 250 proyek, tetapi hanya dari 70 proyek. Dan tidak ada lagi situasi di mana seseorang mengubah modul lain yang berinteraksi dengan hal-hal yang tampaknya sama sekali tidak berhubungan, dan sesuatu pecah . Ini memiliki efek psikologis yang keren. Dan sementara kami mencoba untuk melepaskan diri dari monolit desktop yang sehat dengan mengalokasikan 10 monolit kecil bersyarat untuk layanan kami.
Pavel: Dan selama proses ini, Anda tidak mempertimbangkan apakah modul yang akan dijanjikan dimuat dalam beberapa bentuk dapat membantunya di level mana saja?
Michael: Ini adalah proses ini dan proses migrasi Linux yang Conan bantu kami. Kami memiliki masalah serius dalam mengelola pihak ketiga. Saya berbicara tentang bagaimana kami menggunakan Conan di C ++ Russia 2019 di Moskow.
Modul “plus” akan membantu menyelesaikan beberapa masalah dengan waktu kompilasi, di mana, pada kenyataannya, semuanya dimulai, mengapa semua orang sangat menginginkan modul. Menggunakan kembali modul positif untuk berinteraksi dengan layanan adalah bodoh, karena mereka akan berkomunikasi pada tingkat bahasa-agnostik (protobuf), dan memang demikian. Mungkin kita akan dapat melakukan komponenisasi dan tidak membangun 250 proyek kami dari sumber setiap kali, tetapi memasukkannya ke dalam paket Conan. Dan jika, misalnya, melipat dll tidak nyaman untuk alasan tertentu, maka merakit menjadi modul adalah pilihan.
Tapi saya tidak bisa mengatakan bahwa kami sedang menunggu beberapa fitur yang akan mengubah pendekatan kami terhadap pengembangan.
Pavel: Anda menyebutkan bahwa Conan membantu Anda memecahkan masalah manajemen paket. Menurut pendapat saya, sekitar 3 tahun yang lalu, komunitas C ++ hanya membicarakan hal ini. Laporan pertama muncul, prasyarat pertama. Dan sekarang Anda mengatakan bahwa itu sudah berfungsi dalam produksi.
Ceritakan tentang pengalaman Anda tentang evolusi proyek. Apakah proses transisi menyakitkan dan sepadan?
Michael: Pasti sepadan. Kami puas dengan Conan. Ada beberapa kelemahan di sana, tetapi mengelola dependensi dalam C ++ adalah tugas yang sangat sulit. Oleh karena itu, jelas bahwa tidak akan ada alat sederhana untuk menyelesaikannya.
Dengan Conan dan prosesnya, kami telah mencapai keseimbangan tugas dan kompleksitas solusi. Kami awalnya berkata: "Oke, kami ingin menyoroti sekumpulan dan sekumpulan kompiler dan konfigurasi, kemudian membangun pustaka dinamis (bukan yang statis) secara default, buat sekumpulan kecil pembatasan," dan kami mulai membangun sistem dalam sekumpulan pembatasan ini. Kami memiliki halaman wiki "Cara membuat resep Conan untuk perpustakaan", yang memperhitungkan semua spesifikasi sistem kami. Halaman ini cukup besar dan tidak terlalu sederhana. Tetapi, sekali lagi, kami telah mencapai keseimbangan kompleksitas, jadi saya senang dengan transisi.
Pavel: Dan di sini, ngomong-ngomong, di C ++ Russia 2019 Piter Denis Panin yang akan datang dari NVIDIA akan berbicara tentang alternatif yang diwakili oleh vcpkg . Apakah akan menarik bagi Anda untuk pergi ke laporan dan mendengarkan bagaimana mereka melakukannya di alat lain?
Michael: Ya, itu akan menarik. Saya menggunakan vcpkg sedikit, tetapi, menurut pendapat saya, sangat sedikit fleksibilitas dalam vcpkg. Dan saya tidak bisa membayangkan bagaimana kita bisa membangun sistem dengan persyaratan kita berdasarkan vcpkg. Tetapi jika saya perlu mengambil dan menguji beberapa jenis perpustakaan dengan cepat, maka saya tidak akan mengunduhnya dan membaca Build Instruksi, bahwa di sana Anda perlu menentukan cara mendaftar dependensi, ini semua adalah sampah. Saya akan melihat apakah itu ada di port vcpkg. Jika ada, maka cepat letakkan, bereksperimenlah dengannya. Jika semuanya baik-baik saja, maka saya akan menulis resep conan untuknya.
Pavel: Mari kita lanjutkan tentang pengenalan alat dan pendekatan baru. Pernahkah Anda menemukan fakta bahwa para insinyur datang berlari dengan mata membara dari sebuah konferensi di mana mereka diberi tahu tentang hal baru yang keren dan mereka ingin memasukkannya ke dalam proyek? Bagaimana Anda biasanya bereaksi terhadap hal-hal seperti itu? Atau jadi Anda resor setelah setiap konferensi?
Michael: Hanya ada cerita yang bagus. Ketika saya baru saja mulai bekerja di perusahaan, mereka menulis fitur, dan itu perlu untuk membuat konfigurasi untuk itu. Selain itu, fitur dapat memiliki beberapa versi yang berbeda, dan nilai-nilai properti tertentu dapat digeledah antara versi yang berbeda. Dan saya datang dengan skema berbasis YAML keren di mana ada warisan dan redefinisi properti. Dia menulisnya selama sekitar satu minggu, menutupinya dengan tes. Dan pada awalnya manajer datang kepada saya dan berkata: "Dengar, Michael, mungkin Anda tidak perlu membuang waktu sekarang dan membuat skema yang fleksibel?" Tetapi dia tidak bisa meyakinkan saya. Mataku terlalu terbakar.
Setelah beberapa tahun, saya melihat kode ini dan tidak mengerti mengapa itu sangat sulit dilakukan. Ini terjadi, tetapi, untungnya, sejak saat itu saya menjadi lebih pintar. Selain itu, biasanya pengembang adalah orang yang sangat rasional, Anda dapat berbicara dengan mereka.
Dulu seseorang menarik keputusan pihak ketiga yang meragukan. Tidak jelas oleh siapa mereka mengembangkan, pembaruan terakhir adalah 5 tahun yang lalu, belum diverifikasi apakah ia bekerja di Linux, mereka menghasilkan laporan dalam format berpemilik yang tidak dapat Anda konversi menjadi apa pun. Dan kami duduk dan tidak mengerti apa yang harus dilakukan selanjutnya. Sebagian besar pihak ketiga ini ditambahkan bertahun-tahun yang lalu, tetapi hal serupa terjadi sekarang.
Oleh karena itu, kami menemukan hal yang cukup sederhana - daftar periksa pihak ketiga. Jika Anda ingin menyeret pihak ketiga, cukup periksa item daftar periksa: lintas platform, tingkat dukungan, lisensi, analog mana, tingkat dukungan pengembangan (berapa banyak dukungan pengelola, komunitas mana). Semua poin sudah jelas, tetapi jumlahnya cukup banyak, dan saat Anda mengetik pihak ketiga, Anda tidak akan segera mengingat semuanya. Situasinya menjadi lebih baik, dan kami mengawasi apa yang ditambahkan.
Ini juga keren bahwa dulu mudah untuk menyeret pihak ketiga dan merakitnya, misalnya, hanya dalam rilis di bawah Windows dan 32 bit. Sekarang, pada prinsipnya, tidak ada kemungkinan seperti itu, karena Anda harus meletakkannya di Conan. Dan jika Anda menyeret pihak ketiga, Anda harus memastikan atau secara eksplisit menunjukkan bahwa dalam beberapa konfigurasi tidak akan. Berkat ini, pihak ketiga kiri mulai ditambahkan lebih sedikit.
Oleg: Dan bagaimana dengan pihak ketiga, yang hidup sangat sedikit? Misalnya, beberapa pad kiri dari JavaScript. Dia masuk daftar periksa Anda. Itu sering diperbarui, dipelihara, dibuat oleh paket.
Michael: Tidak ada hal seperti itu. Dalam C ++, pihak ketiga biasanya merupakan hal yang tebal. Dan solusi pihak ketiga yang menjalankan fungsi kecil tidak digunakan. Memang, dalam C ++ tidak begitu mudah untuk menambahkan pihak ketiga. Dan ini bukan JS, di mana masing-masing memiliki modul sendiri.
Kami secara kondisional menarik 80 pihak ketiga, setengahnya belum pernah saya lihat. Atau semacam geometri neraka yang ditulis 15 tahun lalu di beberapa universitas, dan kami memilikinya.
Oleg: Dengan Conan, mudah untuk menambahkan pihak ketiga.
Michael: Conan lebih mudah, tetapi masih jauh dari Python yang sama di mana Anda menulis pip install dan Anda selesai. C ++ memiliki ekosistem yang sangat kompleks: berbagai sistem operasi, kompiler, toolchain, perpustakaan, standar. Sebagian besar perpustakaan memiliki banyak opsi.
Mereka suka bertanya kepada kami, "Mengapa Anda menulis resep perpustakaan Anda, tetapi tidak mengambilnya dari Conan-center?" Saya melihat secara berkala dari sana resep, tetapi mereka tidak cocok untuk kita. Kami melakukan yang lebih baik. Misalnya, resep kami menangani simbol debit, dan menambahkan ikatan ke sumber di dalamnya. Jadi ketika Anda mendapatkan pustaka pihak ketiga dari debugger dari Visual Studio, sumber dimuat secara otomatis.
Jadi dengan Conan jauh lebih baik, tetapi masih jauh dari kenyamanan bahasa lain.
Oleg: Apakah ada kekurangan di Conan yang ingin saya koreksi?
Michael: Ya, ada kekurangannya, tapi teknis.
Conan memiliki metode yang secara kondisional bertanggung jawab untuk menghasilkan paket dan untuk menghubungkan paket yang dihasilkan ke solusi Anda. Secara ideologis, ini adalah dua tahap yang berbeda, dan saya dapat mengubah satu tanpa mengubah yang lain. Ketika saya mengubah cara paket terhubung, saya tidak ingin membuat ulang paket biner, karena mereka akan persis sama. Anda tidak dapat melakukan ini di Conan, karena resepnya adalah satu kesatuan. Jika Anda mengubah resep, maka secara formal Anda harus mengubah versi dan menghasilkan binari baru, yang tidak nyaman.
Fitur transisi ke standar baru
Pavel: Mari kita bicara tentang standar baru. Selain itu, produk Anda sudah memiliki beberapa riwayat.
Sekarang kita datang ke konferensi, di mana setiap tiga tahun mereka memberi tahu kita tentang fitur baru yang luar biasa. Misalnya, di C ++ Russia 2019 Piter akan ada tiga laporan tentang perubahan bahasa yang akan datang. Apakah Anda memiliki pengalaman memigrasi basis kode lama, yang sesuai dengan standar lama, ke apa yang ditawarkan atau akan ditawarkan?
Mikhail: Ya, saya punya pengalaman seperti itu, sedikit membicarakannya di C ++ Russia 2019. Kami memiliki migrasi dari Visual Studio 2013 ke Visual Studio 2017 dan gcc, yaitu, kami secara bersamaan menambahkan dukungan Linux dan pembaruan kompiler dari Microsoft.
Masalah dalam kode jauh lebih sedikit dibandingkan dengan masalah organisasi, teknis, infrastruktur, CI dan seluruh tuning. Dan masalah kami dalam kode terutama terkait dengan UB, yang, setelah memperbarui kompiler, mulai menembak. Meskipun C ++ menyebar busuk selama bertahun-tahun kompatibilitas ke belakang, tetapi itu membantu. Sekarang kami mengkompilasi semuanya di bawah C ++ 17.
Vorings tidak disinkronkan ketika pengembang mengumpulkan di bawah Windows, mendorong ke CI dan hanya setelah itu mereka mulai berkumpul di Linux. Tetapi tidak ada masalah yang signifikan.
Di C ++ 17, beberapa hal usang dihapus, tetapi kami hanya menghabiskan beberapa jam untuk menghapusnya. Sebagai contoh, pustaka log4cplus menggunakan std :: auto_ptr di header, tetapi dalam versi baru itu sudah diganti dengan std :: unique_ptr, jadi itu cukup dengan hanya memperbarui perpustakaan.
Jadi migrasi ke standar baru relatif tidak menyakitkan. Dan mengingat ukuran basis kode kami, saya terkejut betapa sedikit masalah yang kami temui.
Tentang sabuk cokelat dan hitam di C ++
Pavel: Anda dan saya sudah berbicara tentang proses yang ada, di mana pengembang dengan pengalaman sudah bekerja. Mari kita berikan makanan untuk dipikirkan oleh pengembang pemula yang baru belajar. Standar C ++ apa yang akan Anda rekomendasikan mulai?
Michael: Kita harus segera mengambil standar terbaru. Anda tidak akan belajar STL dalam C ++ 98 yang sama, karena STL tanpa lambdas tidak masuk akal. Jika Anda melihat kursus "Fundamentals of Development di C ++: Brown Belt" dan "Fundamentals of Development di C ++: Black Belt" di Coursera, maka kami sudah menulis dalam C ++ 17 di sana. Misalnya, kami menggunakan binding terstruktur.
: , . , . , ?
: , . , C++. , C++, , . , , . , , , , . , . , , , Align Technology.
: , , . Mengapa
: -, — . , . , . , , , . -, , , . . -, - ( ), -, . . . . . . , , , , . , , tutorial . -, , .
: , . , . ?
: , . , .
: , «» . , . «» , ?
: , , . . , - . , .
C++ . , . , . , , . . - , .
, . , , , . , . « ?». , .
. C++ Russia . ?
: . , , . , , . , .
: , . , ? 2015, 2019 2020 ?
: , , , , . - . , , , . , , . , .
CppCon 2018 . , , . C++ . , , .
. , — , .
: ?
: const, volatile, static, constexpr, inline, extern . , , ..
: consteval constinit?
: . , , . , 3-4 , .
: , , Visual Studio constexpr?
: Visual Studio . , . , constexpr-.
: , : , , .
: Visual Studio , . , 2010 : , . Microsoft .
: . : const, constexpr, constinit, consteval , , final. final , , constfinal?
: final, , . . , constfinal, .
: , , , , . ?
: , , . , , .
: ?
: , JUG Ru Group , ().
: . ?
: , — . , , , . .
: . , ?
: , . , ().
C++ Russia 2019 Piter «, » . , .