Container STL hay Qt?

Ưu và nhược điểm của việc sử dụng container Qt (là gì QMap, QVectorvv) trên STL tương đương của họ?

Tôi có thể thấy một lý do để thích Qt:

• Container Qt có thể được chuyển qua các phần khác của Qt. Ví dụ, chúng có thể được sử dụng để cư trúQVariant và sau đó một QSettings(với một số giới hạn, chỉ QListvà QMap/ QHashcó khóa là chuỗi được chấp nhận).

Có cái nào khác không?

Biên tập : Giả sử ứng dụng đã dựa vào Qt.

Tôi đã bắt đầu bằng cách sử dụng std::(w)stringvà các bộ chứa STL độc quyền và chuyển đổi sang / từ các tương đương Qt, nhưng tôi đã chuyển sang QStringvà tôi thấy rằng tôi đang sử dụng các bộ chứa của Qt ngày càng nhiều.

Khi nói đến chuỗi, QStringcung cấp chức năng đầy đủ hơn nhiều so với std::basic_stringvà nó hoàn toàn nhận biết Unicode. Nó cũng cung cấp một triển khai COW hiệu quả , mà tôi đã dựa vào rất nhiều.

Container của Qt:

• cung cấp triển khai COW tương tự như trong QString, cực kỳ hữu ích khi sử dụng foreachmacro của Qt (bản sao) và khi sử dụng loại meta hoặc tín hiệu và vị trí.
• có thể sử dụng các trình vòng lặp kiểu STL hoặc các trình vòng lặp kiểu Java
• có thể truyền phát với QDataStream
• được sử dụng rộng rãi trong API của Qt
• có một triển khai ổn định trên các hệ điều hành. Việc triển khai STL phải tuân theo tiêu chuẩn C ++, nhưng về mặt khác thì được tự do thực hiện (xem phầnstd::string tranh cãi COW). Một số triển khai STL đặc biệt xấu.
• cung cấp băm, không có sẵn trừ khi bạn sử dụng TR1

QTL có một triết lý khác với STL, được J. Blanchette tóm tắt : "Trong khi các container của STL được tối ưu hóa cho tốc độ thô, các lớp container của Qt đã được thiết kế cẩn thận để cung cấp sự tiện lợi, sử dụng bộ nhớ tối thiểu và mở rộng mã tối thiểu."
Liên kết trên cung cấp thêm chi tiết về việc triển khai QTL và những gì tối ưu hóa được sử dụng.

Đây là một câu hỏi khó trả lời. Nó thực sự có thể sôi sục với một lập luận triết học / chủ quan.

Điều đó đang được nói ...

Tôi đề nghị quy tắc "Khi ở Rome ... Làm như người La Mã làm"

Điều đó có nghĩa là nếu bạn ở vùng đất Qt, hãy viết mã như người Qt làm. Điều này không chỉ dành cho mối quan tâm dễ đọc / nhất quán. Hãy xem xét những gì xảy ra nếu bạn lưu trữ mọi thứ trong một thùng chứa stl thì bạn phải chuyển tất cả dữ liệu đó sang một hàm Qt. Bạn có thực sự muốn quản lý một loạt các mã sao chép mọi thứ vào / ra khỏi các thùng chứa Qt. Mã của bạn đã phụ thuộc rất nhiều vào Qt, do đó, không giống như bạn đang làm cho nó trở nên "chuẩn" hơn bằng cách sử dụng các thùng chứa stl. Và điểm của một container là gì nếu mỗi khi bạn muốn sử dụng nó cho bất cứ điều gì hữu ích, bạn phải sao chép nó vào container Qt tương ứng?

Các thùng chứa Qt bị hạn chế hơn so với STL. Một vài ví dụ về nơi STL vượt trội (tất cả những thứ tôi đã đánh trong quá khứ):

