Tại sao Java / C # không thể triển khai RAII?

Câu hỏi: Tại sao Java / C # không thể triển khai RAII?

Làm rõ: Tôi biết rằng trình thu gom rác không mang tính quyết định. Vì vậy, với các tính năng ngôn ngữ hiện tại, phương thức Dispose () của đối tượng không thể được gọi tự động khi thoát khỏi phạm vi. Nhưng một tính năng xác định như vậy có thể được thêm vào?

Sự hiểu biết của tôi:

Tôi cảm thấy việc triển khai RAII phải đáp ứng hai yêu cầu:
1. Tuổi thọ của tài nguyên phải được ràng buộc trong một phạm vi.
2. Ngấm ngầm. Việc giải phóng tài nguyên phải xảy ra mà không có tuyên bố rõ ràng của lập trình viên. Tương tự như một bộ nhớ giải phóng bộ nhớ rác mà không có một tuyên bố rõ ràng. "Nhân chứng" chỉ cần xảy ra tại điểm sử dụng của lớp. Tất nhiên, người tạo thư viện lớp phải thực hiện rõ ràng một phương thức hàm hủy hoặc Dispose ().

Java / C # thỏa mãn điểm 1. Trong C #, một tài nguyên triển khai IDis có thể được liên kết với phạm vi "sử dụng":

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

Điều này không thỏa mãn điểm 2. Lập trình viên phải ràng buộc rõ ràng đối tượng vào một phạm vi "sử dụng" đặc biệt. Các lập trình viên có thể (và làm) quên kết nối tài nguyên một cách rõ ràng với một phạm vi, tạo ra sự rò rỉ.

Trong thực tế, các khối "bằng cách sử dụng" được trình biên dịch chuyển thành mã try-cuối-dispose (). Nó có cùng bản chất rõ ràng của mẫu thử-cuối cùng-dispose (). Không có một bản phát hành ngầm, móc vào một phạm vi là cú pháp đường.

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!!!

Tôi nghĩ rằng đáng để tạo một tính năng ngôn ngữ trong Java / C # cho phép các đối tượng đặc biệt được nối với ngăn xếp thông qua một con trỏ thông minh. Tính năng này sẽ cho phép bạn gắn cờ một lớp là giới hạn phạm vi, để nó luôn được tạo bằng một móc vào ngăn xếp. Có thể có các tùy chọn cho các loại con trỏ thông minh khác nhau.

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.

Tôi nghĩ rằng nhân chứng là "đáng giá". Giống như nhân chứng của việc thu gom rác là "đáng giá". Sử dụng các khối rõ ràng đang làm mới trên mắt, nhưng không cung cấp lợi thế về ngữ nghĩa so với thử-cuối-xử lý ().

Có phải là không thực tế khi triển khai một tính năng như vậy vào các ngôn ngữ Java / C # không? Nó có thể được giới thiệu mà không phá vỡ mã cũ?

Một phần mở rộng ngôn ngữ như vậy sẽ phức tạp và xâm lấn hơn đáng kể so với bạn nghĩ. Bạn không thể chỉ thêm

nếu thời gian tồn tại của một biến thuộc loại giới hạn ngăn xếp kết thúc, hãy gọi Disposeđối tượng mà nó đề cập đến

đến phần có liên quan của thông số ngôn ngữ và được thực hiện. Tôi sẽ bỏ qua vấn đề về các giá trị tạm thời ( new Resource().doSomething()) có thể được giải quyết bằng cách diễn đạt chung hơn một chút, đây không phải là vấn đề nghiêm trọng nhất. Ví dụ, mã này sẽ bị hỏng (và loại điều này có thể trở nên không thể thực hiện được nói chung):

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

Bây giờ bạn cần các hàm tạo sao chép do người dùng định nghĩa (hoặc di chuyển các hàm tạo) và bắt đầu gọi chúng ở mọi nơi. Điều này không chỉ mang ý nghĩa hiệu suất, nó còn làm cho những thứ này có giá trị các loại một cách hiệu quả, trong khi hầu hết tất cả các đối tượng khác là các loại tham chiếu. Trong trường hợp của Java, đây là một sai lệch căn bản so với cách các đối tượng hoạt động. Trong C # ít hơn (đã có structs, nhưng không có hàm tạo sao chép do người dùng định nghĩa cho họ AFAIK), nhưng nó vẫn làm cho các đối tượng RAII này đặc biệt hơn. Ngoài ra, một phiên bản giới hạn của các loại tuyến tính (xem Rust) cũng có thể giải quyết vấn đề, với chi phí cấm răng cưa bao gồm cả việc truyền tham số (trừ khi bạn muốn giới thiệu thậm chí phức tạp hơn bằng cách áp dụng các tham chiếu mượn giống như Rust và trình kiểm tra mượn).

Nó có thể được thực hiện về mặt kỹ thuật, nhưng bạn kết thúc với một loại những thứ rất khác với mọi thứ khác trong ngôn ngữ. Đây hầu như luôn là một ý tưởng tồi, với hậu quả cho người thực hiện (nhiều trường hợp cạnh hơn, nhiều thời gian / chi phí hơn ở mỗi bộ phận) và người dùng (nhiều khái niệm để tìm hiểu, nhiều khả năng lỗi hơn). Nó không đáng để thêm tiện lợi.

