C ++ vs C #

Semua orang tahu bahwa tidak ada yang lebih bodoh daripada berdebat "bahasa mana yang lebih baik." Misalnya, lebih baik untuk apa? Bahasa yang berbeda berhasil di ceruk yang berbeda - dan tidak ada gunanya menarik kesimpulan yang pasti tanpa mempertimbangkan hal ini.

Tetapi apa yang terjadi jika Anda beralih ke spesialis berpengalaman yang sendiri memahami semua ini dan meminta mereka untuk mengatur C ++ vs C # holivar? Ternyata Anda bisa mengetahui banyak detail menarik. Kata "lintas platform" dapat diterapkan dalam kedua cara untuk kedua bahasa, tetapi apa artinya ini dalam praktiknya? Apakah C ++ aktif berkembang sekarang? Apakah C # pernah merusak kompatibilitas ke belakang? Jawabannya mungkin jelas bagi mereka yang sudah tenggelam dalam kedua bahasa sekaligus, tetapi ada beberapa orang seperti itu - dan semua orang akan belajar sesuatu yang baru.

Dari C ++, Sergey sermp Platonov , Ketua Komite Program Konferensi C ++ Rusia , berpartisipasi. Sisi C # diwakili oleh Anatoly Kulakov - ia termasuk dalam PC konferensi DotNext , dan di antara para pemimpin DotNetRu . Dan pemimpin diskusi, dalam kehidupan di mana kedua dunia ini hidup berdampingan, adalah Dmitry mezastel Nesteruk .




Dmitry: Selamat sore, kolega. Selamat datang di pertemuan informal tentang topik bahasa pemrograman. Di Internet kami selalu diingatkan bahwa bahasa tidak dapat dibandingkan. Dan hari ini kami akan melakukan apa yang tidak dapat Anda lakukan: membandingkan C ++ dengan C # dan .NET, pro dan kontra mereka. Tolong perkenalkan diri Anda.

Anatoly: Nama saya Anatoly, dan hari ini saya akan tenggelam untuk C #, karena saya telah mempelajari bahasa ini dari versi pertamanya dan, sepertinya, saya tahu segalanya tentang itu.

Sergey: Hai, nama saya Sergey, saya akan tenggelam untuk C ++ hari ini. Dima dengan benar mengatakan bahwa kami akan membandingkan pro dan kontra. Semua orang menyebutnya "plus," diketahui bahwa, ternyata C # dalam diskusi ini akan menjadi minus. Benarkah itu, Anatoly?

Anatoly: C # memiliki dua plus lagi! Oleh karena itu, saya berpikir bahwa ini adalah perkembangan evolusi dari keunggulan yang sudah usang dan tidak dapat bersaing hampir di mana saja.

Pendidikan

Dmitry: Saya memiliki topik pertama untuk diskusi kami. Bayangkan bahwa mahasiswa baru datang ke universitas, mereka membutuhkan bahasa pertama. Menurut Anda apa yang harus menjadi bahasa pertama yang diperoleh orang di tahun pertama: C ++, C #, atau assembler secara umum?

Sergey: Saya mengajar selama beberapa waktu, jadi saya punya pendapat yang kuat. Saya mengerti bahwa di sini kita akan membahas bahasa mana yang lebih baik, dan saya mendukung C ++ ... Tetapi untuk mempelajari C ++, Anda perlu memahami arsitektur komputer. Dan dengan ini, masalah besar dalam mengajar siswa (setidaknya di universitas tempat saya mengajar). Dan untuk mengajarkan algoritma dan hal-hal, Anda mungkin perlu sesuatu yang tidak fokus pada infrastruktur, dalam bahasa itu sendiri. Di sini Eiffel adalah upaya untuk melakukan ini, tetapi ada juga banyak keajaiban. Karena itu, saya akan mengatakan bahwa kedua bahasa kami tidak cocok.

Pemrograman berbeda, dan bukan "pemrograman" yang mengajarkan, tetapi algoritma, struktur data, dan sebagainya. Ada kemungkinan bahwa masuk akal untuk memilih instrumen Anda sendiri pada setiap subjek. Memahami beberapa jenis struktur data Lisp. Dan C ++, oleh karena itu, harus diberikan setelah siswa memahami sesuatu tentang arsitektur. Dan kemudian akan mungkin untuk memahami mengapa semua rasa sakit dan penderitaan ini. Saya bahkan tidak akan berdebat bahwa kelebihannya adalah tentang rasa sakit.

Anatoly: Ya, saya sepenuhnya setuju bahwa Anda perlu memisahkan objek, dan tidak memasukkannya ke dalam "pemrograman" dan memalu semuanya dalam satu bahasa. Tetapi jika Anda sampai pada titik di mana Anda telah mempelajari dasar-dasar, fundamental, algoritma, dan mulai memilih beberapa jenis bahasa industri, maka, tentu saja, C # akan jauh lebih baik. Karena itu tidak memaksa Anda untuk mempelajari semua ampas ini di tingkat arsitektur, byte memori, dan "matahari terbenam dengan tangan" lainnya. Ini memberikan bahasa yang langsung dimengerti, sintaksis sederhana, dan dalam bahasa ini dari tahun pertama atau kedua Anda bisa mendapatkan uang yang cukup nyata.

Dmitry: Ada argumen bahwa tidak memberikan siswa pemula beberapa hal seperti pointer adalah semacam penistaan. Mereka akan memiliki lubang besar jika seseorang tidak mengerti bahwa, misalnya, tautan sebenarnya hanya alamat variabel dalam memori. Apa yang Anda pikirkan tentang ini?

