ทำไมทุกคนจะใช้ชุดแทน unordered_set

C ++ 0x กำลังแนะนำunordered_setซึ่งมีอยู่ในboostและที่อื่น ๆ อีกมากมาย สิ่งที่ฉันเข้าใจคือunordered_setตารางแฮชที่มีO(1)ความซับซ้อนในการค้นหา ในทางตรงกันข้ามsetไม่มีอะไรเลยนอกจากต้นไม้ที่มีlog(n)ความซับซ้อนในการค้นหา ทำไมทุกคนบนโลกจะใช้setแทนunordered_set? เช่นมีความต้องการsetอีกต่อไปหรือไม่

เมื่อใดสำหรับคนที่ต้องการทำซ้ำสิ่งต่างๆในชุดคำสั่งจะมีความสำคัญ

ชุดที่ไม่ได้สั่งซื้อจะต้องจ่ายค่า O (1) เวลาในการเข้าถึงโดยเฉลี่ยในสองสามวิธี:

• set การใช้งาน หน่วยความจำน้อยกว่าunordered_setเพื่อเก็บองค์ประกอบจำนวนเดียวกัน
• สำหรับองค์ประกอบจำนวนน้อยการค้นหาsetอาจจะเป็นเร็วขึ้นunordered_setกว่าการค้นหาใน
• แม้ว่าการดำเนินการจำนวนมากจะเร็วกว่าในกรณีทั่วไปสำหรับunordered_setพวกเขามักจะรับประกันว่าจะมีความซับซ้อนกรณีที่เลวร้ายที่สุดที่ดีกว่าสำหรับset(ตัวอย่างinsert)
• การset เรียงลำดับองค์ประกอบนั้นมีประโยชน์หากคุณต้องการเข้าถึงตามลำดับ
• คุณสามารถlexicographically เปรียบเทียบที่แตกต่างกันsetS กับ<, <=, และ> ไม่จำเป็นต้องใช้เพื่อสนับสนุนการดำเนินการเหล่านี้>=unordered_set

เมื่อใดก็ตามที่คุณชอบต้นไม้ไปที่โต๊ะแฮช

ตัวอย่างเช่นตารางแฮชคือ "O (n)" ในกรณีที่เลวร้ายที่สุด O (1) เป็นตัวพิมพ์เล็กโดยเฉลี่ย ต้นไม้คือ "O (บันทึก n)" ที่เลวร้ายที่สุด

ใช้ตั้งเมื่อ:

1. เราต้องการข้อมูลที่สั่งซื้อ (องค์ประกอบที่แตกต่าง)
2. เราจะต้องพิมพ์ / เข้าถึงข้อมูล (เรียงตามลำดับ)
3. เราต้องการบรรพบุรุษ / ผู้สืบทอดองค์ประกอบ

ใช้ unordered_set เมื่อ:

1. เราจำเป็นต้องเก็บชุดขององค์ประกอบที่แตกต่างและไม่จำเป็นต้องสั่งซื้อ
2. เราต้องการการเข้าถึงองค์ประกอบเดียวคือไม่มีการแวะผ่าน

ตัวอย่าง:

ตั้ง:

อินพุต: 1, 8, 2, 5, 3, 9

เอาต์พุต: 1, 2, 3, 5, 8, 9

Unordered_set:

อินพุต: 1, 8, 2, 5, 3, 9

ผลลัพธ์: 9 3 1 8 2 5 (อาจจะเป็นคำสั่งนี้ได้รับอิทธิพลจากฟังก์ชั่นแฮช)

ความแตกต่างส่วนใหญ่:

หมายเหตุ: (ในบางกรณีsetสะดวกกว่า) ตัวอย่างเช่นใช้vectorเป็นคีย์

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 

สาเหตุที่vector<int>สามารถเป็นกุญแจสำคัญในsetเพราะการvectorแทนที่operator<แทนที่

แต่ถ้าคุณใช้unordered_set<vector<int>>คุณต้องสร้างฟังก์ชันแฮชvector<int>เพราะ vector ไม่มีฟังก์ชันแฮชดังนั้นคุณต้องกำหนดหนึ่งอย่าง:

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
}

คุณจะเห็นว่าในบางกรณี unordered_setมีความซับซ้อนมากขึ้น

ส่วนใหญ่อ้างจาก: https://www.geeksforgeeks.org/set-vs-unordered_set-c-stl/ https://stackoverflow.com/a/29855973/6329006

เนื่องจาก std :: set เป็นส่วนหนึ่งของ Standard C ++ และ unordered_set ไม่ใช่ C ++ 0x ไม่ใช่มาตรฐานและไม่ใช่ Boost สำหรับพวกเราหลายคนความสะดวกในการพกพาเป็นสิ่งสำคัญและนั่นหมายถึงการยึดมั่นในมาตรฐาน

พิจารณาอัลกอริทึม sweepline อัลกอริทึมเหล่านี้อาจล้มเหลวอย่างสิ้นเชิงกับตารางแฮช แต่ทำงานได้อย่างสวยงามกับต้นไม้ที่สมดุล เพื่อให้ตัวอย่างที่เป็นรูปธรรมของอัลกอริทึม sweepline ให้พิจารณาอัลกอริทึมของฟอร์จูน http://en.wikipedia.org/wiki/Fortune%27s_algorithm