• STL được chuẩn hóa, không thay đổi với mọi phiên bản Qt (Qt 2 có QList(dựa trên con trỏ) và QValueList(dựa trên giá trị); Qt 3 đã có QPtrListvà QValueList; Qt 4 hiện có QList, và không có gì giống như QPtrList hoặc QValueList ).
  Ngay cả khi bạn kết thúc bằng cách sử dụng các bộ chứa Qt, hãy sử dụng tập hợp con API tương thích STL (nghĩa là push_back(), không append(); front(), khôngfirst() , ...) để tránh chuyển tiếp một lần nữa đến Qt 5. Trong cả Qt2-> 3 và Qt3-> 4 chuyển đổi, những thay đổi trong các thùng chứa Qt nằm trong số những chuyển đổi đòi hỏi nhiều mã nhất.
• Tất cả các container hai chiều STL đều có rbegin()/ rend(), làm cho phép lặp ngược đối xứng để lặp lại. Không phải tất cả các thùng chứa Qt đều có chúng (những cái kết hợp không có), vì vậy việc lặp lại rất phức tạp.
• Các thùng chứa STL có phạm vi - insert()từ các loại trình lặp khác nhau, nhưng tương thích, khiến cho việc sử std::copy()dụng ít thường xuyên hơn.
• Các bộ chứa STL có một Allocatorđối số mẫu, làm cho việc quản lý bộ nhớ tùy chỉnh trở nên tầm thường (yêu cầu typedef), so với Qt (fork của QLineEdityêu cầu cho s/QString/secqstring/). EDIT 20171220 : Điều này cắt giảm Qt những tiến bộ trong thiết kế phân bổ theo C ++ 11 và C ++ 17, x. ví dụ như bài nói chuyện của John Lakos ( phần 2 ).
• Không có Qt tương đương với std::deque .
• std::listcó splice(). Bất cứ khi nào tôi thấy mình sử dụng std::list, đó là vì tôi cần splice().
• std::stack, std::queuetổng hợp chính xác thùng chứa bên dưới của chúng và không kế thừa nó, như QStack, QQueuelàm.
• QSetlà thích std::unordered_set, không thích std::set.
• QListlà một chỉ lạ .

Nhiều điều ở trên có thể được giải quyết khá dễ dàng trong Qt , nhưng thư viện container trong Qt dường như gặp phải sự thiếu tập trung phát triển vào lúc này.

EDIT 20150106 : Sau khi dành một chút thời gian để cố gắng mang hỗ trợ C ++ 11 cho các lớp container Qt 5, tôi đã quyết định rằng nó không đáng để làm việc. Nếu bạn nhìn vào công việc đang được đưa vào triển khai thư viện chuẩn C ++, thì rõ ràng các lớp Qt sẽ không bao giờ theo kịp. Chúng tôi đã phát hành Qt 5.4 ngay bây giờ vàQVector vẫn không di chuyển các yếu tố trên các phân bổ lại, không cóemplace_back()hoặc xác định giá trị-push_back()... Gần đây chúng tôi cũng đã từ chối mộtQOptionalmẫu lớp, chờ đợistd::optionalthay thế. Tương tự như vậy chostd::unique_ptr. Tôi hy vọng xu hướng đó tiếp tục.

Hãy chia nhỏ những tuyên bố này thành những hiện tượng có thể đo lường được:

• Nhẹ hơn: Container Qt sử dụng ít bộ nhớ hơn container STL
• An toàn hơn: Container Qt có ít cơ hội được sử dụng không đúng cách
• Dễ dàng hơn: Các thùng chứa Qt thể hiện ít gánh nặng trí tuệ hơn

Dễ dàng hơn

Khiếu nại được đưa ra trong ngữ cảnh này là việc lặp theo kiểu java bằng cách nào đó "dễ dàng" hơn kiểu STL, và do đó Qt dễ sử dụng hơn do giao diện bổ sung này.

Phong cách Java:

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

Phong cách STL:

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

Kiểu trình lặp Java có lợi ích là nhỏ hơn và sạch hơn một chút. Vấn đề là, đây không thực sự là phong cách STL nữa.

Phong cách C ++ 11 STL

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

hoặc là

Phong cách foreach C ++ 11

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

Điều này đơn giản đến mức không có lý do gì để sử dụng bất cứ thứ gì khác (trừ khi bạn không hỗ trợ C ++ 11).

Tuy nhiên, yêu thích của tôi là:

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