Anatoly: 20 tahun yang lalu, ini benar ketika komputer tidak memiliki cukup memori, tidak cukup disk dan hal-hal lain. Sekarang lihat javascripts ini, mereka menyeret 500 megabyte perpustakaan ke setiap "hello world". Berapa banyak yang mereka ingat? Apa kinerja mereka? Apa saja tautannya? Ya, tidak ada yang peduli. Hal utama adalah dengan cepat menggulung dan melepaskan sesuatu dalam produksi. Saya tidak mengklaim bahwa ini adalah cara yang baik atau benar, saya berpendapat bahwa perlu untuk berubah seiring dengan kenyataan. Mungkin sekarang tidak terlalu penting seberapa banyak tautan Anda.

Sergey: Mungkin tergantung di mana. Dmitry, sejauh yang saya mengerti, tertarik pada perdagangan algoritmik - Saya dapat dengan jelas membayangkan bagaimana ia menarik perpustakaan di JS untuk mengirim pesanan ke bursa.

Dmitry: Ya, tentu saja, dalam praktiknya tidak ada yang menggunakan bahasa jenis ini di sana. Meskipun secara teori ini mungkin: jangan lupa bahwa tidak ada uang yang lemah yang dilemparkan ke infrastruktur JS. Mesin yang membuat kompilasi JS menjadi apa saja. Banyak yang menganggap bahasa ini sebagai bahasa kelas satu untuk semua hal secara umum.

Tentu saja, perdagangan algo sekarang merupakan disiplin jarak jauh dari disiplin semacam itu, tetapi perdagangan algo dan matematika finansial secara keseluruhan umumnya merupakan bidang khusus. Itu hanya mendominasi C ++. Dan itu mendominasi sebagian karena inersia, hanya karena alasan historis: pada awalnya semua orang di C ++, dan daerah ini konservatif.

Sergey: Saya tidak setuju. Saya sekarang bekerja di fintech, dan rekan-rekan yang telah ada di sini sejak awal pembicaraan perdagangan algoritmik tentang perusahaan besar yang pertama kali menulis di Jawa. Pada awalnya, Java mengatasi perdagangan algoritmik, tetapi ketika pasar mulai tumbuh dan pesaing dengan C ++ muncul, pada titik tertentu mereka tidak bisa melakukannya, mereka tidak berhasil melakukan semuanya dengan efisien ... Jadi tidak semua orang dalam perdagangan algoritmik memulai dengan C ++. Hanya mereka yang tidak menulis di atasnya yang mati. Seleksi alam.

Dmitry: Sebenarnya, Anda bisa membuatnya lebih luas. Ada banyak contoh di mana bahkan bank besar menyimpan algoritme mereka dalam dokumen Excel. Mereka kemudian menggunakan Excel juga sebagai server untuk menghitung semua ini. Ada rem yang remeh, tetapi itu semua tergantung pada apakah Anda melakukan perdagangan frekuensi tinggi (atau umumnya sesuatu frekuensi tinggi). Jika Anda adalah pembuat pasar, adalah wajar bahwa Anda memerlukan kinerja tinggi, dan di sana bisnis bahkan tidak terbatas pada C ++, di sana kami masuk ke perangkat keras dan bahasa HDL.

Tetapi diskusi kita tidak hanya seputar perdagangan algoritmik, tetapi juga tentang hal-hal sederhana. Di sini saya memberi contoh. Sehubungan dengan konstruksi, saya perlu menulis beberapa aplikasi kecil menghitung hal-hal yang berbeda: misalnya, cara meletakkan batu bata di sekitar kontur rumah. Dan saya hampir tidak bisa membayangkan bagaimana melakukan hal-hal seperti itu di C ++, karena semua yang berhubungan dengan UI lebih lemah di sana. Hanya ada satu kerangka kerja, Qt, dan bahkan menulis di atasnya sangat sulit. Dan jika saya duduk untuk C #, untuk WinForms, maka saya langsung membuat aplikasi.

Anatoly: Ya, bagian visual selalu menjadi kekuatan C #. Microsoft banyak berinvestasi dalam cetakan, dan bahkan dalam cetakan lintas platform, dan secara umum dalam visualisasi. Oleh karena itu, jika kita berbicara tentang aplikasi desktop visual, maka bagi saya tampaknya plus umumnya jauh, jauh di belakang.

Sergey: Yah, itu tergantung, seperti biasa. Saya benar-benar tidak suka UI, tetapi pada plus saya terus-menerus harus melakukannya. Tampaknya membawa JS dan hanya berinteraksi dengan pro. Tapi saya bekerja dengan tertanam, dan itu sulit. Orang-orang membeli beberapa jenis mesin mahal cepat, tetapi masih tidak dapat mengatasi rendering normal UI yang ditulis dalam JS. Dan setelah menulis ulang semua ini di Qt, ternyata overclock. Cerita biasa.

Cross-platform vs cross-platform

Sergey: Saya ingin mengklarifikasi di sini. Saya tidak tahu banyak tentang C #, saya menyentuhnya sendiri sejak lama, dalam versi pertama (saat itu saya rusak kompatibilitas ke belakang). Jadi pertanyaannya adalah: apakah masih dikembangkan hanya oleh Microsoft?

Anatoly: Tidak, sekarang lintas platform, terbuka dan diverifikasi di bawah ISO (ECMA-334 dan ISO / IEC 23270). By the way, sejauh yang saya tahu, C ++ masih tidak memiliki spesifikasi ISO terbuka, hanya dibayar. Dan C #, sebaliknya, benar-benar terbuka. Dikembangkan oleh banyak perusahaan (termasuk Google, Amazon dan Samsung), kami memiliki .NET Foundation . Saya bahkan tidak tahu bahasa yang lebih terbuka sekarang daripada C # dan platform .NET-nya.

