คำถามติดแท็ก smart-pointer

11
ทำไมต้องมีการรวบรวมขยะหากตัวชี้สมาร์ทอยู่ที่นั่น
วันนี้มีหลายภาษาที่เก็บขยะ มันยังสามารถใช้ได้สำหรับ C ++ โดยบุคคลที่สาม แต่ C ++ มี RAII และตัวชี้อัจฉริยะ ดังนั้นจุดประสงค์ของการใช้การรวบรวมขยะคืออะไร? มันทำอะไรพิเศษหรือไม่? และในภาษาอื่นเช่น C # หากการอ้างอิงทั้งหมดถูกใช้เป็นพอยน์เตอร์อัจฉริยะ (เก็บ RAII ไว้) ตามสเปคและการใช้งานจะยังคงมีความต้องการของนักสะสมขยะหรือไม่? ถ้าไม่เป็นเช่นนั้นทำไมจึงไม่เป็นเช่นนั้น

9
std :: shared_ptr เป็นทางเลือกสุดท้าย?
ผมก็แค่ดู "Going พื้นเมือง 2012" std::shared_ptrลำธารและผมสังเกตเห็นการอภิปรายเกี่ยวกับ ฉันรู้สึกประหลาดใจเล็กน้อยที่ได้ยินมุมมองเชิงลบของ Bjarne std::shared_ptrและความคิดเห็นของเขาว่าควรใช้เป็น "ทางเลือกสุดท้าย" เมื่ออายุการใช้งานของวัตถุไม่แน่นอน (ซึ่งฉันเชื่อตามที่เขาพูด ใครบ้างที่จะอธิบายสิ่งนี้ในเชิงลึกมากขึ้นอีกหน่อย? เราจะตั้งโปรแกรมโดยไม่ใช้std::shared_ptrและยังจัดการเวลาวัตถุได้อย่างปลอดภัยหรือไม่?

1
raw, weak_ptr, unique_ptr, shared_ptr ฯลฯ ... วิธีการเลือกอย่างชาญฉลาด?
มีพอยน์เตอร์จำนวนมากใน C ++ แต่จะซื่อสัตย์ใน 5 ปีหรือมากกว่านั้นในการเขียนโปรแกรม C ++ (โดยเฉพาะกับ Qt Framework) ฉันใช้พอยน์เตอร์พอยต์แบบเก่าเท่านั้น: SomeKindOfObject *someKindOfObject = new SomeKindOfObject(); ฉันรู้ว่ามีคำแนะนำ "ฉลาด" อื่น ๆ อีกมากมาย: // shared pointer: shared_ptr<SomeKindofObject> Object; // unique pointer: unique_ptr<SomeKindofObject> Object; // weak pointer: weak_ptr<SomeKindofObject> Object; แต่ฉันไม่มีความคิดเพียงเล็กน้อยเกี่ยวกับสิ่งที่พวกเขาทำและสิ่งที่พวกเขาสามารถเสนอให้ฉันได้เปรียบเทียบตัวชี้แบบดิบ ตัวอย่างเช่นฉันมีส่วนหัวของชั้นนี้: #ifndef LIBRARY #define LIBRARY class LIBRARY { public: // Permanent list …

5
ทำไม Java / C # ไม่สามารถใช้ RAII ได้
คำถาม: ทำไม Java / C # ไม่สามารถใช้ RAII ได้ ชี้แจง: ฉันรู้ว่าตัวรวบรวมขยะไม่ได้กำหนดไว้ ดังนั้นด้วยคุณสมบัติภาษาปัจจุบันจึงเป็นไปไม่ได้ที่วิธีการกำจัด () ของวัตถุจะถูกเรียกโดยอัตโนมัติเมื่อออกจากขอบเขต แต่สามารถเพิ่มคุณสมบัติพิเศษดังกล่าวได้หรือไม่ ความเข้าใจของฉัน: ฉันรู้สึกว่าการนำไปปฏิบัติของ RAII ต้องเป็นไปตามข้อกำหนดสองประการ: 1. อายุการใช้งานของทรัพยากรจะต้องอยู่ในขอบเขต 2. โดยปริยาย การเพิ่มทรัพยากรต้องเกิดขึ้นโดยไม่มีคำสั่งอย่างชัดเจนจากโปรแกรมเมอร์ คล้ายกับตัวรวบรวมขยะที่เพิ่มหน่วยความจำโดยไม่ต้องมีคำสั่งที่ชัดเจน "implicitness" จะต้องเกิดขึ้นเมื่อใช้งานในชั้นเรียนเท่านั้น แน่นอนว่าผู้สร้างไลบรารีคลาสต้องใช้เมธอด destructor หรือ Dispose () อย่างชัดเจน Java / C # พอใจจุดที่ 1 ใน C # ทรัพยากรการใช้ IDisposable สามารถถูกผูกไว้กับขอบเขต "using": void test() { using(Resource …

5
C ++: ชั้นเรียนควรเป็นเจ้าของหรือสังเกตการอ้างอิงของมัน?
บอกว่าผมได้เรียนFoobarที่ใช้ (ขึ้นอยู่กับ) Widgetระดับ ในวันเฒ่าที่ดีWidgetwolud จะถูกประกาศให้เป็นสนามในFoobarหรืออาจจะเป็นตัวชี้ที่ฉลาดถ้าต้องการพฤติกรรม polymorphic และมันจะเริ่มต้นได้ใน constructor: class Foobar { Widget widget; public: Foobar() : widget(blah blah blah) {} // or std::unique_ptr<Widget> widget; public: Foobar() : widget(std::make_unique<Widget>(blah blah blah)) {} (…) }; และเราจะพร้อมทุกอย่างให้เรียบร้อย น่าเสียดายที่วันนี้เด็ก ๆ จาวาจะหัวเราะเยาะเราเมื่อพวกเขาเห็นมันและอย่างถูกต้องตามที่คู่รักFoobarและWidgetร่วมกัน วิธีแก้ปัญหานั้นง่ายมาก: ใช้การฉีดพึ่งพาเพื่อสร้างการพึ่งพาจากFoobarชั้นเรียน แต่แล้ว C ++ ก็บังคับให้เราคิดถึงการเป็นเจ้าของการพึ่งพา การแก้ปัญหาทั้งสามอยู่ในใจ: ตัวชี้ที่ไม่ซ้ำ class Foobar { std::unique_ptr<Widget> widget; …

3
การทำลายรายการใหญ่จะล้นสแต็กของฉันหรือไม่
พิจารณาการใช้งานรายการที่เชื่อมโยงโดยลำพังดังต่อไปนี้: struct node { std::unique_ptr<node> next; ComplicatedDestructorClass data; } ทีนี้สมมติว่าฉันหยุดใช้std::unique_ptr<node> headอินสแตนซ์ที่เกินขอบเขตแล้วทำให้ destructor ของมันถูกเรียก สิ่งนี้จะทำให้สแตกของฉันสำหรับรายการขนาดใหญ่เพียงพอหรือไม่ มันยุติธรรมที่จะคิดว่าคอมไพเลอร์จะทำเพิ่มประสิทธิภาพซับซ้อนสวย (อินไลน์unique_ptr's destructor เข้าnode' s แล้วใช้ recursion หาง) ซึ่งได้รับยากมากถ้าผมทำต่อไปนี้ (ตั้งแต่datadestructor จะทำให้งงงวยnext's ทำให้มันยาก เพื่อให้คอมไพเลอร์สังเกตเห็นโอกาสการเรียงลำดับใหม่และโอกาสในการโทรหาง): struct node { std::shared_ptr<node> next; ComplicatedDestructorClass data; } ถ้าdataอย่างใดมีตัวชี้ไปnodeแล้วก็อาจเป็นไปไม่ได้สำหรับการเรียกซ้ำหาง (แม้ว่าแน่นอนเราควรพยายามหลีกเลี่ยงการละเมิด encapsulation ดังกล่าว) โดยทั่วไปแล้วเราจะทำลายรายการนี้ได้อย่างไร? เราไม่สามารถข้ามผ่านรายการและลบโหนด "ปัจจุบัน" เนื่องจากตัวชี้ที่ใช้ร่วมกันไม่มีrelease! วิธีเดียวคือกับตัวกำหนดเองซึ่งส่งกลิ่นให้ฉันจริงๆ

1
การพัฒนาที่เก็บคีย์ / ค่าที่ย้ายไปยัง C ++ ที่ทันสมัย
ฉันกำลังพัฒนาเซิร์ฟเวอร์ฐานข้อมูลที่คล้ายกับ Cassandra การพัฒนาเริ่มต้นใน C แต่สิ่งต่าง ๆ ก็ซับซ้อนมากโดยไม่ต้องเรียน ขณะนี้ฉันได้ย้ายทุกอย่างใน C ++ 11 แต่ฉันยังคงเรียนรู้ C ++ ที่ทันสมัยและยังมีข้อสงสัยมากมาย ฐานข้อมูลจะทำงานกับคู่ของคีย์ / ค่า ทุกคู่มีข้อมูลเพิ่มเติม - เมื่อถูกสร้างขึ้นด้วยเมื่อมันจะหมดอายุ (0 ถ้าไม่หมดอายุ) แต่ละคู่นั้นไม่เปลี่ยนรูป Key คือสตริง C ค่าเป็นโมฆะ * แต่อย่างน้อยตอนนี้ฉันทำงานด้วยค่าเป็นสตริง C เช่นกัน มีIListระดับนามธรรม มันสืบทอดมาจากสามชั้น VectorList - C dynamic array - คล้ายกับ std :: vector แต่ใช้ realloc LinkList - ทำเพื่อการตรวจสอบและเปรียบเทียบประสิทธิภาพ SkipList …

4
การจัดการทรัพยากรที่ไม่ได้กำหนดไว้ว่าเป็นสิ่งที่เป็นนามธรรมหรือไม่?
จากสิ่งที่ฉันเห็นมีรูปแบบการจัดการทรัพยากรที่แพร่หลายอยู่สองรูปแบบคือการทำลายล้างที่กำหนดขึ้นและชัดเจน ตัวอย่างของอดีตจะเป็น destructors C ++ และตัวชี้สมาร์ทหรือย่อย DESTROY ของ Perl ในขณะที่ตัวอย่างหลังจะเป็นกระบวนทัศน์แบบบล็อกต่อการจัดการทรัพยากรของ Ruby หรืออินเทอร์เฟซ IDispose ของ. NET ภาษาที่ใหม่กว่าดูเหมือนจะเลือกใช้ในภายหลังซึ่งอาจเป็นผลข้างเคียงของการใช้ระบบรวบรวมขยะที่หลากหลายที่ไม่อ้างอิงการนับ คำถามของฉันคือ: เนื่องจาก destructors สำหรับสมาร์ทพอยน์เตอร์หรือระบบรวบรวมขยะอ้างอิง - เกือบจะเป็นสิ่งเดียวกัน - อนุญาตให้มีการทำลายทรัพยากรโดยปริยายและโปร่งใสมันเป็นสิ่งที่เป็นนามธรรมน้อยรั่วกว่าประเภทที่ไม่ได้กำหนดไว้ล่วงหน้า สัญกรณ์? ฉันจะยกตัวอย่างที่เป็นรูปธรรม หากคุณมีคลาสย่อย C ++ สามคลาสของซูเปอร์คลาสเดียวอาจมีการใช้งานที่ไม่ต้องการการทำลายที่เฉพาะเจาะจง บางทีมันอาจใช้เวทมนตร์ในอีกทางหนึ่ง ความจริงที่ว่ามันไม่ต้องการการทำลายพิเศษใด ๆ นั้นไม่เกี่ยวข้อง - คลาสย่อยทั้งหมดยังคงใช้ในลักษณะเดียวกัน ตัวอย่างอื่นใช้บล็อก Ruby คลาสย่อยสองคลาสจำเป็นต้องเพิ่มรีซอร์สดังนั้นคลาสคลาส opts สำหรับอินเตอร์เฟสที่ใช้บล็อกในตัวสร้างแม้ว่าคลาสย่อยย่อยอื่นอาจไม่ต้องการเนื่องจากมันไม่ต้องการการทำลายพิเศษ เป็นกรณีที่การรั่วไหลหลังรายละเอียดการใช้งานของการทำลายทรัพยากรในขณะที่อดีตไม่ได้หรือไม่ แก้ไข: การเปรียบเทียบสมมติว่า Ruby กับ Perl อาจมีความยุติธรรมมากกว่าเนื่องจากมีการทำลายล้างที่กำหนดและที่เหลือไม่ได้ แต่พวกเขาทั้งคู่เก็บขยะ
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.