Mengapa ada begitu banyak kelas string di hadapan std :: string?

Sepertinya saya bahwa banyak perpustakaan C ++ yang lebih besar akhirnya menciptakan tipe string mereka sendiri. Dalam kode klien Anda juga harus menggunakan satu dari perpustakaan ( QString, CString, fbstringdll, saya yakin siapa pun dapat beberapa nama) atau tetap mengkonversi antara tipe standar dan satu penggunaan perpustakaan (yang sebagian besar waktu melibatkan setidaknya satu salinan).

Jadi, adakah kesalahan atau kekeliruan tertentu std::string(seperti auto_ptrsemantik yang buruk)? Apakah sudah diubah di C ++ 11?

Sebagian besar pustaka C ++ yang lebih besar telah dimulai sebelum std::stringdistandarisasi. Lainnya termasuk fitur tambahan yang terlambat standar, atau masih tidak standar, seperti dukungan untuk UTF-8 dan konversi antara pengkodean.

Jika perpustakaan itu diimplementasikan hari ini, mereka mungkin akan memilih untuk menulis fungsi dan iterator yang beroperasi pada std::stringinstance.

String adalah rasa malu besar C ++.

Untuk 15 tahun pertama Anda tidak menyediakan kelas string sama sekali - memaksa setiap kompiler pada setiap platform dan setiap pengguna untuk membuat sendiri.

Kemudian Anda membuat sesuatu yang bingung apakah itu seharusnya merupakan manipulasi string penuh API atau hanya wadah STL char, dengan beberapa algoritma yang menduplikasi yang ada di std :: Vector atau berbeda.

Di mana operasi string yang jelas seperti replace () atau mid () melibatkan kekacauan iterator sehingga Anda perlu memperkenalkan kata kunci 'otomatis' baru untuk menjaga pernyataan itu tetap pada satu halaman dan membuat kebanyakan orang menyerah pada seluruh bahasa .

Dan kemudian Anda memiliki unicode 'support' dan std :: wstring yang hanya arghh .....

<Bantuan> terima kasih - Saya merasa jauh lebih baik sekarang.

Sebenarnya ... ada beberapa masalah dengan std::string, dan ya itu menjadi sedikit lebih baik di C ++ 11, tapi jangan maju dulu.

QStringdan CStringmerupakan bagian dari pustaka lama , oleh karena itu pustaka ada sebelum C ++ distandarisasi (seperti SGI STL). Karena itu mereka harus membuat kelas.

fbstringmengatasi masalah kinerja yang sangat spesifik. Standar ini menetapkan antarmuka dan kompleksitas algoritmik yang menjamin minima, namun Standar Kualitas Implementasi merinci apakah ini cepat atau tidak. fbstringmemiliki pengoptimalan spesifik (terkait penyimpanan, atau lebih cepat findmisalnya).

Kekhawatiran lain yang tidak ditimbulkan di sini (en vrac):

• di C ++ 03 tidak wajib bahwa penyimpanan berdekatan, membuat interoperabilitas dengan C berpotensi sulit. C ++ 11 memperbaiki ini.
• std::string adalah pengkodean yang tidak disadari, dan tidak memiliki kode khusus untuk UTF-8, mudah untuk menyimpan string UTF-8 di dalamnya dan merusaknya secara tidak sengaja
• std::stringantarmuka membengkak , banyak metode bisa diimplementasikan sebagai fungsi bebas dan banyak yang digandakan agar sesuai dengan antarmuka berbasis indeks dan antarmuka berbasis iterator.

Terlepas dari alasan yang diposting di sini ada juga satu lagi - kompatibilitas biner . Penulis perpustakaan tidak memiliki kendali atas std::stringimplementasi yang Anda gunakan dan apakah memiliki tata letak memori yang sama dengan mereka.

std::stringadalah templat, jadi implementasinya diambil dari tajuk STL lokal Anda. Sekarang bayangkan Anda secara lokal menggunakan beberapa versi STL yang dioptimalkan kinerja, sepenuhnya kompatibel dengan standar. Misalnya, Anda mungkin telah memilih untuk mengganggu buffer statis di masing std::string- masing untuk mengurangi jumlah alokasi dinamis dan kesalahan cache. Akibatnya, tata letak memori dan / atau ukuran implementasi Anda berbeda dari yang perpustakaan.