Sergey: Ya, Haskell.

Anatoly: Omong-omong, penulis Haskell bekerja di Microsoft Research dan melakukan banyak upaya untuk membuat segala macam hal keren muncul di C # - misalnya, pemeriksaan statis, semacam refleksi, yang mungkin bahkan tidak dapat Anda mimpikan.

Sergey: Mereka bisa bermimpi, dan bahkan pekerjaan sedang berlangsung ke arah ini. Tetapi jelas bahwa semuanya memiliki harga sendiri. Dalam C ++, mereka hanya menolak untuk membayar harga ini.

Anatoly: Yang mana? Mereka dikompilasi selama dua jam, apa lagi harganya?

Sergey: Dalam C ++, prinsip abstraksi nol biaya. Yaitu, mesin virtual bukan abstraksi nol biaya, bukan? Kita harus tahan dengan ini.

Dmitry: Ya, tapi mesin virtual bisa, misalnya, mengaburkan kode untuk arsitektur tertentu. Sedangkan di C ++, jika saya menggunakan instruksi AVX di komputer tanpa AVX, proses saya hanya dimatikan. Saya akan mengatakan bahwa argumen ini tidak sepenuhnya benar, karena secara teoritis - saya tekankan, secara teoritis - JIT dapat melakukan apa yang tidak tersedia pada C ++. Yakni, optimasi pada saat peluncuran.

Sergey: Tetapi dalam C ++, selama kompilasi, Anda dapat sepenuhnya mengendalikan instruksi apa yang Anda butuhkan. Dalam hal ini, Anda tidak mengendalikannya dengan tangan Anda, tetapi Anda menyerahkan instrumen (kompiler). Lihat, instruksi apa pada arsitektur ini, set instruksi apa ...

Dmitry: Ini bisa dimengerti. Tetapi Anda dapat memformulasikannya dengan cara ini: karena ada sejuta platform, kami tidak akan pernah mendapatkan apapun yang ideal, karena kami tidak dapat merilis sejuta versi dengan flag kompilasi yang berbeda. Benar? Kami biasanya merilis x86 dan x64, tetapi jangan memecahnya menjadi beberapa subkelompok.

Sergey: Kenapa kita tidak bisa? Abad XXI. Tahan Docker dengan parameter berbeda, itu saja.

Dmitry: Ketika kami memiliki klien akhir yang mengunduh aplikasi kami, ia ingin mengunduh biner tertentu. Dan dalam biner ini, yang terbaik yang bisa kita lakukan adalah tetap di mana-mana. Seperti "jika cpuid begitu-dan-begitu dan dukungan avx begitu-dan-begitu, maka kita menggunakan algoritma versi 25". Akibatnya, kita memerlukan 25 versi berbeda dari algoritma yang sama, karena akselerasi tergantung pada platform, itu tergantung platform.

Sergey: Saya mungkin setuju. Hanya saja, jujur ​​saja, saya belum pernah membuat produk non-internal. Saya terutama di perusahaan yang menggunakan produk mereka sendiri.

Dmitry: Ya, tentu saja, pilihan terbaik adalah ketika Anda bisa menebak arsitektur. Dalam hal ini, secara tegas, tidak ada yang memaksa Anda untuk menggunakan instruksi x86 sama sekali. Anda dapat mengambil kartu tertentu (misalnya, Nvidia Tesla) dan melakukan apa pun yang Anda inginkan. Ini juga pendekatan saya, saya mengontrol arsitektur saya. Tetapi ketika Anda membuat keputusan pasar massal untuk pengguna ... Jika Anda mengambil ReSharper bersyarat, ia tidak bisa hanya mengambil dan menggunakan akselerasi GPU untuk setiap indeks yang arbitrer. Karena akselerasi GPU bukan hal yang portabel.

Sergey: Sebenarnya, ada pendekatan (sekarang Anda mungkin tidak perlu merinci), ada orang-orang yang menarik (penulis pendekatan itu, tampaknya, kini juga telah pindah ke Microsoft). Di sini, di konferensi kami tahun sebelumnya ada laporan tentang bagaimana menulis program seperti itu, yang dengan sendirinya akan mengerti di mana (relatif mudah, sekali lagi, abstraksi nol biaya). Sehingga Anda dapat memilih, dan jika ada, membuat kembali kode dengan benar dalam gaya CUDA ...

Dmitry: Sebenarnya, CUDA sendiri sedang mencoba untuk menyelesaikan masalah ini, karena di CUDA ada lapisan menengah PTX tertentu yang berurusan dengan ini. Tetapi ini masih sangat sulit, karena setrika secara radikal berubah secara evolusioner, dan sangat sulit untuk mengikutinya sama sekali. Dan jika kita melihat penggunaan akselerasi GPU, misalnya, dalam produk Adobe, maka mereka menggunakan bagian yang sangat sempit dari teknologi yang tersedia. Jika kartu Anda benar - maka ya, semuanya akan baik-baik saja. Tetapi jika ini sedikit eksotis, tidak ada yang dijamin dalam hal ini.

Anatoly: Dalam diskusi ini, kami menyinggung topik yang agak penting, mitos seperti itu: C ++ dideklarasikan bertahun-tahun yang lalu sebagai bahasa lintas platform, tetapi saat ini cross-platform jauh lebih banyak dalam C #. Satu dan hanya biner yang berfungsi di mana saja .NET didukung, dan ini hampir di mana-mana.

Sergey: Ya, ini juga tidak berdasar. Sebagai orang yang menghabiskan sebagian besar hidup saya di embedded, saya jarang melihat .NET didukung oleh toolchain pabrikan perangkat keras. Perusahaan yang memproduksi besi mengambil G ++ atau Dentang yang sama atau membuatnya mulai menghasilkan kode untuk platform mereka.

