Bisakah pustaka C ++ 11 yang dikompilasi (lib, dll, dll.) Dihubungkan di kompiler C ++ yang lebih lama?

12

Bisakah kompiler C ++ yang lebih lama (mis. VS2008 dan gcc3.4) terhubung dengan perpustakaan eksternal yang ditulis dalam C ++ 11?

Pikiran saya adalah bahwa file C ++ 11 .lib hanya kode byte pada tahap ini, dan seharusnya tidak mengganggu kompiler yang lebih tua bagaimana itu dihasilkan, asalkan itu entah bagaimana diselesaikan dan dipanggil.

Saya sedang mengembangkan perpustakaan kecil yang APInya masih harus mendukung pengguna C ++ 03. Jadi, melihat ke depan, saya bertanya-tanya apakah boleh menerapkan perpustakaan saya menggunakan fitur bermanfaat seperti std::unique_ptrdan semacamnya, atau haruskah saya tetap menggunakannya boost::?

c++ c++11

— Konafa
sumber

10

Asalkan pustaka Anda hanya menggunakan C ++ 11 dalam implementasinya dan tidak mengekspos fasilitas atau tipe C ++ 11 secara publik, dan terutama jika Anda menggunakan tautan statis, maka ya, ini mungkin dan bahkan standar.

Pertimbangkan kasus umum di mana perpustakaan memperlihatkan antarmuka tingkat-C (agar dapat digunakan oleh berbagai klien terluas) tetapi yang diterapkan secara internal di C ++. Klien yang menautkan ke perpustakaan seperti itu hanya perlu khawatir tentang API biner publik (fungsi yang diekspor), yang akan Anda batasi menjadi C / C ++ lawas untuk kompatibilitas maksimum. Program Java dapat menautkan ke API tingkat-C yang diterapkan secara internal di C ++. Ini tidak berarti bahwa Java perlu "mendukung C ++". Demikian pula, klien C / C ++ gaya lama dapat menautkan ke API level C atau C ++ - level yang secara internal menggunakan beberapa versi lebih baru dari lib C ++ atau lib lainnya. Dua hal terpisah: apa yang diperlukan untuk menautkan ke antarmuka perpustakaan, dan apa yang ditautkan oleh perpustakaan itu sendiri (atau menarik secara statis).

Anda tidak membiarkan klien perpustakaan Anda bergantung pada implementasi Anda.

Jika Anda dapat menautkan dependensi Anda secara statis (C ++ 11 atau apa pun) ke perpustakaan Anda, ini bersih dan mandiri. Perpustakaan adalah kotak hitam sejati: tidak ada tapi bytecode. Tetapi bahkan jika pustaka Anda menautkan ke dependensi Anda melalui tautan "implisit dinamis" (jangan dikacaukan dengan jenis LoadLibrary / GetProcAddress yang jelas dan metode serupa pada * nix dan OS X), klien lama harus tetap dapat menautkan ke pustaka itu antarmuka publik, bahkan jika mereka tidak dapat menautkan ke perpustakaan tempat perpustakaan bergantung .

— Jevlin
sumber

1

Bagus! Itulah tepatnya yang saya harapkan. Saya tidak bermaksud menggunakan C ++ 11 secara luas, tetapi senang mengetahui bahwa saya bisa memunculkan satu atau dua fungsi lambda dalam implementasi tersembunyi saya saat nyaman. Analogi C dan Java masuk akal. Terima kasih.

— Konafa

4

Kedengarannya seperti Anda ingin menulis pustaka baru untuk digunakan orang lain, dan bahwa Anda ingin menggunakan C + 11 sebagai bahasa implementasi Anda. Ada beberapa masalah yang perlu dipertimbangkan:

dengan memperkenalkan versi baru C ++ Anda akan memperkenalkan perlunya menyebarkan pustaka runtime C ++ baru dengan pustaka Anda, apakah itu OK?
Anda tidak boleh menggunakan tipe C + 11 baru di antarmuka publik Anda, jika tidak mereka tidak akan dapat menyebutnya.
Secara umum, Anda harus menghindari tipe kompleks, seperti unique_ptr, bahkan vektor, dll. Kecuali jika Anda mendistribusikan perpustakaan Anda sebagai kode sumber, tata letak objek di perpustakaan Anda mungkin berbeda dari tata letak dalam kode klien. Tetap dengan tipe sederhana yang tidak memiliki risiko variasi tata letak objek.

— Phillip Ngan
sumber