ความถูกต้องตามกฎหมายของ COW std :: การใช้สตริงใน C ++ 11

เป็นความเข้าใจของฉันที่ว่าการคัดลอกเมื่อเขียนไม่ใช่วิธีที่เป็นไปได้std::stringในการนำการปฏิบัติตามC ++ 11 มาใช้ แต่เมื่อมีการอภิปรายเมื่อเร็ว ๆ นี้ฉันพบว่าตัวเองไม่สามารถสนับสนุนคำพูดนั้นได้โดยตรง

ฉันถูกต้องหรือไม่ที่ C ++ 11 ไม่ยอมรับการใช้งาน COW ของstd::string?

หากเป็นเช่นนั้นข้อ จำกัด นี้มีการระบุไว้อย่างชัดเจนในมาตรฐานใหม่ (ที่ไหน) หรือไม่?

หรือข้อ จำกัด นี้โดยนัยในแง่ที่ว่ามันเป็นผลรวมของความต้องการใหม่ในติ๊ดว่าการดำเนินการตามวัวของstd::string std::stringในกรณีนี้ฉันสนใจในบทและรูปแบบกลอนที่มาของ 'C ++ 11 ห้ามใช้std::stringงานCOW อย่างมีประสิทธิภาพ'

ไม่อนุญาตเนื่องจากตามมาตรฐาน 21.4.1 p6 อนุญาตให้ใช้ตัวทำซ้ำ / การอ้างอิงไม่ถูกต้องสำหรับ

- เป็นอาร์กิวเมนต์ของฟังก์ชันไลบรารีมาตรฐานใด ๆ โดยอ้างถึง non-const basic_string เป็นอาร์กิวเมนต์

- การเรียกใช้ฟังก์ชันที่ไม่ใช่สมาชิก const ยกเว้นตัวดำเนินการ [], ที่, ด้านหน้า, ด้านหลัง, เริ่มต้น, rbegin, สิ้นสุดและการแสดงผล

สำหรับสตริง COW การเรียก non-const operator[]จะต้องมีการทำสำเนา (และการอ้างอิงที่ไม่ถูกต้อง) ซึ่งย่อหน้าข้างบนไม่อนุญาต ดังนั้นจึงไม่ถูกกฎหมายอีกต่อไปที่จะมีสตริง COW ใน C ++ 11

คำตอบโดยเดฟ Sและ gbjbaanbมีความถูกต้อง (และของ Luc Danton ก็ถูกต้องเช่นกันแม้ว่าจะเป็นผลข้างเคียงของการห้ามสตริง COW มากกว่ากฎเดิมที่ห้ามก็ตาม)

แต่เพื่อล้างความสับสนฉันจะเพิ่มการอธิบายเพิ่มเติม ความคิดเห็นต่างๆเชื่อมโยงไปยังความคิดเห็นของฉันใน Bugzilla GCCซึ่งให้ตัวอย่างต่อไปนี้:

std::string s("str");
const char* p = s.data();
{
    std::string s2(s);
    (void) s[0];
}
std::cout << *p << '\n';  // p is dangling

ประเด็นของตัวอย่างนั้นคือการแสดงให้เห็นว่าเหตุใดสตริงการนับการอ้างอิง (COW) ของ GCC จึงไม่ถูกต้องใน C ++ 11 มาตรฐาน C ++ 11 กำหนดให้รหัสนี้ทำงานได้อย่างถูกต้อง ไม่มีสิ่งใดในรหัสที่อนุญาตpให้ใช้งานไม่ได้ใน C ++ 11

ใช้อ้างอิงนับ GCC เก่าของstd::stringการดำเนินการตามรหัสที่มีพฤติกรรมที่ไม่ได้กำหนดเพราะp เป็นโมฆะกลายเป็นตัวชี้ห้อย (สิ่งที่เกิดขึ้นคือเมื่อs2ถูกสร้างขึ้นจะแชร์ข้อมูลด้วยsแต่การได้รับการอ้างอิงที่ไม่ใช่ const ผ่านs[0]จำเป็นต้องมีการยกเลิกการแชร์ข้อมูลดังนั้นs"copy on write" ก็เช่นกันเนื่องจากการอ้างอิงs[0]อาจถูกใช้เพื่อเขียนลงไปsจากนั้นจึงs2ไป อยู่นอกขอบเขตทำลายอาร์เรย์ที่ชี้โดยp)