Dmitry: Ya, tetapi masalahnya adalah setiap kali mereka melakukan ini, mereka kehilangan sesuatu dari C ++. Misalnya, Nokia menggunakan variasi C ++, tetapi C ++ mereka dengan tikungan gila dan API gila yang membuat marah semua orang. Artinya, bukan hanya C ++, tetapi C ++ untuk satu atau beberapa platform lainnya. Dan kemudian masalahnya dimulai. Misalnya, ambil CUDA yang sama. Seolah-olah ia harus membiarkan pro melalui dirinya sendiri, itu bukan kompiler sama sekali, tetapi hanya seorang pengemudi. Namun terlepas dari ini, ia memiliki lelucon dengan fakta bahwa ia masih menggunakan semacam kerangka kerja untuk merobek file CUDA menjadi bagian-bagian GPU dan CPU. Dan terkadang dia tidak berhasil.

Sergey: Saya tidak bermaksud begitu. Hanya saja ketika saya mendengar ".NET berjalan di mana-mana," sebagian besar biografi kerja saya muncul kembali. Ketika Anda membeli perangkat keras dengan prosesor khusus, itu hanya dibundel dengan pengiriman G ++. Dan ada C ++ biasa, yang G ++ dapat mengkonversi dari toolchain menjadi kode mesin yang didukung oleh prosesor khusus ini.

Dmitry: Tapi sekali lagi, ini harus dipasang kembali ...

Sergey: Tentu saja.

Dmitry: Dan gagasan bahwa kita mengambil kode plus yang ada dan menyeretnya ke sepotong besi - ide ini juga tidak berfungsi, karena tiba-tiba Anda menyeret x86 reguler Anda di suatu tempat, di mana Anda memiliki memori 8 gigabyte untuk segala sesuatu tentang segalanya, dan itu tidak perluas: misalnya, tidak ada swap ke disk, karena tidak ada disk dan akses ke sana. Ini jika kita berbicara tentang portabilitas. Tergantung pada tujuan, secara alami.

Anatoly: Pro bekerja pada lebih banyak perangkat, dan, tentu saja, tertanam adalah salah satu bagian terkuat. Tetapi biasanya Anda harus menyesuaikan kode Anda dengan platform. Ini buruk. Saya dapat mencakup sejumlah besar platform, arsitektur, model dengan satu kode. Pada plus, saya harus memikirkan setiap platform individu: di mana ia akan mulai di sana, dan dalam kondisi apa. Dan itu sangat buruk, sangat menahan.

Stabilitas, kompatibilitas, pengembangan bahasa

Dmitry: Abstraksi nol biaya juga disebutkan, tetapi masalahnya adalah ini memiliki harga yang besar. Misalnya, dalam. NET ada konsep tipe enumerasi dan antarmuka IEnumerable. Dan untuk setiap jenis, misalnya, sebuah array, Anda dapat mengambil dan melewati iterator. Tetapi dalam C ++ tidak ada ide seperti itu. Karena abstraksi nol biaya, untuk berkeliling koleksi, ada beberapa mulai () dan akhir (), ada aturan untuk pekerjaan mereka, dan semua ini jauh lebih rumit (terutama bagi mereka yang mulai memprogram). Ini adalah masalah langsung: bagaimana menyiasati beberapa array dari A hingga Z.

Sergey: Jika saya mengerti benar apa yang Anda bicarakan ... Jika Anda hanya perlu berkeliling sebuah wadah dari awal hingga akhir, sekarang Anda hanya menulis, seperti dalam beberapa Python.

Dmitry: Ini semua luar biasa. Tapi Anda, misalnya, jangan gunakan polimorfisme untuk ini. Anda tidak dapat mengatakan bahwa di sini saya memiliki fungsi yang menerima nilai tertentu, yang disebutkan secara apriori. Anda tidak bisa mengatakan bahwa saya memiliki nilai yang mengimplementasikan antarmuka, dan antarmuka ini memiliki iterator, misalnya.

Sergey: Kita bicara tentang C ++ yang mana? Tentang C ++ secara umum, C ++ masa depan, C ++, yang sekarang diterima sebagai standar?

Dmitry: Nah, jika dalam pro masa depan itu akan ...

Sergey: Di C ++ 20, ini sudah ada di sana. Anda sudah bisa mengatakan, Anda bahkan dapat mendeklarasikan diri Anda. Ini bukan antarmuka, tetapi, bagaimana mengatakannya dengan benar ... Secara umum, Anda dapat menyatakan bahwa tipe Anda harus memenuhi persyaratan ini dan itu. Misalnya, telah dimulai dan berakhir, yang mengembalikan iterator. Dan iterator adalah konsep yang disiapkan di perpustakaan standar. Dia mengatakan apa itu, jelaskan. Iterator juga berbeda. Secara umum, kami mencoba, kami membuatnya lebih nyaman bagi orang-orang.

Dmitry: Tampak bagi saya bahwa ini tumbuh dari kenyataan bahwa orang baru menyadari bahwa sulit untuk hidup tanpa konsep objek yang dapat diubah. Karena itu tidak jelas bagaimana menulis hal-hal umum. Ya, abstraksi nol biaya berarti bahwa kami tidak memiliki biaya untuk berjalan di sekitar v-table saat mencari ... Di. NET hanya ada metode tertentu, misalnya. Dan kami, untuk menemukannya, tentu saja, harus menghabiskan upaya, yang plus plus menolak. Tetapi dari sudut pandang kegunaan, hasil akhirnya tidak begitu baik, saya akan mengatakan.