Vì vậy, như chúng ta có thể thấy, giao diện này không mang lại cho chúng ta điều gì ngoại trừ một giao diện bổ sung, bên trên một giao diện hiện đại, đẹp mắt và hợp lý. Thêm một mức độ trừu tượng không cần thiết trên giao diện đã ổn định và có thể sử dụng? Không phải ý tưởng của tôi về "dễ dàng hơn".

Ngoài ra, giao diện Qt foreach và java thêm chi phí; họ sao chép cấu trúc, và cung cấp một mức độ không cần thiết. Điều này có vẻ không nhiều, nhưng tại sao lại thêm một lớp chi phí để cung cấp giao diện không đơn giản hơn nhiều? Java có giao diện này vì java không có quá tải toán tử; C ++ nào.

An toàn hơn

Sự biện minh mà Qt đưa ra là vấn đề chia sẻ ngầm, không phải là vấn đề ngầm hay vấn đề. Nó không liên quan đến việc chia sẻ, tuy nhiên.

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.
*/

Đầu tiên, đây không phải là ẩn ý; bạn rõ ràng đang gán một vectơ cho một vectơ khác. Đặc tả trình lặp STL chỉ rõ rằng các trình vòng lặp thuộc về vùng chứa, vì vậy chúng tôi đã giới thiệu rõ ràng một vùng chứa chung giữa b và a. Thứ hai, đây không phải là một vấn đề; miễn là tất cả các quy tắc của đặc tả iterator được tuân theo, hoàn toàn không có gì sai. Lần duy nhất có sự cố xảy ra là ở đây:

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

Qt chỉ định điều này như thể nó có ý nghĩa gì đó, giống như một vấn đề phát sinh từ kịch bản này. Nó không. Trình lặp không hợp lệ và giống như bất kỳ thứ gì có thể được truy cập từ nhiều vùng khác nhau, đây chỉ là cách nó hoạt động. Trên thực tế, điều này sẽ xảy ra dễ dàng với các trình vòng lặp kiểu Java trong Qt, nhờ nó phụ thuộc rất nhiều vào việc chia sẻ ngầm, đó là một phản đề như được ghi lại ở đây và tại nhiều khu vực khác . Điều này có vẻ đặc biệt kỳ lạ đối với việc "tối ưu hóa" này được đưa vào sử dụng trong một khuôn khổ ngày càng hướng tới đa luồng, nhưng đó là tiếp thị cho bạn.

Bật lửa

Đây là một chút phức tạp hơn. Việc sử dụng các chiến lược tăng trưởng và chia sẻ sao chép và ghi lại tiềm ẩn khiến cho việc thực sự đảm bảo về việc bộ nhớ của bạn sẽ sử dụng bao nhiêu bộ nhớ tại bất kỳ thời điểm nào. Điều này không giống như STL, mang đến cho bạn sự đảm bảo về thuật toán mạnh mẽ.

Chúng ta biết giới hạn tối thiểu của không gian bị lãng phí cho một vectơ là căn bậc hai của chiều dài của vectơ , nhưng dường như không có cách nào để thực hiện điều này trong Qt; các "tối ưu hóa" khác nhau mà họ hỗ trợ sẽ loại trừ tính năng tiết kiệm không gian rất quan trọng này. STL không yêu cầu tính năng này (và hầu hết sử dụng tăng trưởng gấp đôi, sẽ lãng phí hơn), nhưng điều quan trọng cần lưu ý là ít nhất bạn có thể thực hiện tính năng này, nếu cần.

Điều tương tự cũng đúng với các danh sách được liên kết đôi, có thể sử dụng liên kết XOr để giảm đáng kể dung lượng sử dụng. Một lần nữa, điều này là không thể với Qt, do yêu cầu của nó đối với tăng trưởng và COW.

COW thực sự có thể làm cho thứ gì đó nhẹ hơn, nhưng các Intrusive Container cũng có thể, như được hỗ trợ bởi boost và Qt đã sử dụng chúng thường xuyên trong các phiên bản trước, nhưng chúng không được sử dụng nhiều nữa vì chúng khó sử dụng, không an toàn và gây gánh nặng về lập trình viên. COW là một giải pháp ít xâm phạm hơn, nhưng không hấp dẫn vì những lý do nêu trên.

