Mengapa hanya ada sedikit penerjemah C++

Silakan lihat komentar untuk pertanyaan, dengan bling (ide bagus tentang C++/CLI), dan saya sendiri.

Faktanya adalah: CINT bukan juru bahasa C++. CINT bukan penerjemah C++. Hal ini dinyatakan dengan jelas di sini:

CINT - Wikipedia

en.wikipedia.org

Bahasanya adalah bahasa yang disederhanakan berdasarkan C dan C++.

Lihat juga: http://root.cern.ch/drupal/content/cling[^].

Bagaimana dengan satu alternatif yang disebutkan dalam artikel Wikipedia yang dirujuk di atas, “Ch”? Ini bukan penerjemah C++, ini adalah penerjemah dari beberapa bahasa khusus:
http://en.wikipedia.org/wiki/Ch_%28computer_programming%29[^],

Ch -- an embeddable C/C++ interpreter, C and C++ scripting language

www.softintegration.com

Ada yang lain? “Pike”, juga hanya berdasarkan C dan C++ (Wikipedia bahkan mengatakan “dipengaruhi oleh”):
http://en.wikipedia.org/wiki/Pike_%28programming_lingual%29[^],

Home

pike.roxen.org

Mengenai bahasa C++ “asli”, saya yakin beberapa orang tidak cocok untuk seorang juru bahasa; topiknya terlalu rumit untuk dibahas dalam pertimbangan saya a Cepat Pertanyaan. Saya tidak dapat membuktikannya di sini dan saya tidak 100% yakin, karena cenderung berpikir hal itu mungkin untuk dibuktikan. Saya akan sangat terkejut jika seseorang membuktikan bahwa saya salah.

Mengutip:

Saya pribadi hanya mengetahui 1 juru bahasa C++, yang digunakan oleh Root (CINT, dikembangkan di CERN). Itu membuat saya bertanya-tanya mengapa jumlahnya sangat sedikit, dan jawaban yang jelas adalah bahwa C++ adalah bahasa yang sangat kompleks untuk diurai. Tidak ada orang waras yang mau repot-repot menulis parser C++ dari awal…

Ada beberapa pertanyaan penting di sini: Apa tujuan Anda dan mengapa juru bahasa C/C++ menjadi solusi terbaik (atau setidaknya cukup baik) untuk masalah tersebut? “Apa tujuanmu?” dan “Mengapa X merupakan solusi yang baik?” umumnya merupakan pertanyaan pertama yang sangat baik untuk ditanyakan sebelum membuang waktu yang berharga untuk menerapkan solusi.

C/C++ tidak praktis sebagai bahasa interpretasi berbasis konsol karena berbagai alasan dan orang biasanya tidak suka membuang waktu untuk mengimplementasikan alat yang tidak praktis (yah, mungkin mereka yang memiliki banyak waktu untuk bersenang-senang dan belajar dan/atau mereka yang tidak dapat meramalkan aspek yang tidak praktis).

Mengimplementasikan penerjemah untuk bahasa dinamis (seperti python) dengan variabel yang diketik secara dinamis dan “fungsi yang terhubung secara dinamis” jauh lebih mudah dan lebih sedikit rawan kesalahan dibandingkan melakukan hal yang sama dengan C/C++. Menulis keseluruhan parser, compiler, interpreter untuk bahasa dinamis sederhana cukup mudah dan cepat. Penerjemah itu sendiri tidak harus berkinerja tinggi karena biasanya hanya digunakan untuk mengeksekusi logika tingkat tinggi, kode lem. Jika ada sesuatu yang penting bagi kinerja maka Anda dapat mengimplementasikannya sebagai modul C/C++ asli untuk penerjemah Anda dan mengikatnya ke bahasa yang ditafsirkan secara dinamis. Menurut pendapat saya Anda belum benar-benar memikirkan masalah yang akan muncul dengan interpreter C/C++. Saya bisa menulis novel tentang mereka. Berikut masalah paling menarik yang cukup besar:

