Wadah STL atau Qt?


185

Apa pro dan kontra dari menggunakan kontainer Qt ( QMap, QVector, dll) lebih setara STL mereka?

Saya dapat melihat satu alasan untuk memilih Qt:

  • Wadah Qt dapat diteruskan ke bagian Qt lainnya. Sebagai contoh, mereka dapat digunakan untuk mengisi a QVariantdan kemudian a QSettings(dengan beberapa batasan, hanya QListdan QMap/ QHashyang kuncinya adalah string diterima).

Apakah ada yang lain?

Sunting : Dengan asumsi aplikasi sudah bergantung pada Qt.

Jawaban:


135

Saya mulai dengan menggunakan std::(w)stringdan wadah STL secara eksklusif dan mengkonversi ke / dari setara Qt, tapi saya sudah beralih ke QStringdan saya menemukan bahwa saya menggunakan wadah Qt semakin banyak.

Ketika datang ke string, QStringmenawarkan fungsionalitas yang jauh lebih lengkap dibandingkan dengan std::basic_stringdan itu sepenuhnya sadar Unicode. Ini juga menawarkan implementasi SAP yang efisien , yang sangat saya andalkan.

Kontainer Qt:

  • menawarkan implementasi SAP yang sama seperti pada QString, yang sangat berguna ketika menggunakan foreachmakro Qt (yang menyalin) dan ketika menggunakan meta-type atau sinyal dan slot.
  • dapat menggunakan iterator gaya-STL atau iterator gaya-Java
  • dapat di-stream dengan QDataStream
  • digunakan secara luas di Qt's API
  • memiliki implementasi yang stabil di seluruh sistem operasi. Implementasi STL harus mematuhi standar C ++, tetapi sebaliknya bebas untuk melakukan apa yang diinginkan (lihat std::stringkontroversi Kontrak Karya). Beberapa implementasi STL sangat buruk.
  • berikan hash, yang tidak tersedia kecuali Anda menggunakan TR1

QTL memiliki filosofi yang berbeda dari STL, yang dirangkum dengan baik oleh J. Blanchette: "Sementara kontainer STL dioptimalkan untuk kecepatan mentah, kelas-kelas kontainer Qt telah dirancang dengan cermat untuk memberikan kenyamanan, penggunaan memori minimal, dan perluasan kode minimal."
Tautan di atas memberikan detail lebih lanjut tentang penerapan QTL dan optimasi apa yang digunakan.


12
Dalam standar baru c ++ 0x COW cukup banyak.

16
re: "dirancang dengan hati-hati untuk menyediakan [...] penggunaan memori minimal". Anda seharusnya tidak percaya pemasaran. Profil QList<double>pada arsitektur 32-bit untuk penggunaan memori untuk melihat sendiri.
Marc Mutz - mmutz

11
"Ini juga menawarkan implementasi SAP yang efisien": SAPI tidak terlalu efisien dalam hal aplikasi multithreaded ...
Grizzly

5
@ MarcMutz-mmutz coba profil QVectoralih-alih QList. Ada cukup penjelasan Qt, bahwa QList dirancang untuk menyimpan pointer pada objek. Jadi setiap item ganda yang dibuat secara dinamis dan pointer ke item ini disimpan QList. QList dirancang sebagai wadah "tengah" antara vektor dan daftar tertaut. Ini tidak dirancang untuk kasus kritis memori / kinerja.
Dmitry Sazonov

2
@ user1095108 Tidak ada yang salah dengan itu. Pergi gunakan stl. Beberapa dari kita lebih suka menulis kode yang benar dengan cepat. Tidak ada yang salah dengan itu juga.
weberc2

178

Ini adalah pertanyaan yang sulit dijawab. Ini benar-benar dapat mengarah pada argumen filosofis / subyektif.

Yang telah dibilang...

Saya merekomendasikan aturan "Ketika di Roma ... Lakukan seperti yang dilakukan orang Roma"

Yang berarti jika Anda berada di tanah Qt, kode seperti yang dilakukan orang Qtia. Ini bukan hanya untuk masalah keterbacaan / konsistensi. Pertimbangkan apa yang terjadi jika Anda menyimpan semuanya dalam wadah stl maka Anda harus meneruskan semua data itu ke fungsi Qt. Apakah Anda benar-benar ingin mengelola banyak kode yang menyalin hal-hal ke / keluar dari wadah Qt. Kode Anda sudah sangat bergantung pada Qt, jadi tidak seperti Anda membuatnya lebih "standar" dengan menggunakan wadah stl. Dan apa gunanya sebuah wadah jika setiap kali Anda ingin menggunakannya untuk sesuatu yang bermanfaat, Anda harus menyalinnya ke dalam wadah Qt yang sesuai?


