ทำไม Java / C # ไม่สามารถใช้ RAII ได้

คำถาม: ทำไม Java / C # ไม่สามารถใช้ RAII ได้

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

ความเข้าใจของฉัน:

ฉันรู้สึกว่าการนำไปปฏิบัติของ RAII ต้องเป็นไปตามข้อกำหนดสองประการ:
1. อายุการใช้งานของทรัพยากรจะต้องอยู่ในขอบเขต
2. โดยปริยาย การเพิ่มทรัพยากรต้องเกิดขึ้นโดยไม่มีคำสั่งอย่างชัดเจนจากโปรแกรมเมอร์ คล้ายกับตัวรวบรวมขยะที่เพิ่มหน่วยความจำโดยไม่ต้องมีคำสั่งที่ชัดเจน "implicitness" จะต้องเกิดขึ้นเมื่อใช้งานในชั้นเรียนเท่านั้น แน่นอนว่าผู้สร้างไลบรารีคลาสต้องใช้เมธอด destructor หรือ Dispose () อย่างชัดเจน

Java / C # พอใจจุดที่ 1 ใน C # ทรัพยากรการใช้ IDisposable สามารถถูกผูกไว้กับขอบเขต "using":

void test()
{
    using(Resource r = new Resource())
    {
        r.foo();
    }//resource released on scope exit
}

สิ่งนี้ไม่เป็นไปตามจุดที่ 2 โปรแกรมเมอร์ต้องผูกวัตถุกับขอบเขต "ใช้" อย่างชัดเจน โปรแกรมเมอร์สามารถ (และทำ) ลืมผูกอย่างชัดเจนทรัพยากรกับขอบเขตสร้างการรั่วไหล

ในความเป็นจริงแล้วคอมไพเลอร์จะทำการแปลงบล็อค "ใช้" เป็นโค้ด try-final-dispose () มีลักษณะที่ชัดเจนเหมือนกันของรูปแบบ try-final-dispose () หากไม่มีการปล่อยโดยนัยเบ็ดไปยังขอบเขตคือน้ำตาลประโยค

void test()
{
    //Programmer forgot (or was not aware of the need) to explicitly
    //bind Resource to a scope.
    Resource r = new Resource(); 
    r.foo();
}//resource leaked!!!

ฉันคิดว่ามันคุ้มค่าที่จะสร้างฟีเจอร์ภาษาใน Java / C # ที่อนุญาตให้วัตถุพิเศษที่เชื่อมต่อกับสแต็กผ่านตัวชี้อัจฉริยะ คุณลักษณะนี้จะช่วยให้คุณสามารถตั้งค่าสถานะคลาสเป็นขอบเขตขอบเขตเพื่อให้ถูกสร้างด้วย hook ไปยังสแต็กเสมอ อาจมีตัวเลือกสำหรับพอยน์เตอร์พอยน์เตอร์ที่แตกต่างกัน

class Resource - ScopeBound
{
    /* class details */

    void Dispose()
    {
        //free resource
    }
}

void test()
{
    //class Resource was flagged as ScopeBound so the tie to the stack is implicit.
    Resource r = new Resource(); //r is a smart-pointer
    r.foo();
}//resource released on scope exit.

ฉันคิดว่าโดยนัยคือ "คุ้มค่า" เช่นเดียวกับการเก็บขยะโดยนัยก็คือ "คุ้มค่า" การใช้บล็อกอย่างชัดเจนนั้นทำให้ดวงตาสดชื่น แต่ไม่มีข้อได้เปรียบทางความหมายมากกว่าการพยายามกำจัด ()

มันใช้งานไม่ได้กับคุณลักษณะดังกล่าวในภาษา Java / C # หรือไม่? มันจะถูกนำมาใช้โดยไม่ทำลายรหัสเก่าหรือไม่

ส่วนขยายภาษาดังกล่าวจะซับซ้อนและรุกรานอย่างมีนัยสำคัญเกินกว่าที่คุณคิด คุณไม่สามารถเพิ่มได้

หากอายุการใช้งานของตัวแปรชนิดสิ้นสุดสแต็กสิ้นสุดให้เรียกใช้Disposeบนออบเจ็กต์ที่อ้างถึง

ไปยังส่วนที่เกี่ยวข้องของข้อมูลจำเพาะภาษาและดำเนินการ ฉันจะไม่สนใจปัญหาของค่าชั่วคราว ( new Resource().doSomething()) ซึ่งสามารถแก้ไขได้โดยการใช้ถ้อยคำทั่วไปที่มากกว่านี้เล็กน้อยนี่ไม่ใช่ปัญหาที่ร้ายแรงที่สุด ตัวอย่างเช่นรหัสนี้จะใช้งานไม่ได้ (และสิ่งนี้อาจเป็นไปไม่ได้ที่จะทำโดยทั่วไป):

