Transisi ke Boost-1.65.1 dan bug yang muncul

Tahun lalu (hampir satu tahun telah berlalu) namun kami beralih ke versi baru Boost-1.65.1, dan di bawah tenda Anda akan menemukan tiga bug pendorong yang kami temui. Penting juga untuk menyebutkan bahwa sebelum itu, boost -1.62.1 digunakan dalam perangkat lunak kami, karena beberapa bug muncul dalam boost lebih awal dari versi 1.65.1

Proyek kami memiliki tim integrasi khusus, yang tugas utamanya adalah memigrasikan semua perangkat lunak ke versi baru perpustakaan, Visual Studio, versi baru komponen tingkat rendah (dasar, tempat sebagian besar komponen lainnya bergantung), dll. Tim integrasi juga bertanggung jawab untuk menghilangkan semua masalah yang muncul, secara alami dengan bantuan pemelihara komponen, jika perlu. Jadi, bug yang saya ingat terutama.

Bug dalam boost :: filesystem

Bug ini muncul cukup cepat. Tes mulai macet dengan "pelanggaran akses" ketika mencari path lengkap ke nama file yang diberikan. Fungsi membuat panggilan untuk meningkatkan :: filesystem :: ada, dan program macet. Menjalankan beberapa tes lagi, beberapa kasus serupa diketahui, sementara dalam semua kasus panggilan untuk meningkatkan :: filesystem :: ada dibuat untuk variabel global. Rupanya, ada sesuatu yang berubah dalam variabel boost seumur hidup. Tiket untuk bug yang terdeteksi sangat mudah untuk mencari tiket bug di boost :: filesystem :: ada

Ternyata bug ini mulai meningkat, dimulai dengan versi 1.64. Sebenarnya, masalahnya ada di panggilan make_permissions (digunakan di filesystem :: ada). Di 1.64, implementasi make_permissions telah diubah dan sekarang menggunakan variabel global, yang berarti bahwa ketika upaya dilakukan untuk memanggil filesystem :: ada saat menginisialisasi variabel global atau objek, variabel global yang digunakan dalam make_permissions mungkin belum diinisialisasi. Oleh karena itu, upaya untuk mengakses variabel yang tidak ditentukan melempar pengecualian.

Bug dalam boost :: python

Dalam tes menggunakan boost :: python, sesuatu yang aneh ditemukan. Saat Anda melakukan panggilan sepele untuk eval () untuk literal (misalnya, "40 + 2"), semua aturan. Dan jika Anda mendefinisikan variabel dan kemudian menggunakannya dalam ekspresi, kami mendapatkan pesan bahwa perhitungan menggunakan variabel yang tidak ditentukan (ERROR: [nama] tidak didefinisikan). Untuk mengatasi masalah ini, saya menghabiskan lebih banyak waktu. Saya tidak dapat menemukan tiket untuk masalah ini di pelacak pendorong, jadi saya harus meminta bantuan dari tim komponen ini. Informasi tentang bug dengan cepat ditemukan di github .

Kebetulan bahwa dalam implementasi eval, objek global dan lokal tidak digunakan. Berharap Semoga beruntung dalam menemukan perbaikan tanpa mengkompilasi ulang kode sumber, tim mengambil cuti :)

boost :: numpy

Ini adalah bagian yang paling tidak kusukai. boost :: python :: numeric telah dihapus dan sekarang boost :: python :: numpy telah muncul sebagai alternatif. Tetapi kode yang menggunakan numerik harus didesain ulang cukup banyak, karena intinya bukan hanya untuk mengubah nama namespace, tetapi juga untuk mengimplementasikan objek.

Selain itu, ada informasi yang salah di header dorongan yang menyesatkan saya.
Menurut komentar di sumber, panggilan import_array () sudah dibuat di numpy :: initialize ():

namespace boost { namespace python { namespace numpy { /** * @brief Initialize the Numpy C-API * * This must be called before using anything in boost.numpy; * It should probably be the first line inside BOOST_PYTHON_MODULE. * * @internal This just calls the Numpy C-API functions "import_array()" * and "import_ufunc()", and then calls * dtype::register_scalar_converters(). */ BOOST_NUMPY_DECL void initialize(bool register_scalar_converters=true); }}} // namespace boost::python::numpy 

Tetapi pada kenyataannya, ternyata, import_array () diperlukan.

Selain itu, ada masalah dengan pengujian perubahan, karena potongan kode dengan numpy (sebelumnya dengan boost :: python :: numeric) tidak tercakup sama sekali oleh tes, dan kode itu sendiri juga digunakan dalam komponen lain. Oleh karena itu, masalah diidentifikasi hanya ketika menguji komponen yang sesuai. Tim integrasi tidak diharuskan untuk menulis tes untuk komponen, dan situasi ini adalah penghilangan tim itu sendiri. Wow, saya cukup banyak mendengar dari mereka sehingga saya memecahkan kode mereka. Tetapi setelah tim menggerutu, mereka akhirnya menutupi kode mereka dengan tes. Namun, kebencian tetap (selama migrasi berikutnya, tim tidak ingin memberikan akses ke komponen mereka kepada rekan saya, menyebutkan bahwa terakhir kali kami memecahkan kode untuk mereka. Sasha, soryan! Tetapi setelah tiga hari negosiasi mereka menyerah).

Kesimpulan

Setelah pekerjaan selesai, saya dapat mencatat plus untuk diri saya sendiri, karena dorongan belum pernah digunakan sebelumnya (terutama std), jadi banyak yang bisa ditekankan dari migrasi. Ini lucu, tetapi faktanya, setelah alasan seperti itu, untuk beberapa alasan Anda default untuk menjadi "ahli pendorong" bagi banyak rekan, dan, rekonsiliasi, Anda akan ditanyai tentang hal itu untuk beberapa waktu lagi.

Omong-omong, dalam beberapa tahun terakhir, banyak perusahaan mulai secara aktif menyingkirkan dorongan dan mengganti perpustakaan std jika memungkinkan, atau sesuatu yang lain tanpa adanya fitur di perpustakaan standar. Dan kami juga tidak berdiri di pinggir. Prosesnya sudah dimulai, tetapi belum selesai, masih banyak pekerjaan.