Sergey: Tentu, harus ada keseimbangan. Anda tidak dapat memiliki semuanya sekaligus.

Anatoly: Ini membuat Anda bertanya-tanya berapa tahun telah berlalu. Bahasa-bahasa alternatif berkembang, dan di dalamnya hal-hal mendasar seperti itu muncul sejak awal. Sekarang mereka mengejar sesuatu yang lebih substansial dan menarik. Dan plus duduk selama sepuluh tahun dengan sintaksis yang sama tidak dimengerti, abstraksi yang tidak jelas, kruk yang tidak dapat dipahami dan kurang berkembang. Anda dapat menempatkan ini sebagai salah satu minusnya.

Sergey: Ayo, cepat! Apa artinya "kurang berkembang"?

Anda menyebutkan sebuah komite - C ++ juga memiliki komite ISO yang mengembangkannya. Ada perwakilan di sana, termasuk Microsoft, yang sangat tenggelam karena fakta bahwa "Anda tidak dapat melakukan ini, karena kami memiliki banyak warisan yang perlu kami dukung." Just C ++ adalah bahasa yang sudah dimiliki. Dan, tentu saja, dia berjalan dengan sangat hati-hati. Salah satu tugas utama (yang sudah dinyatakan oleh Straustrup saat membuat) adalah kompatibilitas dengan C. Tetapi sekarang C bahkan telah berevolusi cukup jauh, Anda harus menentukan C yang kompatibel dengan apa.

Dan menurut saya, sekarang C ++ berkembang dengan kecepatan yang luar biasa. Mengenai konsep dan sebagainya - pada kenyataannya, semuanya tumbuh, tentu saja, bukan dari iterabilitas. Bahkan, perkembangannya mengikuti apa yang juga dijelaskan oleh Alexander Stepanov - salah satu penulis dari apa yang sekarang kita sebut “pemrograman umum”, orang yang benar-benar menyeret templat, generik, dan seterusnya ke dalam C ++. Sejujurnya, saya tidak tahu seberapa banyak panitia terinspirasi oleh ide-ide ini, tetapi bagi saya sepertinya ada beberapa persimpangan dengan mereka.

Anatoly: Tampaknya semua metaclasses ini, iterator benar-benar inspirasi, yang sudah puluhan tahun lalu. Bahkan jika Anda mengambil metaprogramming, templates, macro - semua orang ini telah lama mengalami, mengerjakan sesuatu, dan ada banyak konsep yang lebih sederhana, jelas, dan dapat dimengerti. Dalam bahasa lain, ini semua dilakukan jutaan kali lebih baik dan lebih cepat, dengan keamanan jenis, kompilasi waktu pengecekan, dan sebagainya.

Sergey: Tunggu, Anda sudah berbicara tentang sesuatu yang tidak semua orang bersedia membayar. Saya tidak ingin program saya memeriksa sesuatu dalam waktu kompilasi tanpa sepengetahuan saya. Apakah kamu mengerti

Anatoly: Saya pikir semua ini dengan flag dapat dikonfigurasi. Anda mengatur tingkat optimasi, dan itu memeriksa Anda atau tidak. Ini bukan masalah.

Sergey: Seringkali Anda perlu mengendalikan semuanya dengan tangan Anda. Tahu persis apa yang sedang terjadi. Karena alat - yah, itu.

Dmitry: Ini bahkan bukan tentang alat. Di sini fakta bahwa bahasa seperti D dan Rust, katakan, katakan: baiklah, ya, ada hal seperti itu ketika Anda mengakses elemen array, Anda bisa memeriksanya, tetapi Anda tidak bisa memeriksanya. Dan mereka hanya memberikannya kepada pengguna, yaitu, Anda bisa mengatakan "tapi mari kita matikan cek array", "tapi mari kita hidupkan". Artinya, semacam kontrol dalam hal ini.

Sergey: Tidak jelas ketika Anda memiliki Tidak Aman dan Aman, seperti pada Rust, saya tidak melihat perbedaannya dengan C, misalnya, dalam kasus ini.

Anatoly: Perbedaannya adalah Anda dapat menulis dengan aman dan Anda dapat menulis dengan cepat. Dan di C Anda harus menulis yang berbahaya. Ya, mungkin cepat. Stabilitas terkadang lebih penting daripada kecepatan.

Dmitry: Sebenarnya, jika kita mulai menggali topik ini dengan bahasa baru, di C ++ ada hal-hal yang umumnya sangat sulit untuk disampaikan kepada orang-orang. Sebuah pertanyaan sederhana: apa ukuran int? Di sebagian besar bahasa, Anda tahu jawaban untuk pertanyaan ini. Anda mengatakan: int adalah 32 bit. Tapi Anda tidak tahu pro. Anda tahu ukuran pada komputer khusus Anda karena Anda mengingatnya, tetapi, sesungguhnya, Anda bahkan tidak ingin menggunakan tipe dasar karena mereka tidak deterministik. Dan hal-hal seperti itu membuat saya marah ketika ada satu set pendekatan warisan seperti int akan berbeda pada platform yang berbeda. Dan sekarang kita sudah mengerti bahwa ini tidak dapat dilakukan. Mengapa tidak melangkah lebih jauh dari ini dan entah bagaimana menyelesaikan masalah ini?

Sergey: Yah, itu yang memutuskan. Ada PMS , jenis yang dibutuhkan dengan panjang tetap. Sekarang perwakilan Rusia di komite menyeret int variabel panjang (well, sekali lagi, dengan abstraksi nol biaya).

Anatoly: Apakah saya ingat betul bahwa bahkan ada ukuran penunjuk yang tidak menentukan untuk suatu metode? Artinya, di bawah berbagai kompiler dan platform yang berbeda, petunjuknya berbeda?