มาตรฐาน C ++ 03 อนุญาตให้มีพฤติกรรมนั้นอย่างชัดเจนใน 21.3 [lib.basic.string] p5 โดยระบุว่าหลังจากการเรียกไปยังdata()การเรียกครั้งแรกถึงoperator[]()อาจทำให้ตัวชี้การอ้างอิงและตัวทำซ้ำเป็นโมฆะ ดังนั้นสตริง COW ของ GCC จึงเป็นการใช้งาน C ++ 03 ที่ถูกต้อง

มาตรฐาน C ++ 11 ไม่อนุญาตให้เกิดพฤติกรรมนั้นอีกต่อไปเนื่องจากการไม่เรียกไปยังoperator[]()อาจทำให้ตัวชี้การอ้างอิงหรือตัวทำซ้ำเป็นโมฆะโดยไม่คำนึงว่าพวกเขาจะติดตามการเรียกร้องdata()หรือไม่

ดังนั้นตัวอย่างข้างต้นต้องทำงานใน C ++ 11 แต่ใช้ไม่ได้กับสตริง COW ของ libstdc ++ ดังนั้นสตริง COW ชนิดนั้นจึงไม่ได้รับอนุญาตใน C ++ 11

CoW เป็นกลไกที่ยอมรับได้ในการสร้างสตริงที่เร็วขึ้น ... แต่ ...

มันทำให้โค้ดมัลติเธรดช้าลง (การล็อกทั้งหมดเพื่อตรวจสอบว่าคุณเป็นคนเดียวที่เขียนเพียงคนเดียวจะฆ่าประสิทธิภาพหรือไม่เมื่อใช้สตริงจำนวนมาก) นี่คือสาเหตุหลักที่ CoW ถูกสังหารเมื่อหลายปีก่อน

เหตุผลอื่น ๆ คือตัว[]ดำเนินการจะส่งคืนข้อมูลสตริงให้คุณโดยไม่มีการป้องกันใด ๆ ให้คุณเขียนทับสตริงที่คนอื่นคาดว่าจะไม่เปลี่ยนแปลง เช่นเดียวกับและc_str()data()

Quick google บอกว่าโดยพื้นฐานแล้วการมัลติเธรดเป็นสาเหตุที่ไม่ได้รับอนุญาตอย่างมีประสิทธิภาพ (ไม่ชัดเจน)

ข้อเสนอกล่าวว่า:

ข้อเสนอ

เราขอเสนอให้ดำเนินการตัววนซ้ำและการเข้าถึงองค์ประกอบทั้งหมดพร้อมกันอย่างปลอดภัย

เรากำลังเพิ่มความเสถียรของการดำเนินการแม้ในรหัสต่อเนื่อง

การเปลี่ยนแปลงนี้ปิดกั้นการใช้งานแบบ copy-on-write

ติดตามโดย

การสูญเสียประสิทธิภาพที่ใหญ่ที่สุดเนื่องจากการเปลี่ยนจากการใช้งานแบบ copy-on-write คือการใช้หน่วยความจำที่เพิ่มขึ้นสำหรับแอปพลิเคชันที่มีสตริงการอ่านเป็นส่วนใหญ่ที่มีขนาดใหญ่มาก อย่างไรก็ตามเราเชื่อว่าสำหรับการใช้งานเชือกเหล่านั้นเป็นวิธีการแก้ปัญหาทางเทคนิคที่ดีกว่าและขอแนะนำให้พิจารณาข้อเสนอเชือกเพื่อรวมไว้ใน Library TR2

เชือกเป็นส่วนหนึ่งของ STLPort และ SGIs STL

จาก 21.4.2 basic_string constructor และตัวดำเนินการกำหนด [string.cons]

basic_string(const basic_string<charT,traits,Allocator>& str);

[ ... ]

2 เอฟเฟกต์ : สร้างออบเจ็กต์ของคลาสbasic_stringตามที่ระบุในตารางที่ 64 [... ]

ตารางที่ 64 เอกสารที่เป็นประโยชน์ว่าหลังจากสร้างวัตถุผ่านตัวสร้าง (สำเนา) นี้this->data()มีค่าดังนี้:

จุดที่องค์ประกอบ fi rst ของสำเนาที่จัดสรรของอาร์เรย์ซึ่งองค์ประกอบ fi rst ถูกชี้ไปที่ str.data ()

มีข้อกำหนดที่คล้ายกันสำหรับผู้สร้างอื่นที่คล้ายคลึงกัน

เนื่องจากตอนนี้มีการรับประกันว่าสตริงจะถูกจัดเก็บอย่างต่อเนื่องกันและตอนนี้คุณได้รับอนุญาตให้นำตัวชี้ไปยังที่จัดเก็บข้อมูลภายในของสตริง (เช่น & str [0] ทำงานเหมือนกับที่ทำกับอาร์เรย์) จึงไม่สามารถสร้าง COW ที่เป็นประโยชน์ได้ การดำเนินงาน คุณจะต้องทำสำเนาสำหรับหลาย ๆ อย่างเกินไป แม้แต่การใช้operator[]หรือbegin()บนสตริงที่ไม่ใช่ const ก็ต้องใช้สำเนา

