Apakah praktis untuk meninggalkan STL dalam pengembangan C ++? [Tutup]

Saya tahu di beberapa area (industri game, misalnya), STL tidak direkomendasikan. Jadi pertanyaan saya adalah: apakah benar-benar praktik yang baik untuk tidak menggunakan STL dalam beberapa kasus? Jika demikian, apa alasan terbesar untuk tidak menggunakan STL C ++ modern?

• Saya hanya bisa memikirkan satu alasan yang sahih dan itu sangat jarang: Waktu nyata yang sulit. Banyak hal di perpustakaan standar mengalokasikan memori secara internal dan itu tidak cukup deterministik untuk aplikasi real-time yang sulit, sehingga mereka harus dihindari. Aplikasi-aplikasi ini biasanya cukup sederhana, meskipun mereka membutuhkan waktu yang tidak proporsional untuk dikembangkan karena ulasan dan pengujian yang sangat ketat.

• Saya dapat memikirkan satu alasan yang tidak valid, tetapi sangat umum: Pengembang yang tidak memahami kompleksitas komputasi, menyalahgunakan STL dan kemudian menyalahkan perpustakaan.

  STL biasanya lebih cepat saat runtime daripada solusi C-style dengan callback pointer atau solusi berbasis polimorfisme dengan metode virtual ( lihat juga keynote Bjarne Stroustrup ini ). Namun ketika pengembang tidak memahami spesifikasi kompleksitas yang diberikan dan menyalahgunakan perpustakaan dengan membuat sesuatu seperti vektor vektor dari beberapa objek kompleks (dalam C ++ 11, itu tidak lagi menjadi masalah!), Menyebabkan masalah kinerja dan kemudian membela diri dengan "Anda lihat, vektor agak lambat", ini dapat menyebabkan persepsi bahwa perpustakaan standar lambat. Dan begitu manajer mendapatkan persepsi seperti itu, ia dapat hidup sangat lama di dalam organisasi.

• Jelas Anda tidak dapat menggunakan apa pun yang tidak didukung oleh platform yang Anda targetkan. Namun kami saat ini menargetkan empat platform seluler paling umum (Android, iOS, Bada, dan WinCE lama) dan menggunakan pustaka standar dan beberapa bagian Peningkatan pada semuanya.

  Banyak perpustakaan standar yang dulu tidak didukung oleh Microsoft di awal WinCE (IIRC iostreams hanya keluar dengan Visual Studio 2005), tetapi dimungkinkan untuk menggunakan STLport jauh sebelum itu sebagai gantinya. Dan Anda biasanya bisa mendapatkan itu untuk dikompilasi ke apa pun. Jadi saya akan menyebut alasan ini tidak valid juga.

  Selain itu, untuk waktu yang cukup lama itu bukan "STL", tetapi Perpustakaan Standar ANSI C ++. Itu didefinisikan oleh dokumen standar yang sama yang mendefinisikan bahasa itu sendiri. Apa pun yang tidak mendukungnya tidak benar-benar layak disebut C ++.

Saya menggunakan STL dan meningkatkan selama bertahun-tahun. Jika saya ingin meninggalkannya dan menggunakan alat khusus saya, motivasinya adalah:

1. Kompilasi pengurangan waktu (75%). Hanya dengan menyertakan iostreams dapat menambahkan 1 juta baris kode ke modul Anda. Ya header yang dikompilasi banyak membantu, tetapi masih memperlambat kompilasi dalam proyek-proyek besar. Dalam jangka panjang, ini menghabiskan banyak waktu bagi siapa pun yang mengerjakannya.
2. Performa. (25%) STL ditulis untuk bekerja secara umum, tetapi Anda dapat mengoptimalkan struktur agar bekerja persis seperti yang Anda inginkan. Misalnya, Anda mungkin memiliki struktur data dengan jutaan string pendek. Mungkin jauh lebih cepat untuk menggunakan kelas string khusus berdasarkan prinsip boost :: small_vector (vektor data lokal statis kecil, alokasi dinamis hanya untuk string yang lebih besar), perubahan semacam ini dapat membuat bagian-bagian penting dari kode bekerja berkali-kali lebih cepat.

Ada satu alasan kuat untuk tidak menggunakan pustaka templat standar C ++: Salah satu platform target Anda tidak memiliki implementasi yang sepenuhnya sesuai (atau tidak ada implementasi sama sekali) dan Anda tahu bahwa itu tidak akan mendapatkan satu dalam tahun-tahun berikutnya.

Saya tidak tahu tentang kerumitan (efisiensi implementasi) tetapi saya menggunakan kontainer Qt dan string secara ekstensif daripada yang std dan mereka bekerja dengan baik. Saya juga menemukan implementasi set dan daftar Qt lebih mudah digunakan.

Jadi, praktis untuk meninggalkan STL jika Anda dapat menggunakan perpustakaan lain yang sesuai dengan kebutuhan Anda.

Patrick telah menyebutkan alasan untuk tidak menggunakan seluruh STL, yaitu bahwa platform Anda tidak memilikinya.

Secara keseluruhan, saya pikir pertanyaannya tidak ada gunanya. Ini sebagian besar bukan keputusan semua atau tidak sama sekali, tetapi salah satu memilih dan memilih. Anda mungkin memutuskan untuk pergi dengan wadah dan algoritma, tetapi memutuskan untuk menggunakan sesuatu di luar Std Lib untuk string dan i / o.

Ini tidak praktis, kecuali ada alasan kuat untuk melakukannya. Beberapa alasan seperti itu yang dapat saya pikirkan mencakup hanya sebagian atau kurang implementasi STL (atau bagian lain dari perpustakaan standar) atau keterbatasan sumber daya (memori, kecepatan CPU, penyimpanan, ...) yang harus Anda jalani dengan menggulung alat Anda sendiri yang mematuhi apa yang perlu Anda capai.

Dalam industri game sebagian besar (bahkan lebih kecil sampai batas tertentu) studio memiliki perpustakaan internal dan implementasi dari banyak bagian perpustakaan standar yang sangat disesuaikan untuk platform target dan dalam beberapa kasus menargetkan engnie atau bahkan game itu sendiri. Sederhananya ketika mengembangkan game untuk konsol, perangkat keras sangat dibatasi oleh standar saat ini. Ada ribuan dan ribuan garis perakitan kerajinan tangan karena suatu alasan. Sangat penting untuk meminimalkan semua jenis jejak kaki sumber daya dalam kode Anda sehingga permainan berjalan lebih cepat yang memungkinkan lebih banyak konten di dunia game (atau dunia yang lebih besar misalnya) yang diharapkan menghasilkan produk yang lebih baik.

"Setiap permainan yang berhasil dimulai dengan meluncurkan implementasi daftar tertaut milik Anda sendiri."