Libelektra: pembuatan kode untuk kesalahan

Secara pribadi, saya lebih suka opsi 1. Kode kesalahan seharusnya jarang berubah, yang membuat upaya tambahan untuk menulis kode C secara manual dan menjaga agar bahasa lain tetap sinkron dapat diabaikan. Upaya awal juga harus lebih sedikit dibandingkan dengan menyiapkan segala bentuk generasi otomatis.

Mengapa tidak opsi 2?

Template kumis harus diberikan dengan data input entah bagaimana. Entah kita harus menggunakan executable khusus yang dikompilasi pada waktu build. Dalam hal ini kami hanya akan menyingkirkan std::cout << ... dalam kode C++, tetapi tidak banyak lagi yang akan berubah. Pilihan lainnya adalah dengan menggunakan executable kumis default, yang merupakan skrip Ruby dan oleh karena itu membutuhkan Ruby untuk diinstal.

Juga kdb gen tidak dapat digunakan kembali, karena itu akan memerlukan kompilasi kdb terlebih dahulu, yang membutuhkan kdberrors.h .

Mengapa tidak opsi 3?

Membuat kode C mungkin berhasil di CMake, tetapi bahasa yang lebih kompleks mungkin mengalami masalah saat menggunakan CMake.

Jika kita memutuskan untuk menggunakan beberapa bentuk pembuatan kode, kita seharusnya hanya menghasilkan bagian yang benar-benar perlu dibuat. Misalnya kdberrors.h berisi banyak kode yang benar-benar statis dan tidak bergantung pada kesalahan yang sebenarnya kita miliki. Kode ini tidak boleh dibuat, kita harus #include dari file statis.

Saya juga lebih suka opsi 1 karena kode kesalahan yang stabil. Menambahkan pembuatan kode juga menambah kerumitan yang tidak perlu pada keseluruhan kode yang lagi-lagi rawan kesalahan.

@kodebach terima kasih atas penjelasan Anda tentang opsi 2

Saya pikir cukup jelas bahwa kami memilih opsi 1, @Piankero bisakah Anda menuliskan keputusannya?

Untuk binding artinya tidak banyak perubahan.

Apa yang akan lebih bagus jika kita memiliki tutorial penulisan yang mengikat, yang menjelaskan:

1. bagian mana dari ikatan Elektra yang masuk akal (aplikasi, plugin, alat, ...)
2. cara mengintegrasikan binding ke CMake (jika mungkin dan berguna)
3. bagian binding mana yang dapat dan harus berbeda untuk setiap bahasa. Ini termasuk:
   
   
   
   • iterator
   
   
   • konversi ke tipe asli (string, int, ...)
   
   
   • kelebihan beban operator (jika tersedia)
   
   
   • integrasi bahasa pemrograman lainnya (aliran, kode hash, identitas, ...)
   
   
   • mengembalikan kesalahan dari fungsi kdb (tentang apa masalah ini)
   
   

Saya harap kita dapat memperluas tutorial ini untuk situasi berbeda yang kita lihat dalam bahasa yang berbeda. @Piankero dapatkah Anda mulai menulis tutorial, khususnya bagian penanganan kesalahan (cara menerapkan pewarisan, ...)

Tutorial: #2875
Keputusan Desain: #2872