甲府方重信Blog

...Shigenobu Koufugatas Blog

  • Increase font size
  • Default font size
  • Decrease font size
Error
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
Home 業務日誌 Adaプログラミング Adaチュートリアル セクション12.6 - Unchecked_Deallocation

Adaチュートリアル セクション12.6 - Unchecked_Deallocation

E-mail Print PDF

セクション 12.6 - Unchecked_Deallocation

時間が経過すると、もはや参照されなくなったいくつかのオブジェクトが発生する可能性があります。このような場合の取り扱いは「ガベージ・コレクション」と呼ばれています。Adaは、自動ガベージ・コレクションを許可は出来るけれども、必ず必要ではないように設計されていました。多くのAdaコンパイラーは、自動ガベージ・コレクションを実行するようにはなっていなかったので、より移植性を求めるならば、ガベージ・コレクションが自動的に実行されるとは限らないように仮定しておくことが求められます。注意していただきたいのは、ガベージ・コレクションを許すようなAdaコンパイラーは自動ガベージ・コレクションを実行するようなJava J-code (バイトコード)を生成するのです。

Adaは、もはや参照されなくなった場合、そのオブジェクトを離すジェネリック・プロシージャーを提供しています。このプロシージャーは、C言語における「free」や、C++における「delet」に相当します。このジェネリック・プロシージャーの名前は、「Unchecked_Deallocation」と呼ばれています。このプロシージャーは、ジェネリックですので、プログラマーは使用しようとするアクセス型を使うためにこのジェネリックをインスタンス化する必要があります。慣例によって、このインスタンス化の名前は通常「Free」と呼ばれています。

ここで、ジェネリック・プロシージャー「Unchecked_Deallocation」の公式の定義を掲載します。

  generic
    type Object(<>) is limited private;
    type Name   is access  Object;
  procedure Unchecked_Deallocation(X : in out Name);

私たちは、プロシージャーに二つのものを渡す必要があることに注意してください。型とその型へのアクセスです。ここでは、単純な例をあげます。「Free」と呼ばれるプロシージャーをインスタンス化してみましょう。これは、私たちがもはや使われなくなったオブジェクトをリリースすることを許すことになります。

  procedure Free is new Unchecked_Deallocation(Tree_Node, Tree_Access);

「Free」と呼ばれるプロシージャーをインスタンス化すると、私たちはこれを呼び出すことが出来ます。サンプルコードを続けていきましょう。私たちが最後のセクションで作成したノードをもはや使用したくないという状況を想像してみましょう。私たちは、先ほど作成したこの新しい「Free」ルーチン呼び出すだけなのです。すばらしいでしょう。

  Free(Current);

Freeが戻ってきたときには、Currentの値は「null」値となっているでしょう。そして、Currnetによって以前アクセスされていたメモリーはリリースされているでしょう。いかなるUnchecked_Deallocationのインスタンス化も、自動的にプログラマーが期待しているように、囲いこまれた型に対して定義されたファイナライズ操作を自動的に呼び出すでしょう。

ここで重要な問題が浮かび上がります。C言語やC++、Pascalのような他の言語においても同じように登場する問題です。もう一つのアクセス型がそのオブジェクトを参照していた場合、どうなるのか、ということです。私たちの例においては、アクセス変数「Root」はオブジェクト一つを参照し続けています。しかし、そのオブジェクトはもはや存在しません。そのオブジェクトにアクセスするためにRootを使用しようとするいかなる試みも、予測できない結果を生むことになります。一方、Adaはアクセス変数の利用において一連の保護を提供しています。これはADaが完全に保護しきれない(また、他のいくつかの言語においても同様に)問題の一つです。

これは安全であるべきで利用が容易であるべきという要望と、効果が予測可能であるべきという要望の間に対立する強い緊張状態が存在する領域です。いくつかの言語は、割り当ての解除を自動的に取り扱われるように要求しています。これは、自動ガーベッジ・コレクションと呼ばれています。このような言語の例としては、Smalltalk、Eiffel、Javaなどがあります。自動ガーベッジ・コレクションは実際便利です。そのため、誰もがこれを求めないのでしょうか。それは、自動ガーベッジ・コレクションに伴う以下のような問題のためです。

  • 自動的なガーベッジコレクションは、重大な性能上のオーバーヘッドの原因となりえます。
  • 自動的なガーベッジコレクションは、性能が予測不可能になる要因となりえます。特定の割り当て、あるいは、削除が呼ばれる場合の代わりにCollectionのオーパーヘッドが常時発生するかもしれません。
  • 自動的なガーベッジコレクションは、上手に実装するのが困難です (そして、これが上手に実装することが高価につくことがあります)

Adaの仕様は、自動的なガーベッジコレクションを要求してはいません。しかし、Adaは明白に、自動的なガーベッジコレクションを許すように定義されています。コンパイラー・ベンダーは、自分達のオプションとして自動的なガーベッジコレクションを実装するかどうかについては自由な立場にいます。Adaは、Unchecked_Deallocatinが有効であることを要求しており、もし、自動ガーベッジコレクションが存在しなければ、実際何も起きません。プログラマーがもし自動ガーベッジコレクションを実行しないAdaコンパイラーを使用しているのであれば(多くの場合そうなのですが)、そしてまたプログラマーが不正な割り当て削除に注意を払っているのであれば、プログラマーはUncehcked_Deallocationの全ての利用に対して検索をすることが出来ます。

Unchecked_Deallocationは、配列を含むあらゆるオブジェクトに対して有効に動作します。

出典: http://www.adahome.com/Tutorials/Lovelace/s12s6.htm

Last Updated on Tuesday, 08 May 2012 19:26  

ニュース速報

LPIC2資格対策講座 を開催しました。

2010/10/18 ~ 2010/10/22

@リナックスアカデミー ANNEX 505教室