1
+1 Anda sepenuhnya benar, itulah yang saya coba jelaskan dalam pertanyaan saya ("Saya bisa melihat satu alasan untuk memilih Qt") jadi saya sedikit mengeditnya. Terima kasih
Julien-L

Benar-benar kata yang baik. Jika Anda melakukan QT, gunakan hal-hal QT! Bayangkan momen "WTF" untuk pengelola ketika ia membuka aplikasi QT dan melihat QT dan STL digunakan secara bergantian. Itu bisa berakhir menjadi mimpi buruk (tidak perlu).
It'sPete

5
@ It'sPete STL adalah bagian dari standar; QT tidak. Kode apa pun yang menggunakan standar tidak boleh memicu momen "WTF".
Alice

6
Bangsa Romawi menempatkan tawanan mereka ke Colosseum dan kemudian memburu mereka dengan singa. Jika Anda lebih tahu, jangan ikuti kebiasaan setempat. Itu sama benarnya di Qt seperti halnya bagi Manusia Modern di Kekaisaran Romawi ...
Marc Mutz - mmutz

1
@mmutz Anda mengatakan bahwa itu adalah hal yang buruk, saya ingin menaruh beberapa kode yang saya temukan di Colosseum itu dan menonton pertunjukan
slf

65

Wadah Qt lebih terbatas daripada yang STL. Beberapa contoh di mana yang STL lebih unggul (semua ini saya tekan di masa lalu):

  • STL distandarisasi, tidak berubah dengan setiap versi Qt (Qt 2 punya QList(berbasis pointer) dan QValueList(berbasis nilai); Qt 3 punya QPtrListdan QValueList; Qt 4 sekarang punya QList, dan tidak ada yang suka QPtrList atau tidak sama sekali QValueList).
    Bahkan jika Anda akhirnya menggunakan wadah Qt, gunakan subset API yang kompatibel dengan STL (mis. push_back(), Bukan append();, front()bukan first(), ...) untuk menghindari porting lagi pada Qt 5. Di Qt2-> 3 dan Qt3-> 4 transisi, perubahan dalam kontainer Qt adalah di antara mereka yang membutuhkan kode churn paling banyak.
  • Wadah bidirectional STL semua memiliki rbegin()/ rend(), membuat iterasi terbalik simetris untuk meneruskan iterasi. Tidak semua kontainer Qt memilikinya (yang asosiatif tidak), jadi membalikkan iterasi tidak perlu rumit.
  • Wadah STL memiliki jangkauan - insert()dari jenis iterator yang berbeda, tetapi kompatibel, sehingga std::copy()jauh lebih jarang dibutuhkan.
  • Wadah STL memiliki Allocatorargumen templat, membuat sepele manajemen memori kustom (diperlukan typedef), dibandingkan dengan Qt (garpu QLineEditdiperlukan untuk s/QString/secqstring/). EDIT 20171220 : Ini memotong Qt off dari kemajuan dalam desain pengalokasi setelah C ++ 11 dan C ++ 17, lih. mis . pembicaraan John Lakos ( bagian 2 ).
  • Tidak ada Qt yang setara dengan std::deque.
  • std::listtelah splice(). Setiap kali saya menemukan diri saya menggunakan std::list, itu karena saya perlu splice().
  • std::stack, std::queueBenar agregat kontainer yang mendasarinya, dan tidak mewarisi itu, sebagai QStack, QQueuelakukan.
  • QSetseperti std::unordered_set, tidak suka std::set.
  • QListadalah hanya aneh .

Banyak hal di atas dapat diselesaikan dengan mudah di Qt , tetapi perpustakaan kontainer di Qt tampaknya mengalami kurangnya fokus pengembangan saat ini.