File openSavegame(string id) {
    string path = ... id ...;
    File f = new File(path);
    // do something, perhaps logging
    return f;
} // f goes out of scope, caller receives a closed file

ตอนนี้คุณต้องการตัวสร้างสำเนาที่ผู้ใช้กำหนดเอง (หรือย้ายตัวสร้าง) และเริ่มเรียกใช้พวกเขาทุกที่ สิ่งนี้ไม่เพียงส่งผลต่อประสิทธิภาพการทำงานเท่านั้น แต่ยังทำให้สิ่งเหล่านี้มีค่าประเภทได้อย่างมีประสิทธิภาพในขณะที่วัตถุอื่น ๆ เกือบทั้งหมดเป็นประเภทการอ้างอิง ในกรณีของ Java นี่คือการเบี่ยงเบนที่รุนแรงจากการทำงานของวัตถุ ใน C # น้อยลง (มีอยู่แล้วstructแต่ไม่มีตัวสร้างสำเนาที่ผู้ใช้กำหนดเองสำหรับ AFAIK) แต่ก็ยังทำให้วัตถุ RAII เหล่านี้พิเศษยิ่งขึ้น นอกจากนี้ประเภทเชิงเส้นที่มีจำนวน จำกัด (เช่นสนิม) อาจช่วยแก้ปัญหาได้ด้วยค่าใช้จ่ายในการห้ามนามแฝงรวมถึงการส่งพารามิเตอร์ (ยกเว้นกรณีที่คุณต้องการเพิ่มความซับซ้อนมากยิ่งขึ้น

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

ปัญหาที่ใหญ่ที่สุดในการใช้งานสิ่งนี้สำหรับ Java หรือ C # จะเป็นการกำหนดวิธีการถ่ายโอนทรัพยากรทำงาน คุณจะต้องมีวิธีในการยืดอายุของทรัพยากรเกินขอบเขต พิจารณา:

class IWrapAResource
{
    private readonly Resource resource;
    public IWrapAResource()
    {
        // Where Resource is scope bound
        Resource builder = new Resource(args, args, args);

        this.resource = builder;
    } // Uh oh, resource is destroyed
} // Crap, there's no scope for IWrapAResource we can bind to!

สิ่งที่แย่กว่านั้นคือสิ่งนี้อาจไม่ชัดเจนสำหรับผู้ดำเนินการของIWrapAResource:

class IWrapSomething<T>
{
    private readonly T resource; // What happens if T is Resource?
    public IWrapSomething(T input)
    {
        this.resource = input;
    }
}

สิ่งที่ต้องการusingคำสั่งC # อาจใกล้เคียงกับที่คุณกำลังจะมีความหมาย RAII โดยไม่ต้องใช้ทรัพยากรอ้างอิงนับหรือบังคับค่าความหมายทุกที่เช่น C หรือ C ++ เนื่องจาก Java และ C # มีการแบ่งปันทรัพยากรโดยปริยายที่จัดการโดยตัวรวบรวมขยะขั้นต่ำที่โปรแกรมเมอร์จะต้องสามารถทำได้คือเลือกขอบเขตที่ทรัพยากรถูกผูกไว้ซึ่งเป็นสิ่งที่usingทำอยู่แล้ว

เหตุผลที่ RAII ไม่สามารถทำงานในภาษาเช่น C # ได้ แต่ทำงานใน C ++ เนื่องจากใน C ++ คุณสามารถตัดสินใจได้ว่าวัตถุนั้นเป็นวัตถุชั่วคราวจริง ๆ หรือไม่ (โดยการจัดสรรมันในสแต็ก) หรือไม่ว่าจะมีอายุการใช้งานนาน จัดสรรมันบนฮีปโดยใช้newและใช้พอยน์เตอร์)

ดังนั้นใน C ++ คุณสามารถทำสิ่งนี้:

void f()
{
    Foo f1;
    Foo* f2 = new Foo();
    Foo::someStaticField = f2;

    // f1 is destroyed here, the object pointed to by f2 isn't
}

ใน C # คุณไม่สามารถแยกความแตกต่างระหว่างสองกรณีดังนั้นคอมไพเลอร์จะไม่มีความคิดว่าจะจบวัตถุหรือไม่

สิ่งที่คุณสามารถทำได้คือการแนะนำชนิดของตัวแปรเฉพาะที่คุณไม่สามารถใส่ลงในฟิลด์และอื่น ๆ * และมันจะถูกกำจัดโดยอัตโนมัติเมื่อมันออกนอกขอบเขต ซึ่งเป็นสิ่งที่ C ++ / CLI ทำ ใน C ++ / CLI คุณเขียนโค้ดดังนี้:

