Tại sao mọi người sẽ sử dụng set thay vì unordered_set?

C ++ 0x đang giới thiệu unordered_setcó sẵn ở boostnhiều nơi khác. Điều tôi hiểu là unordered_setbảng băm với O(1)độ phức tạp tra cứu. Mặt khác, setkhông có gì ngoài một cái cây với log(n)sự phức tạp tra cứu. Tại sao trên trái đất mọi người sẽ sử dụng setthay vì unordered_set? tức là có cần thiết setnữa không?

Khi, đối với ai đó muốn lặp đi lặp lại các mục của tập hợp, thứ tự quan trọng.

Các bộ không có thứ tự phải trả tiền cho thời gian truy cập trung bình O (1) của chúng theo một số cách:

• setsử dụng ít bộ nhớ hơn unordered_setđể lưu trữ cùng một số phần tử.
• Đối với một số lượng nhỏ các yếu tố , tra cứu trong một setcó thể nhanh hơn tra cứu trong một unordered_set.
• Mặc dù nhiều hoạt động được nhanh hơn trong trường hợp trung bình cho unordered_set, chúng thường được đảm bảo để có tốt hơn trường hợp xấu nhất phức tạp cho set(ví dụ insert).
• Điều đó set sắp xếp các yếu tố hữu ích nếu bạn muốn truy cập chúng theo thứ tự.
• Bạn có thể tự từ điển so sánh khác nhau sets với <, <=, >và >=. unordered_sets không cần thiết để hỗ trợ các hoạt động này.

Bất cứ khi nào bạn thích một cây cho bảng băm.

Ví dụ, các bảng băm là "O (n)" trong trường hợp xấu nhất. O (1) là trường hợp trung bình. Cây là "O ( log n)" tồi tệ nhất.

Sử dụng thiết lập khi:

1. Chúng tôi cần dữ liệu theo thứ tự (các yếu tố riêng biệt).
2. Chúng tôi sẽ phải in / truy cập dữ liệu (theo thứ tự được sắp xếp).
3. Chúng ta cần người tiền nhiệm / kế thừa các yếu tố.

Sử dụng unordered_set khi:

1. Chúng ta cần giữ một tập hợp các yếu tố riêng biệt và không yêu cầu đặt hàng.
2. Chúng ta cần truy cập phần tử đơn tức là không có giao dịch.

Ví dụ:

bộ:

Đầu vào: 1, 8, 2, 5, 3, 9

Đầu ra: 1, 2, 3, 5, 8, 9

Không có thứ tự_set:

Đầu vào: 1, 8, 2, 5, 3, 9

Đầu ra: 9 3 1 8 2 5 (có thể là thứ tự này, bị ảnh hưởng bởi hàm băm)

Khác biệt chủ yếu:

Lưu ý: (trong một số trường hợp setthuận tiện hơn) ví dụ sử dụng vectorlàm khóa

set<vector<int>> s;
s.insert({1, 2});
s.insert({1, 3});
s.insert({1, 2});

for(const auto& vec:s)
    cout<<vec<<endl;   // I have override << for vector
// 1 2
// 1 3 

Lý do tại sao vector<int>có thể là chìa khóa setvì vectorghi đè operator<.

Nhưng nếu bạn sử dụng, unordered_set<vector<int>>bạn phải tạo hàm băm cho vector<int>, vì vectơ không có hàm băm, vì vậy bạn phải xác định một hàm như:

struct VectorHash {
    size_t operator()(const std::vector<int>& v) const {
        std::hash<int> hasher;
        size_t seed = 0;
        for (int i : v) {
            seed ^= hasher(i) + 0x9e3779b9 + (seed<<6) + (seed>>2);
        }
        return seed;
    }
};

vector<vector<int>> two(){
    //unordered_set<vector<int>> s; // error vector<int> doesn't  have hash function
    unordered_set<vector<int>, VectorHash> s;
    s.insert({1, 2});
    s.insert({1, 3});
    s.insert({1, 2});

    for(const auto& vec:s)
        cout<<vec<<endl;
    // 1 2
    // 1 3
}

bạn có thể thấy rằng trong một số trường hợp unordered_setphức tạp hơn.

Chủ yếu được trích dẫn từ: https://www.geekforgeek.org/set-vs-unordered_set-c-stl/ https://stackoverflow.com/a/29855973/6329006

Bởi vì std :: set là một phần của Standard C ++ và unordered_set thì không. C ++ 0x KHÔNG phải là tiêu chuẩn và cũng không phải là Boost. Đối với nhiều người trong chúng ta, tính di động là cần thiết và điều đó có nghĩa là tuân thủ tiêu chuẩn.