EDIT 20150106 : Setelah menghabiskan beberapa waktu mencoba membawa dukungan C ++ 11 ke kelas kontainer Qt 5, saya telah memutuskan bahwa itu tidak layak untuk dikerjakan. Jika Anda melihat pekerjaan yang dimasukkan ke dalam implementasi pustaka standar C ++, cukup jelas bahwa kelas Qt tidak akan pernah menyusul. Kami telah merilis Qt 5.4 sekarang danQVector masih tidak memindahkan elemen pada realokasi, tidak memilikiemplace_back()atau menilai ulangpush_back()... Kami juga baru saja menolakQOptionaltemplat kelas, sebagaistd::optionalgantinyamenunggu. Demikian juga untukstd::unique_ptr. Saya berharap tren itu berlanjut.


3
Hah. Saya di bawah kesan QList itu setara dengan std::deque. Jelas, saya seharusnya tidak membaca sekilas dokumentasi.
Dennis Zickefoose

QVectortelah memiliki crbegindan teman-teman sejak Qt 5.6
Bart Louwers

@ Alex: benar, saya menambahkan yang mudah, tetapi tidak semua kontainer Qt memilikinya, (karena Anda tidak menggunakan std::reverse_iteratorlebih dari yang rusak QHash/ QMapiterator, yang, ketika dereferenced, kembali mapped_typebukan value_type). Tidak ada yang tidak bisa diperbaiki, tetapi lihat EDIT saya mulai tahun 2015.
Marc Mutz - mmutz

@ MarcMutz-mmutz Terima kasih telah mengklarifikasi.
Bart Louwers

Mungkin layak ditambahkan ke daftar fakta bahwa mis QVectormenggunakan intsebagai indeksnya, sehingga membatasi ukuran 31-bit (bahkan pada sistem 64-bit). Selain itu, ia bahkan tidak dapat menyimpan INT_MAXelemen berukuran lebih besar dari 1 byte. Misalnya, yang terbesar yang .size()dapat saya miliki QVector<float>di x86_64 Linux gcc adalah 536870907 elemen (2²⁹-5), sementara std::vector<float>berhasil mengalokasikan 4294967295 elemen (2³²-1; tidak mencoba lagi karena kurangnya RAM untuk ini (ukuran ini sudah memakan waktu 16 GiB) ).
Ruslan

31

Mari pilah klaim-klaim ini menjadi fenomena terukur yang sebenarnya:

  • Lebih ringan: Wadah Qt menggunakan lebih sedikit memori daripada wadah STL
  • Lebih aman: Wadah Qt memiliki peluang lebih sedikit untuk digunakan dengan tidak patut
  • Lebih mudah: Wadah Qt mengurangi beban intelektual

Lebih mudah

Klaim yang dibuat dalam konteks ini adalah bahwa iterasi gaya java entah bagaimana "lebih mudah" daripada gaya STL, dan karenanya Qt lebih mudah digunakan karena antarmuka tambahan ini.

Gaya Jawa:

QListIterator<QString> i(list);
while (i.hasNext())
    qDebug() << i.next();

Gaya STL:

QList<QString>::iterator i;
for (i = list.begin(); i != list.end(); ++i)
    qDebug << *i;

Gaya iterator Java memiliki keuntungan menjadi sedikit lebih kecil dan lebih bersih. Masalahnya adalah, ini bukan gaya STL lagi.

C ++ 11 STL Style

for( auto i = list.begin(); i != list.end(); ++i)
    qDebug << *i;

atau

C ++ 11 gaya foreach

for (QString i : list)
    qDebug << i;

Yang sangat sederhana sehingga tidak ada alasan untuk menggunakan hal lain (kecuali Anda tidak mendukung C ++ 11).

Namun, favorit saya adalah:

BOOST_FOREACH(QString i, list)
{
    qDebug << i;
}

Jadi, seperti yang bisa kita lihat, antarmuka ini tidak memberi kita apa-apa selain antarmuka tambahan, selain antarmuka yang sudah ramping, ramping, dan modern. Menambahkan level abstraksi yang tidak perlu di atas antarmuka yang sudah stabil dan dapat digunakan? Bukan ide saya "lebih mudah".

Juga, antarmuka Qt foreach dan java menambahkan overhead; mereka menyalin struktur, dan memberikan tingkat tipuan yang tidak perlu. Ini mungkin tidak terlalu banyak, tetapi mengapa menambahkan lapisan overhead untuk menyediakan antarmuka yang tidak terlalu sederhana? Java memiliki antarmuka ini karena java tidak memiliki operator kelebihan; C ++ tidak.

Lebih aman

Pembenaran yang diberikan Qt adalah masalah berbagi implisit, yang tidak implisit maupun masalah. Namun itu melibatkan berbagi.