basic_stringห้ามวัวใน C ++ 11 ขึ้นไปหรือไม่?

เกี่ยวกับ

”ฉันถูกต้องที่ C ++ 11 ไม่ยอมรับการใช้งานตามวัวของstd::string?

ใช่.

เกี่ยวกับ

”ถ้าเป็นเช่นนั้นข้อ จำกัด นี้มีการระบุไว้อย่างชัดเจนในมาตรฐานใหม่ (ที่ไหน) หรือไม่?

เกือบโดยตรงตามข้อกำหนดของความซับซ้อนคงที่สำหรับการดำเนินการหลายอย่างที่ต้องการ O ( n ) การคัดลอกข้อมูลสตริงทางกายภาพในการใช้งาน COW

ตัวอย่างเช่นสำหรับฟังก์ชันสมาชิก

auto operator[](size_type pos) const -> const_reference;
auto operator[](size_type pos) -> reference;

…ซึ่งในการใช้งาน COW จะทริกเกอร์การคัดลอกข้อมูลสตริงทั้งสองเพื่อยกเลิกการแชร์ค่าสตริงมาตรฐาน C ++ 11 ต้องการ

" ความซับซ้อน:เวลาคงที่

…ซึ่งออกกฎการคัดลอกข้อมูลดังกล่าวและด้วยเหตุนี้ COW

C ++ 03 ได้รับการสนับสนุนการใช้งาน COW โดยไม่ได้มีความต้องการที่ซับซ้อนอย่างต่อเนื่องเหล่านี้และโดยภายใต้เงื่อนไขที่เข้มงวดบางอย่างที่ช่วยให้โทรไปoperator[](), at(), begin(), rbegin(), end()หรือrend()อ้างอิงโมฆะตัวชี้และ iterators หมายถึงรายการสตริงเช่นจะอาจเกิดขึ้น การคัดลอกข้อมูล COW การสนับสนุนนี้ถูกลบออกใน C ++ 11

ห้ามวัวผ่านกฎการยกเลิก C ++ 11 ด้วยหรือไม่

ในคำตอบอื่นซึ่งในขณะที่เขียนถูกเลือกให้เป็นวิธีแก้ปัญหาและซึ่งได้รับการโหวตอย่างมากและเห็นได้ชัดว่ามีการยืนยันว่า

"สำหรับสตริง COW การเรียกแบบไม่const operator[]ต้องทำสำเนา (และการอ้างอิงที่ไม่ถูกต้อง) ซึ่งไม่อนุญาตโดยย่อหน้า [ที่ยกมา] ด้านบน [C ++ 11 §21.4.1 / 6] ดังนั้นจึงไม่ถูกกฎหมายอีกต่อไปที่จะมีสตริง COW ใน C ++ 11

การยืนยันนั้นไม่ถูกต้องและทำให้เข้าใจผิดในสองวิธีหลัก:

• มันบ่งชี้อย่างไม่ถูกต้องว่าเฉพาะผู้เข้าถึงที่ไม่ใช่constรายการเท่านั้นที่ต้องทริกเกอร์การคัดลอกข้อมูล COW
  แต่ผู้เข้าถึงconstรายการจำเป็นต้องทริกเกอร์การคัดลอกข้อมูลเนื่องจากอนุญาตให้รหัสไคลเอ็นต์สร้างการอ้างอิงหรือตัวชี้ที่ (ใน C ++ 11) ไม่อนุญาตให้ยกเลิกการใช้งานในภายหลังผ่านการดำเนินการที่สามารถทริกเกอร์การคัดลอกข้อมูล COW
• สันนิษฐานอย่างไม่ถูกต้องว่าการคัดลอกข้อมูล COW อาจทำให้การอ้างอิงไม่ถูกต้อง
  แต่ในการนำไปใช้งานที่ถูกต้องการคัดลอกข้อมูล COW การยกเลิกการแชร์ค่าสตริงจะกระทำ ณ จุดหนึ่งก่อนที่จะมีการอ้างอิงใด ๆ ที่อาจทำให้ไม่ถูกต้องได้

