Java / C #에서 RAII를 구현할 수없는 이유는 무엇입니까?

질문 : Java / C #에서 RAII를 구현할 수없는 이유는 무엇입니까?

설명 : 가비지 수집기가 결정적이지 않다는 것을 알고 있습니다. 따라서 현재 언어 기능을 사용하면 범위 종료시 객체의 Dispose () 메서드를 자동으로 호출 할 수 없습니다. 그러나 그러한 결정적 기능을 추가 할 수 있습니까?

내 이해 :

RAII 구현은 두 가지 요구 사항을 충족해야한다고 생각합니다.
1. 리소스 수명은 범위에 속해야합니다.
2. 암시 적. 프로그래머가 명시 적으로 진술하지 않고 자원을 확보해야합니다. 명시 적 진술없이 메모리를 비우는 가비지 수집기와 유사합니다. "내 재성"은 클래스 사용 시점에서만 발생하면됩니다. 클래스 라이브러리 생성자는 물론 소멸자 또는 Dispose () 메서드를 명시 적으로 구현해야합니다.

Java / C #은 포인트 1을 만족합니다. C #에서 IDisposable을 구현하는 리소스는 "사용"범위에 바인딩 될 수 있습니다.

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

이것은 포인트 2를 만족시키지 않습니다. 프로그래머는 명시 적으로 개체를 특수한 "사용"범위에 묶어야합니다. 프로그래머는 명시 적으로 리소스를 스코프에 연결하여 누출을 생성하는 것을 잊어 버릴 수 있습니다.

실제로 "using"블록은 컴파일러에 의해 try-finally-dispose () 코드로 변환됩니다. try-finally-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 #에서 언어 기능을 만드는 것이 좋습니다. 이 기능을 사용하면 클래스를 스코프 바운드로 플래그 지정할 수 있으므로 항상 스택에 대한 후크로 생성됩니다. 다른 유형의 스마트 포인터에 대한 옵션이있을 수 있습니다.

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.

내포가 "가치"라고 생각합니다. 가비지 수집의 암시가 "가치있는"것처럼. 명시 적 사용 블록은 눈에 상쾌하지만 try-finally-dispose ()에 비해 의미 론적 이점을 제공하지 않습니다.

그러한 기능을 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 객체를 더 특별하게 만듭니다. 또는 제한된 형식의 선형 유형 (Rust 참조)도 매개 변수 전달을 포함하여 앨리어싱을 금지하는 비용으로 문제를 해결할 수 있습니다 (Rust와 같은 차용 참조 및 차용 검사기를 채택하여 훨씬 더 복잡한 것을 도입하려는 경우는 제외).

기술적으로 할 수는 있지만 언어의 다른 모든 것과는 매우 다른 범주의 범주로 끝납니다 . 구현 자 (가장 많은 경우, 모든 부서에서 더 많은 시간 / 비용)와 사용자 (배워야 할 더 많은 개념, 더 많은 버그 가능성)에 영향을주는 것은 거의 항상 나쁜 생각입니다. 추가 편의 가치가 없습니다.

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;
    }
}

C #과 같은 것 using 진술 것은 아마도 계산 자원을 참조하거나 C 또는 C ++과 같은 모든 곳에서 가치 의미를 강요하지 않고 RAII 의미를 가지게 될 것입니다. 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
}

이것은 기본적으로 다음 C #과 동일한 IL로 컴파일됩니다.

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전화 컴파일러를 말하고, DisposeA의 finally변수의 범위의 끝 부분에 블록. 그게 다야 다음과 완전히 같습니다.

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

그러나 명시 적 범위가 아니라 암시 적 범위를 갖습니다. 클래스를 범위 제한으로 정의 할 필요가 없으므로 다른 제안보다 간단합니다. 더 깨끗하고 암시적인 구문 설탕.

해결하기 어려운 범위에 문제가있을 수 있지만 지금은 볼 수 없지만 찾을 수있는 사람에게 감사드립니다.

RAII가 가비지 수집 언어에서 작동하는 방법에 대한 예는 withPython 에서 키워드를 확인하십시오 . 결정적으로 파괴 된 객체에 의존하는 대신 주어진 어휘 범위에 메소드 __enter__()와 __exit__()메소드를 연관시킬 수 있습니다 . 일반적인 예는 다음과 같습니다.

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

C ++의 RAII 스타일과 마찬가지로 파일은 '정상'종료인지, break즉각적인 지 return또는 예외인지에 관계없이 해당 블록을 종료 할 때 닫힙니다 .

점을 유의 open()통화가 보통의 파일 열기 기능입니다. 이 작업을 수행하기 위해 리턴 된 파일 오브젝트에는 두 가지 메소드가 포함됩니다.

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

이것은 파이썬의 일반적인 관용구입니다. 리소스와 관련된 객체에는 일반적으로이 두 가지 방법이 포함됩니다.

파일 객체는 __exit__()호출 후에도 할당 된 상태를 유지할 수 있지만 중요한 것은 파일 객체 가 닫혀 있다는 것입니다.