Jika hanya tata letak yang berbeda, beberapa std::stringfungsi anggota memanggil instance yang dikirimkan dari pustaka ke klien atau sebaliknya mungkin gagal, bergantung pada anggota yang dipindahkan.

Jika ukurannya juga berbeda, semua tipe perpustakaan yang memiliki std::stringanggota akan tampak memiliki ukuran yang berbeda ketika diperiksa di perpustakaan dan dalam kode klien. Anggota data yang mengikuti std::stringanggota akan memiliki perubahan offset juga, dan akses langsung / aksesor inline yang dipanggil dari klien akan mengembalikan sampah, meskipun "tampak OK" ketika men-debug perpustakaan itu sendiri.

Bottomline - jika pustaka dan kode klien dikompilasi terhadap std::stringversi yang berbeda , mereka akan terhubung dengan baik, tetapi mungkin menghasilkan beberapa bug yang sulit dimengerti. Jika Anda mengubah std::stringimplementasi Anda, semua perpustakaan yang mengekspos anggota dari STL harus dikompilasi ulang agar sesuai dengan std::stringtata letak klien . Dan karena pemrogram ingin perpustakaan mereka menjadi kuat, Anda jarang melihat di std::stringmana saja.

Agar adil, ini berlaku untuk semua jenis STL. IIRC mereka tidak memiliki tata letak memori yang standar.

Ada banyak jawaban untuk pertanyaan ini tetapi ada beberapa:

1. Warisan. Banyak perpustakaan dan kelas string ditulis SEBELUMNYA dengan keberadaan std :: string.

2. Untuk kompatibilitas dengan kode dalam C. Library std :: string adalah C ++ di mana ada perpustakaan string lain yang bekerja dengan C dan C ++.

3. Untuk menghindari alokasi dinamis. Pustaka std :: string menggunakan alokasi dinamis dan mungkin tidak cocok untuk sistem tertanam, interupsi atau kode terkait waktu nyata, atau untuk fungsionalitas tingkat rendah.

4. Templat. Pustaka std :: string didasarkan pada templat. Sampai cukup baru-baru ini sejumlah kompiler C ++ memiliki dukungan template yang berkinerja buruk atau bahkan bermasalah. Sayangnya, saya bekerja di sebuah industri yang menggunakan banyak alat khusus dan salah satu dari rantai alat kami dari pemain utama di industri ini tidak "secara resmi" 100% mendukung C ++ (dengan barang buggy menjadi templat et al).

Mungkin ada banyak alasan yang lebih valid juga.

Sebagian besar tentang Unicode. Dukungan Standar untuk Unicode buruk sekali, dan semua orang memiliki kebutuhan Unicode mereka sendiri. Sebagai contoh, ICU mendukung setiap fungsi Unicode yang Anda inginkan, di balik antarmuka Java-dihasilkan-dari-Jawa yang paling menjijikkan yang mungkin Anda bayangkan, dan jika Anda berada di Unix terjebak dengan UTF-16 mungkin bukan ide Anda tentang waktu yang baik.

Selain itu, banyak orang memerlukan tingkat dukungan Unicode yang berbeda-tidak semua orang membutuhkan API tata letak teks yang rumit dan hal-hal semacam itu. Jadi, mudah untuk melihat mengapa ada banyak kelas string - yang standar cukup payah dan semua orang memiliki kebutuhan yang berbeda dari yang baru, dengan tidak ada yang mengelola untuk membuat kelas tunggal yang dapat melakukan banyak dukungan lintas platform Unicode dengan antarmuka yang menyenangkan.

Menurut pendapat saya, ini sebagian besar kesalahan Komite C ++ karena tidak benar memberikan dukungan untuk Unicode- pada tahun 1998 atau 2003, mungkin itu bisa dimengerti, tetapi tidak di C ++ 11. Semoga di C ++ 17 mereka akan melakukan yang lebih baik.

Itu karena setiap programmer memiliki sesuatu untuk dibuktikan dan merasakan kebutuhan untuk membuat kelas string mereka sendiri yang luar biasa, lebih cepat untuk fungsi mereka yang luar biasa. Biasanya sedikit berlebihan dan mengarah ke semua jenis konversi string ekstra dalam pengalaman saya.