หากต้องการดูว่าการใช้งาน C ++ 11 COW ที่ถูกต้องbasic_stringจะทำงานอย่างไรเมื่อข้อกำหนด O (1) ที่ทำให้ไม่ถูกต้องถูกละเว้นให้นึกถึงการใช้งานที่สตริงสามารถสลับระหว่างนโยบายการเป็นเจ้าของได้ อินสแตนซ์สตริงเริ่มต้นด้วย Policy Sharable เมื่อใช้นโยบายนี้แล้วจะไม่มีการอ้างอิงรายการภายนอก อินสแตนซ์สามารถเปลี่ยนไปใช้นโยบายที่ไม่ซ้ำกันได้และจะต้องดำเนินการดังกล่าวเมื่อมีการสร้างการอ้างอิงรายการเช่นด้วยการเรียกไปที่.c_str()(อย่างน้อยหากสร้างตัวชี้ไปยังบัฟเฟอร์ภายใน) ในกรณีทั่วไปของอินสแตนซ์หลายอินสแตนซ์ร่วมกันเป็นเจ้าของค่าสิ่งนี้เกี่ยวข้องกับการคัดลอกข้อมูลสตริง หลังจากนั้นการเปลี่ยนไปใช้นโยบายที่ไม่ซ้ำกันอินสแตนซ์จะเปลี่ยนกลับไปเป็นแชร์ได้โดยการดำเนินการที่ทำให้การอ้างอิงทั้งหมดเป็นโมฆะเช่นการมอบหมาย

ดังนั้นในขณะที่ข้อสรุปของคำตอบนั้นสตริง COW ถูกตัดออกนั้นถูกต้อง แต่เหตุผลที่เสนอนั้นไม่ถูกต้องและทำให้เข้าใจผิดอย่างมาก

ฉันสงสัยว่าสาเหตุของความเข้าใจผิดนี้เป็นบันทึกที่ไม่เป็นบรรทัดฐานในภาคผนวก C ของ C ++ 11:

การเปลี่ยนแปลง : basic_stringข้อกำหนดไม่อนุญาตให้ใช้สตริงที่นับการอ้างอิงอีกต่อไป
เหตุผล:การไม่ถูกต้องแตกต่างกันเล็กน้อยกับสตริงที่นับการอ้างอิง การเปลี่ยนแปลงนี้ทำให้พฤติกรรม (sic) เป็นปกติสำหรับมาตรฐานสากลนี้
ผลกระทบต่อคุณสมบัติดั้งเดิม:โค้ด C ++ 2003 ที่ถูกต้องอาจทำงานแตกต่างกันในมาตรฐานสากลนี้

นี่คือเหตุผลที่อธิบายถึงสาเหตุหลักว่าเหตุใดจึงตัดสินใจลบการสนับสนุนพิเศษ C ++ 03 COW เหตุผลนี้เหตุผลที่ไม่ได้เป็นวิธีมาตรฐานได้อย่างมีประสิทธิภาพไม่อนุญาตให้ดำเนินการ COW มาตรฐานไม่อนุญาต COW ผ่านข้อกำหนด O (1)

ในระยะสั้น, C ++ 11 std::basic_stringกฎโมฆะไม่ออกกฎการดำเนินงานของวัว แต่พวกเขาแยกแยะการใช้งาน COW สไตล์ C ++ 03 ที่มีประสิทธิภาพอย่างสมเหตุสมผลเช่นเดียวกับการใช้งานไลบรารีมาตรฐานของ g ++ อย่างน้อยหนึ่งอย่าง การสนับสนุน C ++ 03 COW แบบพิเศษช่วยให้สามารถใช้งานได้อย่างมีประสิทธิภาพโดยเฉพาะอย่างยิ่งการใช้ตัวเข้าถึงconstรายการโดยมีค่าใช้จ่ายของกฎที่ละเอียดอ่อนและซับซ้อนสำหรับการยกเลิกการใช้งาน:

"การอ้างอิงตัวชี้และตัวทำซ้ำที่อ้างถึงองค์ประกอบของbasic_stringลำดับอาจไม่ถูกต้องโดยการใช้งานต่อไปนี้ของbasic_stringวัตถุนั้น:
- เป็นอาร์กิวเมนต์สำหรับฟังก์ชันที่ไม่ใช่สมาชิกswap()(21.3.7.8), operator>>()(21.3.7.9) และgetline()(21.3. 7.9)
- เป็นข้อโต้แย้งbasic_string::swap()ของ
- ฟังก์ชั่นการโทรdata()และc_str()สมาชิก
- โทรที่ไม่ใช่constสมาชิกฟังก์ชันยกเว้นoperator[](), at(), begin(), rbegin(), และend() - ภายหลังการใด ๆ ของการใช้งานดังกล่าวข้างต้นยกเว้นรูปแบบของและที่กลับ iterators, สายแรกที่ไม่ใช่สมาชิกฟังก์ชัน, , , ,rend()
insert()erase()constoperator[]()at()begin()rbegin()end()หรือrend().