void f()
{
    Foo f1;
    Foo^ f2 = gcnew Foo();
    Foo::someStaticField = f2;

    // f1 is disposed here, the object pointed to by f2 isn't
}

สิ่งนี้จะคอมไพล์ IL โดยพื้นฐานเหมือนกับ C # ต่อไปนี้:

void f()
{
    using (Foo f1 = new Foo())
    {
        Foo f2 = new Foo();
        Foo.someStaticField = f2;
    }
    // f1 is disposed here, the object pointed to by f2 isn't
}

สรุปได้ว่าถ้าฉันต้องเดาว่าทำไมนักออกแบบของ C # ไม่ได้เพิ่ม RAII นั่นเป็นเพราะพวกเขาคิดว่าการมีตัวแปรท้องถิ่นสองประเภทนั้นไม่คุ้มกับมันเพราะส่วนใหญ่ในภาษาที่มี GC การสรุปขั้นสุดท้ายแบบไม่แน่นอนมีประโยชน์ บ่อยครั้ง.

* _{ไม่ได้โดยไม่มีเทียบเท่าของ&ผู้ประกอบการซึ่งใน C ++ / CLI %คือ แม้ว่าการทำเช่นนั้นจะ“ ไม่ปลอดภัย” ในแง่ที่ว่าหลังจากวิธีการสิ้นสุดลงฟิลด์จะอ้างอิงวัตถุที่ถูกกำจัด}

หากสิ่งที่รบกวนจิตใจคุณusingคือสิ่งที่ชัดเจนพวกเขาอาจใช้ก้าวเล็ก ๆ ไปสู่ความชัดเจนน้อยกว่าแทนที่จะเปลี่ยนข้อกำหนด C # พิจารณารหัสนี้:

public void ReadFile ()
{
  string filename = "myFile.dat";
  local Stream file = File.Open(filename);
  file.Read(blah blah blah);
}

ดูlocalคำหลักที่ฉันเพิ่มหรือไม่ ทั้งหมดมันไม่สามารถเพิ่มบิตน้ำตาลประโยคมากขึ้นเช่นเดียวกับusingบอกคอมไพเลอร์ที่จะเรียกDisposeในfinallyบล็อกในตอนท้ายของขอบเขตของตัวแปรที่ นั้นคือทั้งหมด. มันเทียบเท่ากับ:

public void ReadFile ()
{
  string filename = "myFile.dat";
  using (Stream file = File.Open(filename))
  {
      file.Read(blah blah blah);
  }
}

แต่มีขอบเขตโดยนัยแทนที่จะเป็นขอบเขตที่ชัดเจน มันง่ายกว่าคำแนะนำอื่น ๆ เนื่องจากฉันไม่จำเป็นต้องกำหนดคลาสเป็นขอบเขตขอบเขต เพิ่งทำความสะอาดน้ำตาล syntactic นัยมากขึ้น

อาจมีปัญหาเกี่ยวกับขอบเขตที่ยากต่อการแก้ไขถึงแม้ว่าฉันจะมองไม่เห็นในตอนนี้และฉันขอขอบคุณทุกคนที่สามารถค้นพบได้

สำหรับตัวอย่างของวิธี RAII ทำงานในภาษาขยะรวบรวมตรวจสอบคำหลักในหลามwith แทนที่จะพึ่งพาวัตถุที่ถูกทำลายที่กำหนดขึ้นแล้วให้คุณเชื่อมโยง__enter__()และ__exit__()วิธีการกับขอบเขตศัพท์ที่กำหนด ตัวอย่างทั่วไปคือ:

with open('output.txt', 'w') as f:
    f.write('Hi there!')

เช่นเดียวกับสไตล์ RAII ของ C ++ ไฟล์จะถูกปิดเมื่อออกจากบล็อกนั้นไม่ว่าจะเป็นการออก 'ปกติ', a break, ทันทีreturnหรือข้อยกเว้น

โปรดทราบว่าการopen()โทรเป็นฟังก์ชั่นเปิดไฟล์ปกติ เพื่อให้งานนี้วัตถุไฟล์ที่ส่งคืนมีสองวิธี:

def __enter__(self):
  return self
def __exit__(self):
  self.close()

นี่เป็นสำนวนทั่วไปใน Python: วัตถุที่เกี่ยวข้องกับทรัพยากรมักจะรวมถึงวิธีการทั้งสองนี้

โปรดทราบว่าวัตถุไฟล์ยังคงสามารถจัดสรรหลังจากการ__exit__()โทรสิ่งที่สำคัญคือมันถูกปิด