Sergey: Secara alami, ini adalah arsitektur. Ketika Anda dekat dengan perangkat keras, bagaimana Anda bisa menjamin ukuran pointer, jika Anda menggunakan 8-bit, kemudian pada 64-bit?

Anatoly: Dan bagaimana kita bisa melakukan aritmatika pada pointer setelah itu? Ini gila.

Sergey: Maksud saya ? Baik, hati-hati.

Anatoly: Begitu . Pendekatannya jelas di mana-mana, dengan cermat mengendalikan segala sesuatu dengan pegangan.

Sergey: Ya, ya. Sekali lagi, pendekatan dikembangkan dalam standar C ++ modern ... Jika kita berbicara tentang pilihan, maka dalam plus modern, pada kenyataannya, ada pilihan apakah akan menggunakan pengumpul sampah. Hanya saja GC dibangun di sana di atas counter referensi.

Secara umum, dalam kata-kata Anda, kolega, saya, maaf, merasa bahwa Anda belum memperbarui pengetahuan Anda tentang plus modern untuk waktu yang lama.

Sekarang, orang-orang seperti Straustrup, yang merupakan bagian dari jajaran dewa plus, datang dengan banyak panggilan untuk mencari cara mengajar C ++ modern. Masalahnya adalah apa yang orang pikirkan dalam kategori C ++ 2003, dan mengajar dalam kategori yang sama. Dan sehubungan dengan ini ada proyek dan pendekatan baru yang menarik, ada kursus modern - katakanlah orang-orang dari Yandex telah membuat kursus yang luar biasa. Dan sekarang dalam plus itu dianggap perilaku buruk, misalnya, untuk menggunakan murni baru dan menghapus.

Dmitry: Mengenai komentar Anda tentang memperbarui pengetahuan ... Nuansanya adalah bahwa pendekatan saya, misalnya, adalah dengan menggunakan delta C ++ kecil, yang dijamin akan bekerja untuk saya dan dengan siapa saya menjadi "teman". Anda lihat, C ++ sangat luas. Ada metaprogramming template, dan semuanya akan baik-baik saja, ada banyak sihir, tetapi, sayangnya, sihir ini tidak dapat dibaca. Ini adalah kode di mana non-penulis tidak dapat mengetahuinya tanpa pengetahuan khusus, dalam arti kotak hitam. Dan ada banyak kotak hitam seperti itu di pro, area kegelapan yang tidak dapat dicerna ... Saya ingin, saya tidak tahu, opsi Anda untuk dapat diperkirakan, baik dan tanpa trik.

Contoh paling sederhana adalah berbicara tentang rentang ( rentang-v3 dan seluruh topik ini). Di satu sisi, semua ini hebat: ada hal-hal yang telah ada di C # selama beberapa tahun, memungkinkan, misalnya, untuk membuat kalender dengan transformasi apa pun dari koleksi standar. Di sisi lain, cara itu diterapkan dalam C ++ hanya tidak menyenangkan dibandingkan dengan C #: itu berat, tidak dapat dibaca.

Sergey: Ini bumbu. Sebaliknya, saya menyukainya. Seperti yang saya mengerti, Anda harus melaporkan Nibler dan presentasinya ...

Dmitry: Anda tahu, ketika operator "atau" digunakan untuk memfilter koleksi, saya langsung memiliki pertanyaan tentang ini. Baik C # dan Java melakukan semuanya melalui titik, melalui metode biasa.

Sergey: Dan menurut saya ini terinspirasi oleh Bash. Artinya, itu hanya pipa.

Dmitry: Ya, mungkin ini menjelaskan sesuatu dalam pendekatan ini.

Sergey: Ini menjelaskan banyak hal! Mari kita bicara tentang PowerShell, karena kita berbicara tentang Bash. Siapa yang melihat PowerShell?

Anatoly: Saya menulis di PowerShell, bahasa yang bagus. Tetapi sekali lagi, pipa harus dimasukkan ke tempatnya, di mana semua arsitektur diserap olehnya. Bukan di mana Anda perlu melakukan satu tindakan tunggal, dan sintaksinya buruk di sini.

Sergey: Dalam pipa jangkauan, itu sangat ...

Dmitry: Dalam kisaran mereka digunakan, menurut pendapat saya, untuk alasan berikut ... Saya akan mengatakan ini: jika C ++ memiliki metode ekstensi atau fungsi ekstensi, mereka akan menggunakannya, tentu saja. Karena hal yang paling alami jika Anda perlu mengurutkan koleksi adalah menulis "collection. Filter ()". Dan bukan "koleksi | lihat :: filter () ".

Anatoly: Saya juga mendapat kesan bahwa Anda ditembak di kaki selama 20 tahun, menabrak wajah, membenturkan kepala ke dinding, dan akhirnya berkata: "Nah, sekarang kami telah melakukan semuanya dengan indah di standar ke-20, sekarang mari kita ajarkan pro benar. " Ya, tidak ada yang mau mengajar mereka dengan benar! Artinya, itu adalah rasa sakit jangka panjang.

Sergey: Tolong jangan mengajar. Apa masalahnya? Tulis di C # - berdagang di atasnya, tulis tertanam. Saya tidak keberatan.

Anatoly: Nah, ada celah sempit di mana pro masih ada.

Sergey: Embedded adalah "ceruk sempit" ... Saat ini, melihat-lihat di dapur saya, saya melihat banyak komputer.

Dmitry: Setiap kali saya terbang dengan pesawat, saya berpikir: "Sial, saya berharap semua ini bisa ditulis dengan baik di sana."

Sergey: Ngomong-ngomong, ada terutama Ada, sejauh yang saya ingat.