Khó khăn lớn nhất trong việc triển khai một cái gì đó như thế này cho Java hoặc C # sẽ là việc xác định cách thức chuyển giao tài nguyên hoạt động. Bạn sẽ cần một số cách để kéo dài tuổi thọ của tài nguyên ngoài phạm vi. Xem xét:

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!

Điều tồi tệ hơn là điều này có thể không rõ ràng đối với người thực hiện IWrapAResource:

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

Một cái gì đó giống như usingtuyên bố của C # có thể gần giống như bạn sắp có ngữ nghĩa RAII mà không cần dùng đến tài nguyên đếm tham chiếu hoặc buộc ngữ nghĩa giá trị ở mọi nơi như C hoặc C ++. Vì Java và C # có chia sẻ ngầm các tài nguyên được quản lý bởi trình thu gom rác, nên lập trình viên tối thiểu cần có thể làm là chọn phạm vi mà tài nguyên bị ràng buộc, đó chính xác là những gì usingđã làm.

Lý do tại sao RAII không thể hoạt động với ngôn ngữ như C #, nhưng nó hoạt động trong C ++, là vì trong C ++, bạn có thể quyết định liệu một đối tượng có thực sự tạm thời hay không (bằng cách phân bổ nó trên ngăn xếp) hoặc liệu nó có tồn tại lâu không (bởi phân bổ nó trên heap bằng cách sử dụng newvà sử dụng con trỏ).

Vì vậy, trong C ++, bạn có thể làm một cái gì đó như thế này:

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

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

Trong C #, bạn không thể phân biệt giữa hai trường hợp, vì vậy trình biên dịch sẽ không biết có nên hoàn thiện đối tượng hay không.

Những gì bạn có thể làm là giới thiệu một số loại biến cục bộ đặc biệt, mà bạn không thể đưa vào các trường, v.v. * và nó sẽ tự động được xử lý khi nó vượt quá phạm vi. Đó chính xác là những gì C ++ / CLI làm. Trong C ++ / CLI, bạn viết mã như thế này:

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

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

Điều này biên dịch về cơ bản cùng IL như C # sau:

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
}

Để kết luận, nếu tôi đoán tại sao các nhà thiết kế của C # không thêm RAII, thì họ nghĩ rằng việc có hai loại biến cục bộ khác nhau không đáng, chủ yếu là vì trong ngôn ngữ với GC, quyết toán xác định không hữu ích thường xuyên

* _{Không phải không có tương đương với &toán tử, trong C ++ / CLI là %. Mặc dù làm như vậy là không an toàn, theo nghĩa là sau khi phương thức kết thúc, trường sẽ tham chiếu đến một đối tượng được xử lý.}

Nếu những gì làm phiền bạn với usingcác khối là nhân chứng của họ, có lẽ chúng ta có thể bước một bước nhỏ bé về phía ít nhân chứng hơn là thay đổi chính thông số kỹ thuật C #. Hãy xem xét mã này:

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

Xem localtừ khóa tôi đã thêm? Tất cả những gì nó làm là thêm một chút đường cú pháp, giống như using, bảo trình biên dịch gọi Disposemột finallykhối ở cuối phạm vi của biến. Đó là tất cả. Nó hoàn toàn tương đương với:

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

nhưng với một phạm vi ngầm, chứ không phải là một phạm vi rõ ràng. Nó đơn giản hơn các đề xuất khác vì tôi không phải có lớp được định nghĩa là giới hạn phạm vi. Chỉ cần sạch hơn, đường cú pháp ngầm hơn.

Có thể có vấn đề ở đây với phạm vi khó giải quyết, mặc dù tôi không thể nhìn thấy nó ngay bây giờ và tôi đánh giá cao bất cứ ai có thể tìm thấy nó.

Để biết ví dụ về cách RAII hoạt động với ngôn ngữ được thu gom rác, hãy kiểm tra withtừ khóa trong Python . Thay vì dựa vào các đối tượng bị phá hủy xác định, nó cho phép bạn liên kết __enter__()và __exit__()phương thức với một phạm vi từ vựng nhất định. Một ví dụ phổ biến là:

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

Như với kiểu RAII của C ++, tệp sẽ bị đóng khi thoát khỏi khối đó, bất kể đó là lối thoát 'bình thường', a break, ngay lập tức returnhay ngoại lệ.

Lưu ý rằng open()cuộc gọi là chức năng mở tệp thông thường. Để thực hiện công việc này, đối tượng tệp được trả về bao gồm hai phương thức:

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

Đây là một thành ngữ phổ biến trong Python: các đối tượng được liên kết với một tài nguyên thường bao gồm hai phương thức này.

Lưu ý rằng đối tượng tập tin vẫn có thể vẫn được phân bổ sau __exit__()cuộc gọi, điều quan trọng là nó đã bị đóng.