อีกสิ่งหนึ่งนอกเหนือจากสิ่งที่คนอื่นพูดถึงแล้ว ในขณะที่ความซับซ้อนที่คาดว่าจะถูกตัดค่าใช้จ่ายสำหรับการแทรกองค์ประกอบไปยัง unordered_set คือ O (1) ทุก ๆ คราวจากนั้นจะใช้ O (n) เนื่องจากตารางแฮชจำเป็นต้องได้รับการปรับโครงสร้างใหม่ (จำนวนถังต้องเปลี่ยน) - แม้ด้วย ฟังก์ชันแฮช 'ดี' เช่นเดียวกับการแทรกองค์ประกอบในเวกเตอร์ใช้เวลา O (n) ทุก ๆ ครั้งแล้วเพราะอาร์เรย์ที่ต้องถูกจัดสรรใหม่

การแทรกในชุดจะใช้เวลาไม่เกิน O (ล็อก n) นี่อาจเป็นที่นิยมในบางแอปพลิเคชัน

ให้อภัยฉันอีกสิ่งหนึ่งที่ควรสังเกตเกี่ยวกับสถานที่ให้บริการที่จัดเรียง:

ถ้าคุณต้องการช่วงของข้อมูลในคอนเทนเนอร์ตัวอย่างเช่น: คุณเก็บเวลาไว้ในชุดและคุณต้องการเวลาตั้งแต่ 2013-01-01 ถึง 2014-01-01

สำหรับunordered_setมันเป็นไปไม่ได้

แน่นอนตัวอย่างนี้จะมีมากขึ้นน่าเชื่อสำหรับกรณีการใช้งานระหว่างแผนที่และunordered_map

g++ 6.4 stdlibc ++ สั่งเทียบกับชุดมาตรฐานที่ไม่เรียงลำดับ

ฉันเปรียบเทียบการใช้ Linux C ++ ที่โดดเด่นนี้เพื่อดูความแตกต่าง:

รายละเอียดมาตรฐานและการวิเคราะห์เต็มรูปแบบได้รับที่: โครงสร้างข้อมูลพื้นฐานของชุด STL ใน C ++ คืออะไร?และฉันจะไม่ทำซ้ำพวกเขาที่นี่

"BST" หมายถึง "การทดสอบกับstd::setและ 'แผนที่กัญชา' หมายถึง" std::unordered_setการทดสอบกับ "Heap" เป็นstd::priority_queueสิ่งที่ฉันวิเคราะห์ที่: Heap vs Binary Search Tree (BST)

สรุปโดยย่อ:

• กราฟแสดงให้เห็นอย่างชัดเจนว่าภายใต้เงื่อนไขเหล่านี้การแทรก hashmap จะเร็วกว่าเสมอเมื่อมีรายการมากกว่า 100k และความแตกต่างก็เพิ่มขึ้นเมื่อจำนวนรายการเพิ่มขึ้น

  ต้นทุนของการเพิ่มความเร็วนี้คือคุณไม่สามารถท่องไปตามลำดับได้อย่างมีประสิทธิภาพ

• เส้นโค้งชัดเจนแนะนำว่าสั่งstd::setเป็น BST-based และstd::unordered_setเป็น hashmap ในคำตอบอ้างอิงฉันยืนยันต่อไปว่าโดย GDB ขั้นตอนการแก้จุดบกพร่องรหัส

คำถามที่คล้ายกันสำหรับmapvs unordered_map: มีข้อได้เปรียบของการใช้แผนที่บน unordered_map ในกรณีที่เป็นกุญแจสำคัญหรือไม่?

มือฉันจะบอกว่ามันสะดวกที่จะมีสิ่งต่าง ๆ ในความสัมพันธ์หากคุณต้องการแปลงมันให้อยู่ในรูปแบบที่แตกต่างกัน

นอกจากนี้ยังเป็นไปได้ว่าในขณะที่หนึ่งเข้าถึงได้เร็วขึ้นเวลาในการสร้างดัชนีหรือหน่วยความจำที่ใช้เมื่อสร้างและ / หรือเข้าถึงได้มากขึ้น

หากคุณต้องการเรียงลำดับสิ่งต่าง ๆ คุณจะต้องใช้ set แทน unordered_set unordered_set ใช้เกินชุดเมื่อสั่งซื้อที่เก็บไว้ไม่สำคัญ

ในขณะที่คำตอบนี้อาจใช้เวลา 10 ปี แต่ก็คุ้มค่าที่จะชี้ให้เห็นว่าstd::unordered_setยังมีข้อเสียด้านความปลอดภัย

หากฟังก์ชั่นแฮชสามารถคาดเดาได้ (โดยทั่วไปจะเป็นกรณีนี้ยกเว้นว่าจะใช้มาตรการตอบโต้เช่นเกลือแบบสุ่ม) ผู้โจมตีสามารถส่งข้อมูลด้วยมือที่สร้างการชนกันของแฮชและทำให้การแทรกและค้นหาทั้งหมดใช้เวลา O (n) .

สิ่งนี้สามารถใช้สำหรับการโจมตีแบบปฏิเสธการให้บริการที่มีประสิทธิภาพและสวยงาม

การใช้งานหลายภาษา (ส่วนใหญ่) ของภาษาที่ใช้แผนที่แฮชภายในได้พบกับสิ่งนี้:

• จาวาสคริ
• PHP
• ชวา