Dmitry: Ada mendominasi di sana, ya.

Anatoly: Ngomong-ngomong, saya baru-baru ini menemukan artikel yang bagus di mana penulis dalam berbagai bahasa (sekitar 10) menulis driver tingkat rendah - driver jaringan untuk kartu Intel 10-gigabit. Dari C ke Swift, JS, Python, dan tentu saja C #. Jika kita melihat grafik ini, yang dia dapatkan, maka C # dalam jumlah besar (ketika biaya peluncuran diratakan) berjalan setara dengan C dan Rust.



Artinya, jika kita berbicara tentang kinerja, mungkin kesalahpahaman bahwa C # jauh lebih rendah di suatu tempat. Ada juga laporan funky oleh Federico Luis Scratched Metal , di mana ia menunjukkan bagaimana ia mengoptimalkan kode C # untuk profiler prosesor.

Sergey: Yah, itu mulai lagi. Masalahnya adalah bahwa ketika Anda mulai mengoptimalkan Java itu, bahwa C #, menjadi tidak jelas mengapa tidak menulis plus. Karena Anda membutuhkan pengetahuan khusus. Dan, seperti yang bagi saya, keunggulan bahasa seperti C # dan Java diratakan - bukan ambang masukan yang sangat tinggi. Sejauh yang saya mengerti, apa yang dibicarakan Dmitry: keterbacaan kode, banyak belajar, sulit menjelaskan beberapa konsep, dan sebagainya.

Anatoly: Saya bekerja 99% dari waktu saya menulis dalam "normal" C # - aman, stabil dan bekerja sepanjang waktu. Dan 1% dari waktu saya ingin menulis semacam kode tingkat rendah yang cepat. Dan C # ini memungkinkan saya juga. Tetapi alat utama saya masih stabil, dapat dibaca, tanpa kesalahan ...

Dmitry: Tolya, izinkan saya memberi Anda contoh sederhana: vektorisasi. Dengan vektorisasi dalam. NET, semuanya sangat buruk, terlepas dari kenyataan bahwa System.Numerics.Vektor perlahan digergaji. Dan apa akibatnya, bagi saya, misalnya? Untuk fakta bahwa jika Anda mencari-cari di pasar dan membeli perpustakaan matematika untuk .NET, itu tertulis di pro (dengan bungkus penuh). Karena dalam. NET praktis tidak ada akses ke akselerasi perangkat keras (AVX, dll.), Sekarang berada pada tahap embrionik.

Anatoly: Intrinsik dirilis dalam .NET Core 3 di mana Anda dapat langsung mengakses AVX. Mereka benar-benar masih dalam masa pertumbuhan, tetapi ada hal-hal mendasar, dan sisanya cukup mengharukan.

Dmitry: Anda mengerti, kami memiliki 2019 di halaman. Sebagai pengguna dari semua ini dipercepat baik matematika, saya tidak menunggu ini. Dan sebagai hasilnya, bagi saya, jika saya ingin cepat mempertimbangkan sesuatu, C # tidak lagi menjadi kandidat. Karena perpustakaan C ++ sudah ada. Mungkin waktu sudah hilang untuk ini.

Anatoly: Tampaknya bagi saya bahwa C # bergerak ke arah plus, ia mencoba untuk memenangkan pasar mereka. Namun plus tidak lagi bergerak kemana-mana.

Sergey: Dari mana ini berasal? Apa artinya "plus tidak ke mana-mana" artinya?

Anatoly: Ketika mereka memberi tahu saya pada 2019 bahwa akan ada iterator dalam standar, akan ada beberapa kemajuan tentang lambda, menurut saya ...

Sergey: Saya tidak tahu mengapa Anda berbicara tentang iterator dan lambda, saya tidak mengerti ke mana batu itu ...

Anatoly: Bukan tentang iterator, saya salah paham, maksud saya wadah yang dapat kita bahas sebelumnya. Dan sementara itu, kami mendapat pencocokan pola.

Sergey: Itu semua tergantung pada apakah perlu atau tidak. Kami sedang mendiskusikan pencocokan pola. Namun sejauh ini tidak ada argumen apakah itu diperlukan dalam pro.

Dmitry: Saya mendengar banyak komentar serupa dari plus yang mengatakan bahwa “meskipun sudah ada kehadiran yang jelas dari pendekatan ini atau itu dalam bahasa lain, itu sudah berhasil, orang-orang menyukainya dan membangun solusi di atasnya, kami masih tidak menginginkannya dalam pro karena itu bukan plus idiomatik. " Dan menurut saya Jawa jatuh ke lubang yang sama. Java berkata, "tidak ada teman, kami tidak akan memiliki delegasi." Dan di Jawa masih belum ada konsep delegasi, tetapi dalam. NET semua ini berfungsi dengan baik.

Sergey: Lihat, pro sangat sederhana. Sekali lagi, kembali ke panitia. Ada tip - ini adalah orang-orang yang sedang mengembangkan kompiler. Dan bagi mereka, kata-kata "abstraksi nol biaya" adalah apa yang harus dipandu oleh mereka. Dan kata "warisan", sayangnya.

Dmitry: Ya, abstraksi nol biaya adalah assembler. Jika kita menginginkan abstraksi nol biaya secara umum, kita perlu menulis semuanya dalam assembler.

Sergey: Tidak ada abstraksi.

Dmitry: Assembler adalah abstraksi atas kode biner. Ini hanya generasi kedua, bukan generasi ketiga.

Sergey: Jadi, tentang segala macam "hal-hal yang menyenangkan", ternyata tidak jelas bagaimana membuatnya bekerja dengan cepat.

