Mercurial > hg > Papers > 2021 > anatofuz-master

comparison paper/chapter/04-interface.tex @ 82:3fb7c17d8e91

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
update
author anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp>
date Fri, 05 Feb 2021 09:53:09 +0900
parents 9974be9e2d1c
children 88ae1e4d83c6
comparison
equal deleted inserted replaced
81:9974be9e2d1c 82:3fb7c17d8e91
124 124
125 \subsection{Gears::Interfaceの構成} 125 \subsection{Gears::Interfaceの構成}
126 126
127 127
128 \section{Interfaceの実装のCbCファイルへの構文の導入} 128 \section{Interfaceの実装のCbCファイルへの構文の導入}
129 今までのGearsOSではマクロに似た\texttt{\#interface}構文で使用するInterfce名を指定した。
130 しかしInterfaceを実装する場合も、 InterfaceのAPIを利用する際も同じシンタックスであった。
131 この2つは意味が異なっている為、 シンタックスを分離したい。
132 Implementの型定義ファイルを導入したので、Interfaceの実装をする場合に別のシンタックスを導入する。
133
134
135 導入された構文をソースコード\ref{src:implHeader}に示す。
136 この例ではStack Interfaceの実装としてSingleLinkedStackを定義する宣言である。
137
138 Implementの宣言の構文では、 まず\texttt{\#impl}の後ろに実装したいIntefaceの名前を入れる。
139 続く\texttt{for}キーワードの後ろに、 Implementの型名を記述する。
140 宣言はgenerate\_stub.plが読み取り、 変換した後のCbCファイルからは該当する行が削除される。
141 \lstinputlisting[label=src:implHeader, caption=Intefaceの実装をする際の宣言]{src/implHeader.h}
129 142
130 \section{GearsCbCのInterfaceの実装時の問題} 143 \section{GearsCbCのInterfaceの実装時の問題}
131 144
132 Interfaceとそれを実装するImplの型が決定すると、最低限満たすべきCodeGearのAPIは一意に決定する。 145 Interfaceとそれを実装するImplの型が決定すると、最低限満たすべきCodeGearのAPIは一意に決定する。
133 ここで満たすべきCodeGearは、Interfaceで定義したCodeGearと、 Impl側で定義した privateなCodeGearとなる。 146 ここで満たすべきCodeGearは、Interfaceで定義したCodeGearと、 Impl側で定義した privateなCodeGearとなる。
225 238
226 239
227 コンストラクタのメンバ変数はデフォルトでは変数は0、ポインタの場合はNULLで初期化するように生成する。 240 コンストラクタのメンバ変数はデフォルトでは変数は0、ポインタの場合はNULLで初期化するように生成する。
228 このスクリプトで生成されたコンストラクタを使う場合、 CbCファイルから該当する部分を削除すると、\texttt{generate\_stub.pl}内でも自動的に生成される。 241 このスクリプトで生成されたコンストラクタを使う場合、 CbCファイルから該当する部分を削除すると、\texttt{generate\_stub.pl}内でも自動的に生成される。
229 自動生成機能を作成すると1CbCファイルあたりの記述量が減る利点がある。 242 自動生成機能を作成すると1CbCファイルあたりの記述量が減る利点がある。
230 243 generate\_stub.pl内で作製する場合は、 すでにメタ情報を含むコードに書き換えたものを作製する。
244 その為厳密には同じコードを生成する訳ではない。
231 245
232 246
233 明示的にコンストラクタが書かれていた場合は、 Perlスクリプト内での自動生成は実行しないように実装した。 247 明示的にコンストラクタが書かれていた場合は、 Perlスクリプト内での自動生成は実行しないように実装した。
234 これはオブジェクト指向言語のオーバーライドに相当する機能と言える。 248 これはオブジェクト指向言語のオーバーライドに相当する機能と言える。
235 現状のGearsOSで使われているコンストラクタは、 基本は\texttt{struct Context*}型の変数のみを引数で要求している。 249 現状のGearsOSで使われているコンストラクタは、 基本は\texttt{struct Context*}型の変数のみを引数で要求している。
283 このローカル変数の型と、CodeGearの定義の引数の型が、完全に一致しているかどうかのチェックを行うと、さらに強固な引数チェックが可能となる。 297 このローカル変数の型と、CodeGearの定義の引数の型が、完全に一致しているかどうかのチェックを行うと、さらに強固な引数チェックが可能となる。
284 ただし引数で渡す際に、例えばint型の値の加算処理などを行っていると、その処理の結果がint型になっているかどうかをPerlレベルでチェックする必要が出てしまう。 298 ただし引数で渡す際に、例えばint型の値の加算処理などを行っていると、その処理の結果がint型になっているかどうかをPerlレベルでチェックする必要が出てしまう。
285 299
286 300
287 \section{InterfaceのAPIの未実装の検知} 301 \section{InterfaceのAPIの未実装の検知}
288 パースした結果、ヘッダファイルにAPIの定義がなかった場合は11行目の\texttt{unless}に処理が落ち、 エラー終了する。 302 InterfaceAPI呼び出し時に引数の数以外に、そもそも実装していないAPIを呼び出してしまうことがある。
303 この場合はCbCがPerlスクリプトによって変換された後でエラーが出る。
304 内容はCbCコンパイラのコンパイル時にInterfaceの構造体に、APIに対応するフィールドがないエラーである。
305 コンパイル時に発覚できるので問題ないが、 これも変換する前に発見したほうがデバッグが容易である。
306
307 API呼び出し時の処理は、ソースコード\ref{src:parsedArgs}の処理そのものであるため、この処理の中に未実装のAPIを検知する様にした。
308 呼び出し元のInterfaceの情報パースした結果、ヘッダファイルにAPIの定義がなかった場合は11行目の\texttt{unless}に処理が落ち、 エラー終了する。
309 これによってInterface呼び出しの問題が、 Perlスクリプトによって変換する前に検知可能になった。
289 310
290 \section{par goto のInterface経由の呼び出しの対応} 311 \section{par goto のInterface経由の呼び出しの対応}