C/C++ memerlukan deklarasi forward. Dalam bahasa tafsir praktis tidak ada deklarasi maju dan tidak ada deklarasi/definisi terpisah. Namun ini hanyalah sebagian kecil dari masalah yang lebih serius: C/C++ secara tidak praktis digunakan sebagai bahasa interpretasi. Ini adalah serangkaian masalah yang melibatkan masalah desain bahasa dan masalah kegunaan praktis sebagai bahasa yang ditafsirkan. Dengan python saya dapat dengan mudah mendefinisikan fungsi X yang memanggil fungsi Y yang tidak ada dan saya diizinkan untuk mendefinisikan fungsi Y ini nanti. Kemudian saya dapat mengeksekusi X. Nanti jika mau, saya dapat sepenuhnya mengubah definisi Y (mungkin dengan beberapa parameter yang diinisialisasi default baru agar kompatibel dengan definisi sebelumnya) dan eksekusi X lainnya segera menggunakan definisi Y yang baru. Saya dapat menjalankan X meskipun ia memanggil fungsi Z yang belum ditentukan dan ini tidak menjadi masalah jika eksekusi X dengan parameter masukan sebenarnya tidak benar-benar berjalan ke cabang yang akan memanggil Z. Dalam a Penerjemah C++ apa yang terjadi jika saya mengubah definisi templat yang sangat mendasar (misalnya: array dinamis) yang digunakan oleh banyak fungsi yang telah ditentukan sebelumnya (misalnya sebagai fungsi sebaris)? Bagaimana Anda mengetahui blok kode mana yang perlu dikompilasi ulang di dalam penerjemah Anda untuk menggunakan fungsi inline yang baru? Apa yang terjadi jika kompilasi ulang beberapa fungsi ini gagal dengan definisi baru? Anda tidak memiliki masalah serius seperti ini dengan bahasa dinamis seperti python. Berurusan dengan skenario seperti itu dalam penerjemah non-dinamis akan menjadi masalah besar, dan ini hanyalah dua masalah “sederhana/mendasar”, ini hanyalah puncak gunung es. Saya telah memprogram C/C++ selama lebih dari satu dekade dan tidak pernah merasa membutuhkan juru bahasa C/C++.

Mengutip:

Namun, ada parser C++ di luar sana sebagai bagian dari kompiler, beberapa di antaranya bersifat open source. Terlintas dalam benak saya bahwa ada kemungkinan untuk menafsirkan kode Majelis yang dikeluarkan oleh parser saat bepergian. Ini akan seperti kompiler JIT yang mengeluarkan bytecode untuk ditafsirkan oleh mesin virtual. Satu masalah yang terlintas dalam pikiran adalah penggunaan file sumber berbeda yang jika tidak maka akan menyebabkan beberapa file objek yang perlu dihubungkan. Ini memang sebuah batasan, tapi bukan batasan yang terlalu serius jika Anda bertanya kepada saya.

Saya mulai menulis jawaban tetapi menjadi terlalu panjang dan rumit karena menganalisis masalah Anda dalam banyak bagian yang berbeda. Sebaliknya saya tulis di sini hanya beberapa kesimpulan saya.

Anda harus menjawab pertanyaan yang saya posting di paragraf sebelumnya. Dari pertanyaan Anda, saya pikir mungkin tujuan Anda hanyalah menciptakan A Penerjemah C++ dengan jumlah pekerjaan paling sedikit yang diinvestasikan – Saya berasumsi ini karena Anda ingin menggunakan kembali barang-barang (unit kompilasi, file objek) dari kompiler yang ada. Masalah saya dengan hal ini adalah bahwa orang melakukan sesuatu dengan “pekerjaan paling sedikit yang diinvestasikan” ketika mereka harus melakukan sesuatu yang tidak mereka sukai. Sebaliknya jika mereka melakukan sesuatu hanya untuk bersenang-senang sebagai hobi atau dengan tujuan tertentu maka mereka biasanya tidak keberatan melakukan banyak pekerjaan. Dalam kasus juru bahasa C/C++, semua solusi tampaknya melibatkan banyak pekerjaan.

Bergantung pada kompiler dan pengaturan kompiler, file objek mungkin berisi sesuatu selain yang Anda butuhkan. Mereka tidak terstandarisasi dan bahkan kompiler yang sama dapat memasukkan sampah yang sama sekali tidak berguna ke dalamnya dengan beberapa pengaturan (seperti LTCG). IMO akan lebih praktis untuk menulis backend untuk memancarkan apa yang Anda butuhkan daripada mencoba menguraikannya dari file objek.

Alasan spekulatif saya: Tampaknya tidak ada seorang pun yang mempunyai kebutuhan dibandingkan dengan upaya untuk melakukannya. Yaitu Anda mungkin bisa membangun Menara Eiffel di taman Anda, dengan asumsi Anda memiliki ruang, bahan, orang, tanah yang cukup bagus, dll. dan Anda dapat melakukannya untuk kesenangan Anda sendiri. 😉

Perbedaan dari C ke C++ adalah seperti yang dinyatakan dalam standar C++:

Selain fasilitas yang disediakan oleh C, C++ menyediakan tambahan tipe data, kelas, templat, pengecualian, namespace, kelebihan operator, kelebihan nama fungsi, referensi, operator manajemen penyimpanan gratis, dan fasilitas perpustakaan tambahan.