QVector<int> a, b;
a.resize(100000); // make a big vector filled with 0.

QVector<int>::iterator i = a.begin();
// WRONG way of using the iterator i:
b = a;
/*
Now we should be careful with iterator i since it will point to shared data
If we do *i = 4 then we would change the shared instance (both vectors)
The behavior differs from STL containers. Avoid doing such things in Qt.
*/

Pertama, ini bukan implisit; Anda secara eksplisit menetapkan satu vektor ke yang lain. Spesifikasi iterator STL dengan jelas menunjukkan bahwa iterator termasuk dalam wadah, jadi kami telah dengan jelas memperkenalkan wadah bersama antara b dan a. Kedua, ini bukan masalah; selama semua aturan spesifikasi iterator dipatuhi, sama sekali tidak ada yang salah. Satu-satunya saat ada yang salah ada di sini:

b.clear(); // Now the iterator i is completely invalid.

Qt menetapkan ini seolah-olah itu berarti sesuatu, seperti masalah muncul de novo dari skenario ini. Tidak. Iterator tidak valid, dan sama seperti apa pun yang dapat diakses dari beberapa area terpisah, ini hanya cara kerjanya. Bahkan, ini akan terjadi dengan mudah dengan iterator gaya Java di Qt, berkat sangat bergantung pada berbagi implisit, yang merupakan antipemutakhir seperti yang didokumentasikan di sini , dan di banyak daerah lainnya . Tampaknya aneh untuk "optimasi" ini mulai digunakan dalam kerangka kerja yang bergerak semakin banyak menuju multithreading, tapi itu pemasaran untuk Anda.

Lebih ringan

Yang ini agak rumit. Penggunaan Copy-On-Write dan Berbagi Secara implisit dan Strategi Pertumbuhan membuatnya sangat sulit untuk benar-benar membuat jaminan tentang berapa banyak memori yang akan digunakan wadah Anda pada waktu tertentu. Ini tidak seperti STL, yang memberi Anda jaminan algoritmik yang kuat.

Kita tahu batas minimal ruang terbuang untuk vektor adalah akar kuadrat dari panjang vektor , tetapi tampaknya tidak ada cara untuk mengimplementasikannya dalam Qt; berbagai "optimisasi" yang didukungnya akan menghalangi fitur penghematan ruang yang sangat penting ini. STL tidak memerlukan fitur ini (dan sebagian besar menggunakan pertumbuhan dua kali lipat, yang lebih boros), tetapi penting untuk dicatat bahwa Anda setidaknya bisa mengimplementasikan fitur ini, jika perlu.

Hal yang sama berlaku untuk daftar tertaut ganda, yang dapat menggunakan tautan XOr untuk secara drastis mengurangi ruang yang digunakan. Sekali lagi, ini tidak mungkin dengan Qt, karena persyaratan untuk pertumbuhan dan SAP.

SAP memang dapat membuat sesuatu lebih ringan, tetapi Wadah Intrusif, seperti didukung oleh boost , dan Qt sering digunakan dalam versi sebelumnya, tetapi mereka tidak digunakan lagi karena mereka sulit digunakan, tidak aman, dan membebani beban. pada programmer. SAP adalah solusi yang jauh lebih tidak mengganggu, tetapi tidak menarik karena alasan yang disebutkan di atas.

Tidak ada alasan mengapa Anda tidak bisa menggunakan wadah STL dengan biaya memori yang sama atau kurang dari wadah Qt, dengan manfaat tambahan sebenarnya mengetahui berapa banyak memori yang akan Anda buang pada waktu tertentu. Sayangnya, mustahil untuk membandingkan keduanya dalam penggunaan memori mentah, karena tolok ukur seperti itu akan menunjukkan hasil yang sangat berbeda dalam kasus penggunaan yang berbeda, yang merupakan jenis masalah yang STL dirancang untuk diperbaiki.

Kesimpulannya

Hindari penggunaan Qt Containers bila memungkinkan untuk melakukannya tanpa membebankan biaya penyalinan, dan gunakan iterasi tipe STL (mungkin melalui pembungkus atau sintaks baru), bila memungkinkan.


4
Poin Anda sebagian besar valid, tetapi ada beberapa info yang menyesatkan di sana: Adding an unnecessary level of abstraction on top of an already stable and usable interface? Not my idea of "easier".iterator gaya Java Qt tidak ditambahkan ke C ++ 11; mereka mendahului itu. Pokoknya Qt's foreach(QString elem, list)semudah foreach C ++ 11 atau BOOST_FOREACH dan bekerja dengan kompiler yang sesuai dengan pra-C ++ 11.
weberc2