Không có lý do tại sao bạn không thể sử dụng các bộ chứa STL với cùng chi phí bộ nhớ hoặc ít hơn bộ chứa của Qt, với lợi ích bổ sung là thực sự biết bạn sẽ lãng phí bao nhiêu bộ nhớ tại bất kỳ thời điểm nào. Thật không may, không thể so sánh hai cách sử dụng bộ nhớ thô, bởi vì các điểm chuẩn như vậy sẽ cho thấy kết quả rất khác nhau trong các trường hợp sử dụng khác nhau, đây là loại vấn đề chính xác mà STL được thiết kế để khắc phục.

Tóm lại là

Tránh sử dụng Bộ chứa Qt khi có thể làm như vậy mà không áp dụng chi phí sao chép và sử dụng phép lặp loại STL (có thể thông qua trình bao bọc hoặc cú pháp mới), bất cứ khi nào có thể.

Container STL:

• Có đảm bảo hiệu suất
• Có thể được sử dụng trong các thuật toán STL cũng có đảm bảo hiệu suất
• Có thể được các thư viện C ++ của bên thứ ba tận dụng như Boost
• Là tiêu chuẩn, và có khả năng tồn tại lâu hơn các giải pháp độc quyền
• Khuyến khích lập trình chung các thuật toán và cấu trúc dữ liệu. Nếu bạn viết các thuật toán và cấu trúc dữ liệu mới phù hợp với STL, bạn có thể tận dụng những gì STL đã cung cấp miễn phí.

Các thùng chứa Qt sử dụng thành ngữ copy-on-write.

Một trong những vấn đề chính là API của Qt mong bạn cung cấp dữ liệu trong các thùng chứa của Qt, vì vậy bạn cũng có thể chỉ cần sử dụng các thùng chứa Qt thay vì chuyển đổi qua lại giữa hai.

Ngoài ra, nếu bạn đã sử dụng các bộ chứa Qt, có thể sử dụng chúng một cách tối ưu hơn một chút, vì bạn sẽ không phải bao gồm các tệp tiêu đề STL và có khả năng liên kết trong các thư viện STL. Tuy nhiên, tùy thuộc vào chuỗi công cụ của bạn, điều đó có thể xảy ra bằng mọi cách. Hoàn toàn từ quan điểm thiết kế, tính nhất quán nói chung là một điều tốt.

Nếu dữ liệu bạn đang làm việc chủ yếu được sử dụng để điều khiển UI dựa trên Qt, thì chắc chắn sử dụng các thùng chứa Qt.

Nếu dữ liệu chủ yếu được sử dụng nội bộ trong ứng dụng và bạn sẽ không bao giờ chuyển khỏi Qt, sau đó chặn các vấn đề về hiệu suất, hãy sử dụng các thùng chứa Qt vì nó sẽ giúp xử lý các bit dữ liệu đến UI dễ dàng hơn.

Nếu dữ liệu chủ yếu được sử dụng cùng với các thư viện khác chỉ biết về các thùng chứa STL, thì hãy sử dụng các thùng chứa STL. Nếu bạn gặp phải tình huống này, bạn sẽ gặp rắc rối, không có vấn đề gì vì bạn sẽ thực hiện nhiều thao tác chuyển qua lại giữa các loại container cho dù bạn có làm gì đi nữa.

Bên cạnh sự khác biệt COW, các container STL được hỗ trợ rộng rãi hơn nhiều trên nhiều nền tảng khác nhau. Qt đủ khả năng di động nếu bạn giới hạn công việc của mình ở các nền tảng "chính thống", nhưng STL cũng có sẵn trên nhiều nền tảng khó hiểu khác (ví dụ, DSP của Texas Cụ).

Bởi vì STL là tiêu chuẩn chứ không phải do một công ty duy nhất kiểm soát, nói chung, có nhiều lập trình viên có thể dễ dàng đọc, hiểu và sửa đổi mã STL và nhiều tài nguyên hơn (sách, diễn đàn trực tuyến, hội nghị, v.v.) để hỗ trợ họ làm điều này hơn là cho Qt. Điều đó không có nghĩa là người ta nên tránh xa Qt chỉ vì lý do này; chỉ là, tất cả những thứ khác đều bằng nhau, bạn nên mặc định với STL, nhưng tất nhiên tất cả mọi thứ hiếm khi bằng nhau, vì vậy bạn sẽ phải quyết định trong bối cảnh của riêng bạn có ý nghĩa nhất.