Jika menggunakan C++11, Anda dapat menambahkan ekspresi lambda dan beberapa bagian lainnya, semuanya terutama gula sintaksis dalam arti bahwa mereka mengabstraksi sesuatu yang sebagian besar terkait dengan parser dan juga dapat dilakukan (jika tidak membosankan) dengan cara lain.

Apa hasil item runtime dari penguraian fitur di atas
– tipe data tambahan: beberapa tipe char/numerik bawaan lainnya
– kelas: fungsi instance yang diperluas dengan this parameter
– class: pewarisan dengan kelas dasar sebagai sub objek dari kelas turunan
– kelas: pemanggilan fungsi implisit khusus (ctor, dtor, dll.)
– class: vtable untuk pemanggilan fungsi virtual
– kelas: urutan definisi (kebanyakan) tidak menjadi masalah di kelas – hanya pencarian nama yang terpengaruh
– templat: kelas atau fungsi yang dihasilkan berdasarkan tipe atau nilai integral konstan
– pengecualian: aliran kontrol tambahan dan terutama kode pembukuan pembersihan
– namespace: “gula sintaksis” (tipe, objek, fungsi yang unik dapat ditentukan dan dipanggil)
– kelebihan beban: “gula sintaksis” (parser membuat panggilan ke fungsi yang benar)
– referensi: “gula sintaksis”, menghasilkan pointer atau tidak ada kode runtime sama sekali
– baru/hapus: memori tingkat rendah malloc/gratis plus panggilan ctor/dtor
– perpustakaan: kumpulan item berdasarkan fitur bahasa
– ekspresi lambda: “gula sintaksis” (kelas fungsi implisit)
– …

Ada banyak masalah detail yang harus diatasi, tetapi secara teknis ini bisa dianggap sebagai masalah C yang lebih luas.

Jadi, jika Anda memiliki frontend C++ yang berhasil diterjemahkan ke dalam C yang secara fungsional setara, maka Anda telah sampai pada level CINT. Masalah seperti banyak file dan perpustakaan referensi serta file objek tidak hanya terjadi pada C++ tetapi merupakan fakta umum pada semua bahasa C*. Jadi, Anda dapat menggunakan kembali konsep penerjemah bahasa tersebut (CINT?).

Namun sekali lagi, pembenaran upaya tersebut sangat bergantung pada “keuntungan” yang diharapkan.

Bersulang
Dan saya

Karena C++ adalah bahasa pemrograman yang masif. Ini terlalu rumit. Penerjemah dibuat untuk bahasa seperti Python, JavaScript, tidak hanya sederhana, tetapi juga dimaksudkan untuk ditafsirkan, juga dinamis. Implementasi Python pertama adalah seorang juru bahasa; bukan kompiler. Bukan hanya ini alasannya. Sudah diketahui bahwa C++ lebih cepat daripada bahasa yang ditafsirkan ketika “dikompilasi”. Namun Anda tidak selalu bisa mengharapkan hal yang sama dari juru bahasa C++. C++ peka terhadap konteks; C++ sangat besar; C++ berisi obat generik. Dengan demikian, kompleksitas bahasa berkontribusi pada lambatnya pemrosesan kode sumber. Misalnya, Lihat kecepatan kompilasi C++. Apa yang akan terjadi jika Anda menafsirkan sumbernya? Meskipun demikian, program klasik “halo dunia” mungkin tidak memakan waktu lama. Tapi pikirkan sebuah program dengan banyak penggunaan teknik generik?

Namun masih ada beberapa penafsir seperti CINT, Ch. Lihat halaman berikut:

Attention Required! | Cloudflare

stackoverflow.com

Sulit untuk benar-benar “menyelesaikan” pertanyaan ini – mungkin lebih baik di forum, tapi inilah 2c saya.

Definisi bahasa tidak menghalangi pembuatan penerjemah, tetapi C++ benar-benar dirancang sebagai bahasa tingkat rendah yang dapat digunakan untuk kode yang sangat efisien. Bahasanya sangat kompleks, tetapi bukan tidak mungkin untuk diurai (AFAIK sangat memerlukan parser GLR atau parser tulisan tangan). Meskipun demikian, sebagian besar keunggulan C++ berasal dari fakta bahwa ia dapat digunakan untuk kode yang efisien, yang berjalan dekat dengan mesin. Interpreter biasanya digunakan untuk tugas tingkat tinggi, di mana iterasi cepat selama pengembangan lebih penting daripada kecepatan eksekusi.

Singkatnya, itu akan menjadi pekerjaan yang sangat berat, dan akan berlari seperti seekor anjing.