@ weberc2 Anda bingung; Iterator gaya Java Qt ditambahkan di atas iterator C ++ (bukan C ++ 11). Ini lapisan tambahan abstraksi (dan yang tidak perlu) yang membengkak antarmuka, yang tidak mudah. Dan pendahuluan untuk Qt tidak semudah BOOST_FOREACH, karena terutama tidak aman, dan tidak memiliki luasnya dukungan yang sama (BOOST_FOREACH dapat berlaku untuk rentang apa pun, untuk versi C ++, di mana sebagai pendahuluan dalam QT menuntut C + +03 kepatuhan). Kemampuan QT harus dihindari dengan cara apa pun.
Alice

So, as we can see, this interface gains us nothing except an additional interface, *on top of* an already sleek, streamlined, and modern interface. Adding an unnecessary level of abstraction on top of an already stable and usable interface? Not my idea of "easier".(penekanan saya) Anda mengatakan ini tepat setelah Anda menunjukkan kepada kami versi C ++ 11 dan BOOST foreach, membuatnya terdengar seperti versi Qt dibangun dari salah satu dari keduanya, yang bukan merupakan kasus AFAICT. Saya yakin itu bukan apa yang Anda maksudkan, tetapi justru itulah yang menjadi penyebabnya. Karenanya "informasi menyesatkan".
weberc2

It's an additional layer of abstraction (and an unnecessary one) that bloats the interface, which is not easier.Masih belum jelas apa yang Anda bandingkan. C ++ 03 iterators? C ++ 11 iterator? BOOST_FOREACH? Semua yang di atas?
weberc2

1
Saya hanya mengatakan, Anda sering sangat ambigu mengenai metode iterasi yang Anda maksud. Saya percaya bahwa Anda berpikir Anda jelas dan bahasa Anda masuk akal, tetapi tampaknya aneh untuk menolak untuk menyebutkan. Setuju untuk tidak setuju, saya kira.
weberc2

23

Wadah STL:

  • Memiliki jaminan kinerja
  • Dapat digunakan dalam algoritma STL yang juga memiliki jaminan kinerja
  • Dapat dimanfaatkan oleh pustaka C ++ pihak ketiga seperti Boost
  • Apakah standar, dan cenderung hidup lebih lama dari solusi eksklusif
  • Dorong pemrograman generik algoritma dan struktur data. Jika Anda menulis algoritme dan struktur data baru yang sesuai dengan STL, Anda dapat memanfaatkan apa yang sudah disediakan STL tanpa biaya.

5
Semua hal di atas kecuali menjadi standar juga berlaku untuk QTL, asalkan Anda mengkompilasi Qt dengan dukungan STL (default). Dukungan STL mencakup fungsi iterator, typedefs wadah (const_iterator, dll), fungsi konversi (ke / dari STL).
rpg

2
Qt bukan milik
txwikinger

3
@ rpg Hampir semuanya tidak benar untuk QTL; QTL tidak memiliki jaminan kinerja yang kuat (karena mereka telah menghancurkannya di masa lalu), tidak sesuai dengan STL (tanpa terbalik, dan karenanya tidak dapat digunakan dengan banyak dorongan), tidak standar (mereka terus berubah antar versi), dan melakukan tidak mendorong pemrograman generik (mereka tidak memiliki argumen templat untuk pengalokasi, misalnya).
Alice

15

Wadah Qt menggunakan idiom copy-on-write.


2
+1, mungkin menjadi keuntungan signifikan dalam kinerja dan sumber daya
RedGlyph

32
Atau mungkin kerugian signifikan. Lihat gotw.ca/publications/optimizations.htm
Kaz Dragon

3
Penghitungan ulang atom tampaknya berjalan cukup baik: labs.trolltech.com/blogs/2006/10/16/…
rpg

Wadah STL bebas menggunakan idiom apa pun yang ada selama memenuhi jaminan kinerja dan speknya. SAP berlaku, bahkan di bawah C ++ 11 / C ++ 14 STL.
Alice