กฎเหล่านี้ซับซ้อนและละเอียดอ่อนมากจนฉันสงสัยว่าโปรแกรมเมอร์หลายคนสามารถสรุปได้อย่างแม่นยำ ฉันไม่สามารถ.

จะเกิดอะไรขึ้นถ้าข้อกำหนด O (1) ถูกเพิกเฉย

หากoperator[]ไม่คำนึงถึงข้อกำหนดเวลาคงที่ของ C ++ 11 ในเช่นนั้น COW สำหรับbasic_stringอาจเป็นไปได้ในทางเทคนิค แต่ยากที่จะนำไปใช้

การดำเนินการที่สามารถเข้าถึงเนื้อหาของสตริงโดยไม่ต้องคัดลอกข้อมูล COW ได้แก่ :

• การเชื่อมต่อผ่าน+.
• เอาต์พุตผ่าน<<.
• การใช้basic_stringอาร์กิวเมนต์เป็นฟังก์ชันไลบรารีมาตรฐาน

เนื่องจากไลบรารีมาตรฐานได้รับอนุญาตให้อาศัยความรู้และโครงสร้างเฉพาะในการนำไปใช้งาน

นอกจากนี้การใช้งานสามารถนำเสนอฟังก์ชันที่ไม่ได้มาตรฐานต่างๆสำหรับการเข้าถึงเนื้อหาสตริงโดยไม่ต้องเรียกใช้การคัดลอกข้อมูล COW

ปัจจัยที่ทำให้เกิดความซับซ้อนหลักคือในbasic_stringการเข้าถึงรายการC ++ 11 ต้องทริกเกอร์การคัดลอกข้อมูล (ยกเลิกการแบ่งปันข้อมูลสตริง) แต่จำเป็นต้องไม่โยนเช่น C ++ 11 §21.4.5 / 3“ Throws: Nothing” ดังนั้นจึงไม่สามารถใช้การจัดสรรแบบไดนามิกธรรมดาเพื่อสร้างบัฟเฟอร์ใหม่สำหรับการคัดลอกข้อมูล COW วิธีหนึ่งในการแก้ปัญหานี้คือการใช้ฮีปพิเศษที่สามารถจองหน่วยความจำได้โดยไม่ต้องจัดสรรจริงจากนั้นจองจำนวนที่จำเป็นสำหรับการอ้างอิงเชิงตรรกะแต่ละค่าเป็นสตริง การจองและยกเลิกการจองในฮีปอาจเป็นเวลาคงที่ O (1) และการจัดสรรจำนวนเงินที่จองไว้แล้วสามารถnoexcept. เพื่อให้เป็นไปตามข้อกำหนดของมาตรฐานด้วยวิธีนี้ดูเหมือนว่าจะต้องมีฮีปตามการจองพิเศษต่อผู้จัดสรรที่แตกต่างกัน

^{หมายเหตุ:
¹ตัวเข้าถึงconstรายการทริกเกอร์การคัดลอกข้อมูล COW เนื่องจากอนุญาตให้โค้ดไคลเอ็นต์รับข้อมูลอ้างอิงหรือตัวชี้ไปยังข้อมูลซึ่งไม่ได้รับอนุญาตให้ทำให้เป็นโมฆะโดยการคัดลอกข้อมูลในภายหลังที่ทริกเกอร์โดยเช่นตัวเข้าถึงที่ไม่ใช่constรายการ}

ฉันมักจะสงสัยเกี่ยวกับวัวที่ไม่เปลี่ยนรูป: เมื่อสร้างวัวแล้วฉันสามารถเปลี่ยนแปลงได้โดยการมอบหมายจากวัวตัวอื่นเท่านั้นดังนั้นจึงเป็นไปตามมาตรฐาน

ฉันมีเวลาลองวันนี้สำหรับการทดสอบเปรียบเทียบอย่างง่าย: แผนที่ขนาด N ที่คีย์ด้วยสตริง / วัวโดยทุกโหนดถือชุดของสตริงทั้งหมดในแผนที่ (เรามีจำนวนวัตถุ NxN)

ด้วยสตริงที่มีขนาด ~ 300 ไบต์และวัว N = 2000 จะเร็วกว่าเล็กน้อยและใช้หน่วยความจำน้อยกว่า ดูด้านล่างขนาดเป็น kbs รัน b อยู่กับวัว

~/icow$ ./tst 2000
preparation a
run
done a: time-delta=6 mem-delta=1563276
preparation b
run
done a: time-delta=3 mem-delta=186384