Liên quan đến câu trả lời của AlexKR: hiệu suất STL được đảm bảo trong giới hạn, nhưng việc triển khai nhất định có thể sử dụng các chi tiết phụ thuộc vào nền tảng để tăng tốc STL của họ. Vì vậy, theo nghĩa đó, bạn có thể nhận được các kết quả khác nhau trên các nền tảng khác nhau, nhưng nó sẽ không bao giờ chậm hơn bảo đảm rõ ràng (lỗi modulo).

Năm xu của tôi: Các thùng chứa Qt được cho là hoạt động tương tự trên các nền tảng khác nhau. Trong khi các container STL phụ thuộc vào việc thực hiện STL. Bạn có thể nhận được kết quả hiệu suất khác nhau.

EDIT: Tôi không nói rằng STL là "chậm hơn" nhưng tôi chỉ ra tác động của các chi tiết thực hiện khác nhau.
Vui lòng kiểm tra cái này , và sau đó có thể cái này .
Và nó không phải là một vấn đề thực sự của STL. Rõ ràng, nếu bạn có sự khác biệt đáng kể về hiệu suất, thì có vấn đề trong mã sử dụng STL.

Tôi đoán nó phụ thuộc vào cách bạn sử dụng Qt. Nếu bạn sử dụng nó trên tất cả các sản phẩm của bạn, thì có lẽ nên sử dụng các thùng chứa Qt. Nếu bạn chỉ chứa nó (ví dụ) phần UI, có thể tốt hơn là sử dụng các thùng chứa tiêu chuẩn C ++.

Tôi cho rằng STL là một phần mềm xuất sắc, tuy nhiên nếu tôi thực hiện một số chương trình liên quan đến KDE hoặc Qt thì Qt là con đường để đi. Ngoài ra, nó phụ thuộc vào trình biên dịch bạn đang sử dụng, với GCC STL hoạt động khá tốt tuy nhiên nếu bạn phải sử dụng SUN Studio CC thì STL rất có thể sẽ khiến bạn đau đầu vì trình biên dịch không phải STL mỗi lần. Trong trường hợp đó vì trình biên dịch sẽ làm cho đầu bạn bị tổn thương, chỉ cần sử dụng Qt để cứu bạn khỏi rắc rối. Chỉ 2 xu của tôi ...

Có một hạn chế (đôi khi) lớn trong QVector. Nó chỉ có thể phân bổ int byte bộ nhớ (lưu ý rằng giới hạn tính bằng byte không theo số lượng phần tử). Điều này ngụ ý rằng việc cố gắng phân bổ các khối bộ nhớ liền kề lớn hơn ~ 2GB với QVector sẽ dẫn đến sự cố. Điều này xảy ra với Qt 4 và 5. std :: vector không có giới hạn như vậy.

Lý do chính để đi với các container STL cho tôi là nếu bạn cần một bộ cấp phát tùy chỉnh để sử dụng lại bộ nhớ trong các thùng chứa rất lớn. Ví dụ, giả sử bạn có QMap lưu trữ 1000000 mục (cặp khóa / giá trị). Trong Qt ngụ ý chính xác 1000000 triệu phân bổ ( newcuộc gọi) không có vấn đề gì. Trong STL, bạn luôn có thể tạo một bộ cấp phát tùy chỉnh phân bổ nội bộ tất cả bộ nhớ đó cùng một lúc và gán nó cho từng mục khi bản đồ được điền.

Lời khuyên của tôi là sử dụng các thùng chứa STL khi viết các thuật toán quan trọng về hiệu suất trong logic nghiệp vụ và sau đó chuyển đổi chúng trở lại thành các thùng chứa Qt khi kết quả đã sẵn sàng bằng cách hiển thị bởi các điều khiển và biểu mẫu UI của bạn nếu cần.