1
@Alice COW bukan implementasi yang valid sebagian besar waktu karena melanggar kompleksitas standar dan jaminan validitas iterator di hampir semua kasus. Salah satu dari beberapa kelas yang dapat diimplementasikan dengan COW adalah std::basic_stringdan standar mengambil tindakan dengan C ++ 11 untuk membuat ini tidak sesuai.
Tiago Gomes

9

Salah satu masalah utama adalah bahwa Qt's API mengharapkan Anda untuk memberikan data dalam wadah Qt, jadi Anda mungkin juga cukup menggunakan wadah Qt daripada mengubah bolak-balik antara keduanya.

Juga, jika Anda sudah menggunakan kontainer Qt, mungkin akan sedikit lebih optimal untuk menggunakannya secara eksklusif, karena Anda tidak harus menyertakan file header STL dan berpotensi menautkan di perpustakaan STL. Namun, tergantung pada rantai alat Anda, itu mungkin terjadi. Murni dari perspektif desain, konsistensi pada umumnya adalah hal yang baik.


1
Tingkat di mana Anda harus "mengubah bolak-balik" antara wadah STL dan Qt dalam aplikasi nyata yang menggunakan STL kecuali di mana berinteraksi dengan Qt umumnya sangat ditaksir terlalu tinggi. Sebagian besar waktu Anda melakukan beberapa std :: transform datang ke / dari lapisan presentasi (yang menggunakan Qt) dan Anda mendapatkan saklar wadah gratis. Pihak yang berminat dapat menelusuri ke projects.kde.org/projects/kde/kdepim/repository/revisions/… untuk melihat sendiri.
Marc Mutz - mmutz

8

Jika data yang Anda gunakan sebagian besar digunakan untuk menggerakkan UI berbasis Qt, maka pasti gunakan kontainer Qt.

Jika sebagian besar data digunakan secara internal di aplikasi, dan Anda tidak akan pernah berpeluang jauh dari Qt, maka jika tidak ada masalah kinerja, gunakan wadah Qt karena itu akan membuat bit data yang masuk ke UI lebih mudah untuk ditangani.

Jika sebagian besar data digunakan bersama dengan perpustakaan lain yang hanya tahu tentang wadah STL, maka gunakan wadah STL. Jika Anda memiliki situasi ini, Anda dalam masalah apa pun karena Anda akan melakukan banyak bolak-balik di antara jenis wadah apa pun yang Anda lakukan.


7

Selain perbedaan SAP, wadah STL jauh lebih banyak didukung pada berbagai platform. Qt cukup portabel jika Anda membatasi pekerjaan Anda pada platform "arus utama", tetapi STL juga tersedia di banyak platform lain yang tidak jelas (mis., DSP Texas Instruments).

Karena STL adalah standar daripada dikendalikan oleh satu perusahaan, ada, secara umum, lebih banyak programmer yang dapat dengan mudah membaca, memahami, dan memodifikasi kode STL dan lebih banyak sumber daya (buku, forum online, konferensi, dll.) Untuk mendukung mereka dalam melakukan ini daripada Qt. Itu bukan untuk mengatakan bahwa seseorang harus menghindar dari Qt karena alasan ini saja; Hanya saja, semua hal lain dianggap sama, Anda harus default ke STL, tetapi tentu saja semua hal jarang sama, jadi Anda harus memutuskan dalam konteks Anda sendiri yang paling masuk akal.

Sehubungan dengan jawaban AlexKR: kinerja STL dijamin dalam batas, tetapi implementasi yang diberikan dapat menggunakan detail yang bergantung pada platform untuk mempercepat STL mereka. Jadi dalam hal itu, Anda mungkin mendapatkan hasil yang berbeda pada platform yang berbeda, tetapi itu tidak akan pernah lebih lambat daripada jaminan eksplisit (bug modulo).


9
Berkenaan dengan poin pertama Anda: Saya berasumsi OP mengacu pada proyek yang sudah menggunakan Qt, dan karena itu sudah terbatas pada platform "mainstream". Tampaknya tidak mungkin seseorang akan menarik perpustakaan kelas berat seperti Qt hanya untuk kelas kontainernya.
ThisSuitIsBlackNot

4

Lima sen saya: Wadah Qt seharusnya berfungsi serupa pada platform berbeda. Sementara wadah STL tergantung pada implementasi STL. Anda mungkin mendapatkan hasil kinerja yang berbeda.