Hãy xem xét các thuật toán quét. Các thuật toán này sẽ thất bại hoàn toàn với các bảng băm, nhưng hoạt động rất đẹp với các cây cân bằng. Để cung cấp cho bạn một ví dụ cụ thể về thuật toán quét, hãy xem xét thuật toán vận may. http://en.wikipedia.org/wiki/Fortune%27s_alacticm

Một điều nữa, ngoài những gì người khác đã đề cập. Mặc dù độ phức tạp được khấu hao dự kiến ​​để chèn một phần tử vào unordered_set là O (1), mọi lúc và sau đó sẽ mất O (n) vì bảng băm cần phải được cấu trúc lại (số lượng xô cần thay đổi) - ngay cả với hàm băm 'tốt'. Giống như việc chèn một phần tử trong một vectơ sẽ mất O (n) mỗi lần bởi vì mảng bên dưới cần được phân bổ lại.

Chèn vào một bộ luôn mất tối đa O (log n). Điều này có thể được ưa thích trong một số ứng dụng.

Xin lỗi, một điều đáng chú ý nữa về tài sản được sắp xếp:

Nếu bạn muốn một phạm vi dữ liệu trong vùng chứa, ví dụ: Bạn đã lưu trữ thời gian trong tập hợp và bạn muốn có thời gian từ 2013-01-01 đến 2014-01-01.

Đối với unordered_set thì không thể.

Tất nhiên, ví dụ này sẽ thuyết phục hơn cho các trường hợp sử dụng giữa bản đồ và unordered_map .

g++ 6.4 stdlibc ++ đã đặt hàng so với điểm chuẩn thiết lập không có thứ tự

Tôi đã điểm chuẩn việc triển khai Linux C ++ vượt trội này để thấy sự khác biệt:

Các chi tiết và phân tích điểm chuẩn đầy đủ đã được đưa ra tại: Cấu trúc dữ liệu cơ bản của bộ STL trong C ++ là gì? và tôi sẽ không lặp lại chúng ở đây.

"BST" có nghĩa là "được thử nghiệm với std::setvà" bản đồ băm "có nghĩa là" được thử nghiệm với std::unordered_set. "Heap" là std::priority_queuecái mà tôi đã phân tích tại: Heap vs Binary Search Tree (BST)

Tóm tắt nhanh:

• biểu đồ cho thấy rõ ràng trong các điều kiện này, việc chèn hashmap luôn nhanh hơn rất nhiều khi có hơn 100 nghìn mục và sự khác biệt tăng lên khi số lượng mục tăng lên

  Chi phí cho việc tăng tốc độ này là bạn không thể di chuyển hiệu quả theo thứ tự.

• các đường cong gợi ý rõ ràng rằng thứ tự std::setlà dựa trên BST và dựa trên hàm std::unordered_setbăm. Trong câu trả lời tham khảo, tôi xác nhận thêm rằng bằng bước GDB gỡ lỗi mã.

Câu hỏi tương tự cho mapvs unordered_map: Có bất kỳ lợi thế nào của việc sử dụng bản đồ so với unordered_map trong trường hợp các khóa tầm thường không?

Nói chung, tôi sẽ nói thật thuận tiện khi có những thứ trong một mối quan hệ nếu bạn đang muốn chuyển đổi nó sang một định dạng khác.

Cũng có thể trong khi một người truy cập nhanh hơn, thời gian để xây dựng chỉ mục hoặc bộ nhớ được sử dụng khi tạo và / hoặc truy cập vào nó là lớn hơn.

Nếu bạn muốn sắp xếp mọi thứ, thì bạn sẽ sử dụng set thay vì unordered_set. unordered_set được sử dụng qua bộ khi đặt hàng được lưu trữ không quan trọng.

Mặc dù câu trả lời này có thể trễ 10 năm, nhưng đáng để chỉ ra rằng nó std::unordered_setcũng có nhược điểm về bảo mật.

Nếu chức năng băm có thể dự đoán được (điều này thường xảy ra trừ khi áp dụng các biện pháp đối phó như muối ngẫu nhiên), kẻ tấn công có thể tự tạo dữ liệu tạo ra va chạm băm và khiến tất cả các lần chèn và tra cứu mất thời gian O (n) .

Điều này có thể được sử dụng cho các cuộc tấn công từ chối dịch vụ rất hiệu quả và thanh lịch.

Nhiều (hầu hết?) Các ngôn ngữ sử dụng bản đồ băm trong nội bộ đã chạy vào đây:

• Javascript
• PHP
• Java