Dmitry: Biarkan mereka bekerja lebih lambat. Gagasan dengan iterator asinkron, coroutine, semua ini - dalam. NET dengan C # kata kunci hasil tidak lagi tahu berapa banyak rilis bekerja dengan baik. Ya, mesin negara besar sedang dibangun di belakang layar, hanya sulap. Tapi async / menunggu juga membangun sihir, dan di iterator. Tetapi semua orang menggunakannya, dan itu benar-benar nyaman.

Sergey: Coroutines menambah plus, halo.

Dmitry: Ya, ya, kemajuan sedang dibuat. Tetapi coroutine muncul sekarang, bukan 10 tahun yang lalu.

Sergey: Sekali lagi. Nilai tambahnya lebih tua, dan menurut saya, kecepatan pengembangan turun dengan akumulasi basis kode. Jelas, itu semua tergantung pada apakah ada keinginan untuk mempertahankan dukungan Legacy. Bagi para profesional, ini adalah posisi berprinsip. Artinya, kode yang Anda tulis di tahun 80-an sekarang dikompilasi oleh kompiler modern.

Dmitry: Ya, tetapi Anda mengkompilasi kode yang Anda tulis dalam C # 1.0 dengan kompiler modern.

Sergey: Ini tidak benar. Di awal diskusi, saya mengatakan bahwa pembaruan tiba pada versi awal saya. NET, dan tiba-tiba semua program berhenti bekerja.

Dmitry: Mungkin API yang Anda gunakan baru saja berubah. Di sini Anda perlu memisahkan perpustakaan dan bahasa pemrograman.

Sergey: Saya tidak punya apa-apa, hanya C #. Saya masih muda, ini adalah tahun-tahun pertama.

Dmitry: Saya hanya ingat satu perubahan, di C # 4 - sedikit perubahan dalam perilaku foreach. Tentu saja, dalam versi 1.x semuanya bisa lebih bergejolak, tetapi sekarang kita jelas tidak berada dalam fase di mana seseorang tiba-tiba memecahkan sesuatu.

Anatoly: Yah, secara resmi Microsoft menganut posisi yang benar-benar memonitor kompatibilitas, mereka menguji versi baru pada sejumlah besar mesin dan basis kode. Mungkin Anda memiliki bug atau sesuatu seperti itu.

Dmitry: Secara umum, .NET juga memonitor kompatibilitas ke belakang, tetapi kecepatan kemajuan telah melonjak baik C ++ dan Java.

Sergey: Tampaknya bagi saya bahwa itu memainkan peran besar, bahwa pada awalnya semua ini didorong oleh satu perusahaan. Karena C ++ awalnya di komite - dan ini adalah politik, semua orang berusaha untuk mendorong keputusan mereka, dan ini seperti pertemuan Senat di Star Wars.

Dmitry: Jadi argumen Anda adalah bahwa kita semua adalah sandera komite yang didorong bukan oleh inovasi?

Sergey: Masalahnya adalah Anda tidak memilih solusi yang akan memuaskan semua orang. Alat ini didistribusikan secara luas sehingga digunakan oleh banyak perusahaan. Anda ingat coroutine yang sama: mengapa mereka menerima mereka terlambat? Karena Microsoft, tampaknya, tidak setuju dengan Google. Ada dua implementasi - saya tidak ingat siapa yang berada di belakang stackful dan siapa yang di belakang stackless, tetapi tidak bisa setuju. Karena kedua perusahaan besar, mereka memiliki basis kode besar yang sudah mengandung solusi, dan mereka menolak untuk menulis ulang.

Dmitry: Dari sudut pandang pembaca, orang akan merasa bahwa ia diludahi dari menara lonceng yang tinggi, karena ada kepentingan perusahaan, mereka terlibat dalam interlovers, dan semua ini tampaknya tidak menjadi perhatian Anda - pergi, antek, "biarkan mereka makan kue" .

Sergey: Justru sebaliknya. Panitia berusaha memilih agar orang biasa tidak harus menderita. Dan seringkali itu sulit.

Dmitry: Ya, saya dapat mengatakan pada diri saya sendiri bahwa saya tidak akan menderita jika biaya nol langsung ke suatu tempat, tetapi akan ada semacam peluang fleksibel untuk berjalan melalui pohon biner dan beralih dengan cara yang berbeda tanpa variabel waktu. yield, - - — , , , , - .

: , , , , - .

: , Boost .

: , . Boost , , , … - . std::string, , . size(), length(), : , - ? - , , . , . , , , . , , , - .

: , , , . ?

: , , «», .

: .

: embedded-, include, ?

: . embedded -.

, , - ? , , . ?

: . 150 . - , . .

: , !

: , Steam, , , 64 . , 150 ?

: , , .

: , -. ? , , , — , zero cost abstractions . -?

: , , , , ?

: , . , , .

: , , , . — , . , . , , . , . -. C.

: . «». : , . , , , . . , .

: , . . , . proposal. .

: , proposal. , « »: , STL , . , - , .

: STL . STL . , , STL — , , .

: , — , ? , greenfield. brownfield development, . — , . — . ?

: , . , , . , . , , . G++ , Clang . .

: , , , . « , A, B». , .NET, . , , , , , ?

: , , . , C++ 2.0. ++C++. , C.

: , . , , . , , , , #include #import - — . , . , , , , .

. , . , , , C# C++, .

: , , 10 . , , , , , , . « », . , .

C# , C++. , C# . , , . , , , , JIT' — , , - ( int). , , , , .

: , , , C# — . , , C++ . , . ( , ) — cutting edge. , UI- C++, , . C# — . C++ , .

, . , , , C++ , , , . , .

, C# Microsoft. , .NET Foundation, , , Microsoft. , .

---

C++ Russia DotNext . : ?