EDIT: Saya tidak mengatakan bahwa STL "lebih lambat" tetapi saya menunjukkan efek dari berbagai detail implementasi.
Silakan periksa ini , dan mungkin ini .
Dan itu bukan masalah nyata STL. Jelas, jika Anda memiliki perbedaan kinerja yang signifikan, maka ada masalah dalam kode yang menggunakan STL.


Wadah STL semuanya serupa, terlepas dari implementasinya. Anda tidak dapat menerapkan vektor seperti daftar di belakang layar karena harus berada di blok memori yang berdekatan. STL juga biasanya dioptimalkan hingga luasan yang sangat besar di semua platform utama.
Yacoby

1
Jika Anda tetap berpegang pada apa yang dijanjikan STL (alih-alih mengasumsikan penerapannya), Anda tidak akan pernah memiliki masalah untuk berpindah antar platform dengan STL. Sama dengan Qt.
Michael Kohne

Ini adalah kebalikan dari kebenaran. Wadah STL selalu bekerja sama di semua platform; jika tidak, mereka bukan STL. QT, bagaimanapun, secara drastis mengubah kinerja dari versi ke versi, jadi pada platform dengan QT4.0 daripada QT4.8, Anda bisa mendapatkan beberapa perubahan serius.
Alice

1
Anda membingungkan dua jenis kinerja yang sangat berbeda; kinerja algoritmik dan kinerja komputasi praktis. Semua implementasi STL menjamin kinerja algoritmik yang sama; jika vektor Anda membutuhkan log (n) waktu untuk mengindeks elemen, itu bukan vektor STL. Tautan Anda menunjukkan kinerja komputasi praktis, yang tidak ada artinya dalam diskusi ini; QT mengubah algoritme mereka di antara versi, dan C ++ yang sama pada platform yang berbeda mendapatkan kinerja yang berbeda. Ini, menurut pengalaman saya, jauh lebih mudah ditempa daripada perbedaan dalam kinerja STL.
Alice

3

Saya kira itu tergantung pada cara Anda menggunakan Qt. Jika Anda menggunakannya di seluruh produk Anda, maka mungkin masuk akal untuk menggunakan wadah Qt. Jika Anda hanya berisi untuk (misalnya) bagian UI, mungkin lebih baik menggunakan wadah standar C ++.


3

Saya berpendapat bahwa STL adalah perangkat lunak yang sangat baik namun jika saya melakukan beberapa pemrograman terkait KDE atau Qt maka Qt adalah cara yang harus dilakukan. Juga tergantung pada kompiler yang Anda gunakan, dengan GCC STL bekerja cukup baik namun jika Anda harus menggunakan katakanlah SUN Studio CC maka STL kemungkinan besar akan membawa Anda sakit kepala karena kompiler bukan STL per se. Dalam hal ini karena kompiler akan membuat kepala Anda sakit, cukup gunakan Qt untuk menyelamatkan Anda dari masalah. Hanya 2 sen saya ...


3

Ada (kadang-kadang) batasan besar dalam QVector. Itu hanya dapat mengalokasikan memori byte int (perhatikan bahwa batasnya adalah dalam byte bukan dalam jumlah elemen). Ini menyiratkan bahwa mencoba mengalokasikan blok memori berdekatan yang lebih besar dari ~ 2GB dengan QVector akan menyebabkan crash. Ini terjadi dengan Qt 4 dan 5. std :: vector tidak memiliki batasan seperti itu.


0

Alasan utama untuk menggunakan wadah STL untuk saya adalah jika Anda memerlukan pengalokasi khusus untuk menggunakan kembali memori dalam wadah yang sangat besar. Misalkan misalnya Anda memiliki QMap yang menyimpan 1000000 entri (pasangan kunci / nilai). Dalam Qt yang menyiratkan alokasi persis 10.000.000 juta ( newpanggilan) apa pun yang terjadi. Di STL Anda selalu dapat membuat pengalokasi khusus yang secara internal mengalokasikan semua memori itu sekaligus dan menetapkannya untuk setiap entri saat peta diisi.

Saran saya adalah menggunakan wadah STL saat menulis algoritma kinerja kritis dalam logika bisnis dan kemudian mengubahnya kembali ke wadah Qt ketika hasilnya siap dengan ditampilkan oleh kontrol dan formulir UI Anda jika diperlukan.


Tidak mencoba membela QTL di sini, tetapi Anda bisa mengkhususkan diri QMapNode<K,V>untuk Anda K, Vuntuk menyediakannya sendiri operator new.
Marc Mutz - mmutz
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.