組み込みアプリケーション開発、特にセットトップボックス(STB)やデジタル家電、携帯電話などそれなりのUIを要求される製品の開発では、Webブラウザを搭載しユーザーインターフェース(UI)をHTML+JavaScriptで構築することがあります。この手法のメリットとして以下のようなことが挙げられます。

1. UIとロジックの分離

   家電製品に搭載するような画面の動きをプログラマが全てコードで記述しようとすると大変です。UIをHTML(+CSS)で記述できれば画面作成はデザイナーにお願いし、プログラマーはロジックに集中できます。最後のUIとロジックの結合作業はプログラマー側に残りますが…

2. 開発工数の削減

   UIをHTMLで記述できれば、C/C++やJavaで記述するのに比べて開発効率の向上が見込まれます。それに伴い、工数削減、開発期間短縮が期待出来ます。

3. 豊かな表現力、操作性の実現

   ブラウザがFlashなどのプラグインを使用できれば高度な視覚効果を比較的簡単に実現出来ます。

本記事では、これらのメリットをPC上のアプリケーションにも適用することを目指し、サンプルアプリケーションの作成を行います。

システム構成

UIにWebブラウザを利用する場合の典型的なシステム構成は次のようになります。この場合、UIと処理エンジンはブラウザを介して双方向に通信し、連携して動作します。

図１：組み込みブラウザを使った一般的な構成図

“組み込み ブラウザ” をキーワードにネットで検索すれば、多くの組込み用ブラウザ製品がヒットし、この図と同じような資料や説明が見つかると思います。

今回はブラウザ機能にWebKit、アプリケーションロジックにPythonを使い、上の図と似たような構成のアプリケーションを作っていきます。

WebKitとは

オープンソースのHTMLレンダリングエンジンの一つで、Appleの「Safari」や、Googleの「Google Chrome」などのWebブラウザに使われています。
Webブラウザ以外では、Appleの「iTunes」、Googleの「Android」などに使われています。

Pythonとは

プログラミング言語の一つです。Perl、PHP、Rubyと比較されるスクリプト言語です。

なぜPythonなのか

Pythonネタを探してて、このネタに辿り着いたというのが本音ですが….それはおいといて、

Androidであれば、WebKit + Java の開発環境をGoogleが用意してくれています。また、Mac OS 上ならWebKit + Objective-C が使えます。これらの組み合せであればネット上で豊富な資料が入手可能ですが、それなりの開発環境構築の手間がかかります。

WebKit自体は、各種バインディングを利用すれば、特定の言語に縛られず様々な言語から利用出来ます。今回は言語の一例としてPythonを取り上げ、お手軽なアプリケーション開発を目指します。

準備するもの

今回のアプリケーション開発・実行には、次のソフトウェアが必要になります。(必要な順に挙げています)

OS – Linux

記事の作成にはUbuntu9.10と、9.04を使用しました。

Ubuntu以外のディストビリューションでも動作可能と思います。(勿論、BSD系でも)

WebKit

WebKit公式ページ

私の環境では、Google Chrome (Linux版) をインストールした時に、同時にインストールされました。
Ubuntuの場合、後述するpython-webkitをインストールすると一緒に入るかも？（未確認です）

Python

Python公式ページ

UbuntuでX Window Systemを使っている場合、デフォルトでインストールされます。
他のディストリビューションでもデフォルトでインストールされているか、簡単にインストール出来ると思います。

python-webkit

http://code.google.com/p/pywebkitgtk/

正式名称は、WebKit/Gtk Python bindings で、Python+GTK の環境からWebKitを利用できるようにします。

Ubuntuの場合、apt-getでインストール出来ます。

$ sudo apt-get install python-webkit

python-jswebkit

PythonとJavaScriptエンジンの連携を実現します。

公式HPは、上述のpython-webkitと同じようですが、何故かこちら(gwrite)にソースコードが置いてあります。

http://code.google.com/p/gwrite/downloads/list

Ubuntu9.10の場合、上のURIに登録されているパッケージを使えば、簡単にインストール出来ます。

• 32bit版パッケージ
• 64bit版パッケージ

それ以外の方は、

http://gwrite.googlecode.com/files/python-jswebkit-0.0.1.tar.gz

をダウンロードして解凍します。

解凍後、インストールスクリプトを実行します。

$ sudo python setup.py install

インストールの際、libwebkit-dev が必要です。/usr/include/webkit-1.0/以下のファイルを要求された場合は、libwebkit-devをインストールして下さい。

WebKitとPythonでどんなことが出来るか？

python-webkitについてくるサンプルアプリケーションを実行してみましょう。

Ubuntu9.10 (python-webkit 1.1.5-1) の場合、

$ /usr/share/doc/python-webkit/examples/tabbed_browser.py

Ubuntu9.04 (python-webkit 1.0.2-1) の場合、

$ /usr/share/doc/python-webkit/examples/webbrowser.py

問題がなければ、次のようなアプリが起動するはずです。

…立派なWebブラウザが実行されましたね。

ということで、Webブラウザは既にあるので、今回はWebブラウザ以外を目指すことにします。

クリアすべき課題

単にダイアログにWebKitをはめ込んでHTMLのページを表示だけでは面白くありません。(単なるブラウザです)

UI(HTML+JavaScript)とアプリケーションロジック(Python)が連携してアプリケーションらしい動きを目指します。

そのためには、

1. PythonからJavaScriptの呼び出し
2. JavaSctiptからPythonの呼び出し

を行う必要があります。

その上で、JavaScriptだけでは実現できないような機能をPython側で行います。

PythonからJavaScriptの呼び出し

python-jswebkit を利用します。

JavaScriptCoreのインスタンスを取得し、EvaluateScript()メソッドを使って呼び出します。以下にサンプルを示します。

記述例

1. インポート

   import webkit
   import jswebkit

2. ‘load-finished’シグナルのハンドラで、JavaScriptCoreを取得

   def _cb_load_finished(self, view, frame):
       gc = frame.get_global_context()
       self._javascript = jswebkit.JSContext(gc)

3. JavaScriptコードを実行

   result = self._javascript.EvaluateScript('JavaScriptのコード')

JavaScriptの記述方法

上の例の ‘JavaScriptのコード’ の部分には、任意のJavaScriptのコードを記述できます。

1. 関数名()を書けば、JavaScriptの関数を実行出来ます。

   ret = self._javascript.EvaluateScript('foo()')

   と実行すると、JavaScriptのfoo()関数が実行されます。

2. グローバル変数名を書けば、変数の値を取得出来ます。

   JavaScriptで

   var hoge="hogeの中身";     // これはグローバル変数

   と書いおいて、Pythonから

   result = self._javascript.EvaluateScript('hoge')

   と実行すると、result変数に Javasctript変数「hoge」の値 「hogeの中身」 が格納されます。

補足

もっと簡単にJavaScriptを呼び出す方法として、python-webkit のwebkit.WebView.execute_script()メソッドを使うという方法もありますが、この方法ではJavaScriptの実行結果を取得出来ないため、今回は採用していません。

JavaSctiptからPythonの呼び出し

Android(WebKit+Java)であれば、addJavaScriptInterface()でJava側のインターフェースを登録しておけばJavaScriptから簡単に呼び出せるのですが…
python-webkit, python-jswebkitの両方でいろいろ試しましたが、どちらを使っても JavaScript -> Pythonの呼び出しがうまく出来ませんでした。

そのため今回は、JavaSctiptからPythonの呼び出しはあきらめ、Python側からJavaScriptの関数を定期的に呼び出してメッセージを取得することにします。

アプリケーションの仕様

今回作成するアプリケーションの仕様を定義します。

基本仕様

選択された画像ファイルを表示するアプリケーション、ということにします。基本機能は次の通りです。

1. ユーザーが指定したフォルダにあるファイルの一覧を表示する。
2. ユーザーが選択したファイルの画像を表示する。

この仕様に決めた理由

次のような理由から、アプリケーションの仕様を決めました。

1. JavaScriptのみで実現不可能

   JavaScriptからローカルリソースにアクセス出来ないため、JavaScriptのみでファイル一覧を表示することは出来ません。この部分をPythonと連携して実現することで単なるブラウザ以上のことを実現します。

2. UIにブラウザを使うメリットを享受出来る。

   さまざまな画像ファイルのフォーマットを知らなくても、ブラウザさえ対応していれば簡単に画像を表示できます。「ブラウザの機能が使えて良かった」と実感出来ると思います。

画面イメージ

画面イメージは下の通りです。

制限事項

本記事のコンセプトに合わせて、アプリケーション作成に以下の制限を設けました。

1. UIは全てHTML+JavaScript(+CSS) で作成する。

   Pythonにはダイアログ表示以外のUIの機能を持たせません。
   ダイアログも全領域にWebKitを表示するだけです。

2. 表示ファイル(html)はローカルに持ち、ファイル名固定で良い。

   ブラウザではないので、手元にあるファイルの表示で十分です。

アプリケーションの使い方

今回作成したサンプルアプリケーション一式はここにあります。

サンプルアプリケーション一式

ファイルをダウンロードして解凍すると次のファイルが出てきます。

menu.html
image_viewer.py
no_image.png

以下のように入力してアプリケーションを起動します。

$ python image_viewer.py

成功すれば、先に挙げた実行画面が現れると思います。

使い方は次の通りです。

1. Directory: に画像ファイルのあるパスを指定。

   実行画面例では、GIMPを画像フォルダ /usr/share/gimp/2.0/imagesを指定しています。

2. [ファイル一覧更新]ボタンを押す。
3. リストボックスにファイル一覧が表示されるので、画像ファイルを選択。

   画像表示領域に、選択した画像ファイルを表示します。
   画像以外のファイルを選択すると、画像表示領域に「NO IMAGE」と表示します。

4. 1 に戻って、別のパスを指定することも可能。

アプリケーションの解説

作成したアプリケーションについて説明します。

シナリオ

アプリケーションの利用シナリオを定義します。

登場するアクター、機能は次の通りです。

1. ユーザー
2. UI (HTML+JavaScript)
3. Python

今回は、次の３つの操作シナリオを想定しました。

ファイル一覧表示

1. ユーザーが、パスを入力し[ファイル一覧更新]ボタンを押して確定する。
2. UIは、パス名をJavaScriptのグローバル変数に格納する。
3. Pythonは、
   1. 定期的にJavaScript関数を呼び出し、パス名を監視する。
   2. パス名を取得できたら、指定パスにあるファイル名のリストを作成する。

      JavaScriptからファイル一覧を作成することは出来ません。そのためファイル一覧の作成をPython側で行います。

   3. JavaScript関数を呼び出し、ファイルリストを渡す。
4. UIは、リストボックスにファイルリストを登録する。(リストの内容は全更新)

画像表示

1. ユーザーがリストボックスからファイルを一つ選択する。
2. UIは、
   1. ファイル選択イベントを監視し、
   2. 選択されたファイルをimageエリアに画像を表示する。

      選択ファイルが画像以外の場合、あらかじめ決められた画像(”NO IMAGE”)を表示

終了

1. ユーザーが、 [終了]ボタンを押す。
2. UIは、JavaScriptのグローバル変数に終了リクエストを格納する。
3. Pythonは、
   1. 定期的にJavaScript関数を呼び出し、終了リクエストを監視する
   2. 終了リクエスト：ONなら、プログラムを終了する

ファイル構成

本アプリケーションは、次の３つのファイルから構成されます。

1. menu.html

   UIを実装したHTML(+JavaScript)ファイルです。

2. image_viewer.py

   WebKitの表示を行うPythonスクリプトです。

3. no_image.png

   画像以外のファイルを選択されたときに表示する画像ファイルです。

設計資料

内部構成

アプリケーションの内部構成(WebKit, UI, Python ) は次の様になっています。

呼び出しは、Python -> JavaScript の一方向のみで、次の２つの呼び出しを行っています。

• イベント監視

  GUIのイベントが発生してもJavaScriptからPythonのコードを呼び出せないため、自発的にイベントを通知することが出来ません。そのため、JavaScript側ではイベントをキューにストアしておき、Python側からタイマーイベントで定期的にJavaScriptのget_event()関数を呼び出してイベントを取り出しています。

• ファイル一覧通知

  ファイル一覧を更新するときに、JavaScriptのset_file_list()関数を呼び出します。

それでは、実際のソースコードについて説明していきます。

Python側のソースコード (image_viewer.py)

まずは、Python側のソースから見ていきます。

#!/usr/bin/env python
# coding: UTF-8
from gettext import gettext as _
import gtk
import webkit
import gobject
import jswebkit
import time
import sys
import dircache
import os

class WebBrowser(gtk.Window):

    def __init__(self):
        """
        (処理)
        1. WebKitのインスタンスを生成し、ダイアログへ追加
        2. シグナル(’load-finished’)に対するコールバック関数(_cb_load_finished)の登録
        3. ダイアログを表示
        4. UI定義ファイル(menu.html)を表示
        """
        gtk.Window.__init__(self)

        self._cmd = {'update':self._cmd_update, 'quit':self._cmd_quit }

        self._browser = webkit.WebView()
        self._browser.connect('load-finished', self._cb_load_finished)
        self.add(self._browser)

        self.set_size_request(640, 460)
        #self.fullscreen()

        self.connect('destroy', gtk.main_quit)
        self.show_all()
        self._browser.open("file://menu.html")

    def _cb_load_finished(self, view, frame):
        """
        シグナル(’load-finished’)に対するコールバック関数。
        HTMLコンテンツのロードが完了したときに、シグナルが通知(コールバック)される。
        (処理)
        1. JavaScriptCore(JavaScript実行エンジン)の取得(メンバー変数に登録)
        2. 監視タイマーの登録
        """
        print "=> load-finished"
        gc = frame.get_global_context()
        self._javascript = jswebkit.JSContext(gc)
        self._set_timer()

    def _set_timer(self):
        gobject.timeout_add(100, self._cb_timer, None)

    def _cb_timer(self, params) :
        """
        タイマーハンドラ
        (処理)
        1. JavaScriptの get_event()関数を呼び出してメッセージ取得
        2. メッセージ対応したハンドラ関数を実行
        """
        event = self._javascript.EvaluateScript('get_event()')
        if event != None:
            print "event[", event, "]"

            params = event.split()
            if self._cmd.has_key(params[0]):
                self._cmd[params[0]](params[1:])
            else:
                print "### err: event[", params[0], "] unknown ###"

        self._set_timer()

    def _cmd_update(self, params):
        """
        “update”メッセージハンドラ関数
        ファイル一覧を取得し、UIへ通知する。
        """
        resp = 'set_file_list("' + os.path.abspath(params[0]) + os.sep + '", ['
        for file in dircache.listdir(params[0]):
            resp += ('"' + file + '",')
        resp += '])'
        #print resp
        self._javascript.EvaluateScript(resp)

    def _cmd_quit(self, params):
        """
        “quit”メッセージハンドラ関数
        直ちにプログラムを終了する。
        """
        sys.exit()

if __name__ == "__main__":
   gobject.threads_init()
   webbrowser = WebBrowser()
   gtk.main()

補足

JavaScriptCoreの取得は、_cb_load_finished()メソッドで行っています。

gc = frame.get_global_context()
self._javascript = jswebkit.JSContext(gc)

JavaScriptの実行は以下の様に行っています。(_cmd_update()メソッド)

event = self._javascript.EvaluateScript('get_event()')

UI側のソースコード (menu.html)

次にUI側(HTML+JavaScript)のコードです。

<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Webkit+Python Sample Application</title>

<style type="text/css">
<!--
div.left_block {float: left; width: 50%;}
div.right_block{float: right; width: 50%;}
-->
</style>

<script type="text/javascript">
<!--
/**
 *  Pyton側へ通知するイベントのキューイングに使用
 */
function Queue(){
	this._queue = new Array();
}

Queue.prototype.push = function(item){
	this._queue.push(item);
}

Queue.prototype.pop = function(){
	return this._queue.length ==0 ? null : this._queue.shift();
}

Queue.prototype.empty = function(){
	return this._queue.length == 0 ? true : false;
} 

var event = new Queue();
var workpath = ".";

/**
 *  [ファイル一覧更新]ボタンが押されたとき、キューにメッセージを格納
 */
function on_update(){
	var target_path = document.form.location.value;
	if(0 < target_path.length){
		event.push("update " + document.form.location.value);
	}
}

/**
 *  [終了]ボタンが押されたとき、キューにメッセージを格納
 */
function on_exit(){
	event.push("quit");
}

/**
 * Python から定期的に呼び出される。
 * キューの先頭にあるメッセージを返す。（キューが空なら null を返す）
 */
function get_event(){
	return event.empty() ? null : event.pop();
}

/**
 * Python からファイル一覧の通知時に呼び出される。
 * ファイル一覧リストボックスの内容を更新する。
 */
function set_file_list(path, list){
	workpath = path;
	var file_list = document.result.file_list;

	while(0 < file_list.length ){
		file_list.removeChild(le_list.options[0]);
	}

	for(var i=0; i<list.length; i++ ){
		file_list.options[file_list.options.length] = new Option(list[i], list[i]);
	}
}

/**
 * ユーザーがファイルを選択した時のイベントハンドラ
 * ファイルを画像領域に表示する。
 */
function on_select(){
	var file_list = document.result.file_list;
	var index = file_list.selectedIndex;
	var uri = "file://" + workpath + file_list.options[index].text;

	document.image1.src = uri;
	//console.log(uri);
}

/**
 * ファイルを画像として表示出来なかったときのイベントハンドラ
 * 代わりにno_image.pngを表示する。
 */
function on_image_error(){
	document.image1.src = "file://no_image.png";
}

//-->
</script>
</head>

<body bgcolor='lavender'>
  <form name="form" >
    Directory: <input type="text" name="location" style="width:80%"/>
  </form>
  <button style="width:100%" onClick='on_update()' >ファイル一覧更新</button>
  <div class="left_block">
    <form name="result">
      <select name="file_list" style="width:90%" size=17 onChange='on_select()'></select>
    </form>
  </div>
  <div class="right_block">
    <a id="image" width="320" height="320" >
      <img name="image1" src="file://no_image.png" alt="" onerror='on_image_error()'/>
    </a>
  </div>

  <button style="width:100%" onClick="on_exit()" >終了</button>
</body>
</html>

補足

Pythonへ渡すメッセージはQueueオブジェクトに格納します。

Python から呼び出される関数は、次の２つです。

• get_event()
• set_file_list(path, list)

あとがき

今回は組込みソフトウェアの手法をデスクトップアプリケーションに適用してみました。

WebKitをUI構築ツールの一つと捉えると、非常に便利な開発用ライブラリと考えることが出来ると思います。(GoogleのAndroidもそれを狙っているのでしょうけど)

最初のほうにも述べましたが、WebKitは各種言語向けバインディングを利用することにより、いろいろな言語から利用出来ます。現時点(2010年2月)ではその辺りの情報が少ないかな？と思うので、本記事が参考になれば幸いです。

機会があれば、Pythonに限らず、Perl, Ruby, PHPなど、皆さんの慣れ親しんだ言語との組み合わせをぜひ試してみて下さい。

AT&T研究所が開発したグラフ描画ツールです。
ただし、折れ線グラフや棒グラフみたいなExcelで作成するようなグラフではなく、ダイヤグラムや有向グラフなどが対象となります。

Graphvizの公式サイト

Graphvizを使うことにより、高品質な有向グラフを作成することが出来ます。どんなグラフを作成できるかは、Graphviz公式サイト 生成したグラフのサンプルを参照して下さい。

ソフトウェア技術者の方にとっては、Graphivizの使い方はそれほど難しくありませんし、ネットで検索すれば多くの解説記事が見つかります。
そのため本記事ではGraphvizの説明は最低限に留め、Graphvizをどのように活用していくかに焦点を当てていきます。

基本的な使い方

まずは Graphvizを全く知らない人のために、簡単なグラフ作成手順を紹介しておきます。

作成手順

1. DOT言語のスクリプトを作成し
2. dotコマンドを使って、スクリプトからグラフを作成します。

使ってみよう

まずは簡単なdotスクリプトを作成してみます。

dottest.dot

digraph sample{
  graph [rankdir = LR];
  one -> two;
  one -> three;
  two -> four;
  two -> five;
  five -> six -> seven;
}

スクリプトの詳細は後回しにして、まずはdotコマンドを使ってグラフ画像を作ってみましょう。

dotコマンドの書式

dotコマンドの基本的な使い方は以下の通りです。

 dot -T[出力形式] [スクリプトファイル名] -o [出力ファイル名]

• -Tで画像形式を指定します。

  bmp, jpeg, png, tiff, その他が指定できます。どんな形式で出力可能かは、Graphviz公式サイト Output Formatsを参照して下さい。

• -o で出力ファイル名を指定します。指定しない場合、標準出力に出力します。
• その他、細かいオプションは、Graphviz公式サイト Command-line Invocationを参照して下さい。

実行例

以下のように実行します。

$ dot -Tpng dottest.dot -o dottest.png

成功すれば、次のような画像ファイルが作成されます。

変換結果：dottest.png

dotスクリプトの説明

上で使ったdotスクリプトについて簡単に説明します。

digraph sample{
  ...
}

スクリプト全体を、"digraph [ID]{" ～ "}" で囲みます。
IDには任意の名前をつけることが出来ます。ただし使用できる文字に制限があります。

  graph [rankdir = LR];

グラフを横方向に作成するオプションで、省略可能です。 省略した場合、縦方向にグラフが作成されます。

  one -> two;

ノードとノードをエッジ("->") で連結して記述します。

 five -> six -> seven;

このように３つ以上を一度に記述することもできます。

ノード名

ノード名にはアルファベット[a-zA-Z]、アンダースコア('_')、数字[0-9]が使えます。 ただし、以下の制限があります。

• 数字から始まってはいけません（C言語等の変数名の制限と同じですね)
• ハイフン('-'), > は使えません (エッジで使用します)
• 空白(' ')も使えません(単語の区切りになります)

上記のルールに抵触するノード名を表示したい場合、ノード名は上記のルールに従った上で、

ノード名 [label="表示名"]

のように、label属性で表示文字列を指定します。

Graphvizの公式サイトには、もっと詳しい説明があります。

• ドキュメントのTOPページ
• ノードの形の指定
• エッジの形の指定
• 色の指定
• 属性一覧

少し凝ったスクリプト

次にもう少し凝った、多少意味のあるグラフを作ってみましょう。

題材はBSDの系譜図です。

The UNIX system family tree: Research and BSD を参考にしました。ただし、全て再現すると大変なので、一部(?)省略しています。

digraph BSD{
  graph [rankdir = LR];

  _43BSD_NET2 [label="4.3BSD NET/2", shape=box];
  _386BSD [label="386BSD"];
  _43BSD_NET2 -> _386BSD;

  _44BSD [label="4.4BSD"];
  _43BSD_NET2 -> _44BSD;

  BSD386 [label="BSD/386"];
  _43BSD_NET2 -> BSD386;
  _43BSD_NET2 -> NetBSD;

  subgraph cluster0{
    label="(NetBSD)";
    color=lightgray;
    NetBSD [label="NetBSD"];
    NetBSD_current [label="NetBSD -current", color=yellow, style=filled];
    NetBSD -> NetBSD_current;
  }
  _386BSD -> NetBSD;
  _44BSD -> NetBSD;

  subgraph cluster1{
    label="(FreeBSD)";
    color=lightgray;
    FreeBSD [label="FreeBSD"];
    FreeBSD_current [label="FreeBSD 9 -current", color=yellow, style=filled];
    FreeBSD -> FreeBSD_current;
  }
  _386BSD -> FreeBSD;
  _44BSD -> FreeBSD;

  DragonFly [label="DragonFly", color=yellow, style=filled];
  FreeBSD -> DragonFly  [label="FreeBSD 4.8", fontcolor=blue, fontsize=9];

  BSD_OS [label="BSD/OS"];
  BSD386 -> BSD_OS;
  _44BSD -> BSD_OS;

  subgraph cluster2{
    label="(OpenBSD)";
    color=lightgray;
    OpenBSD [label="OpenBSD"];
    OpenBSD_current [label="OpenBSD -current", color=yellow, style=filled];
    OpenBSD -> OpenBSD_current;
  }
  NetBSD -> OpenBSD;

  subgraph cluster3{
    label="(Mac OS X)";
    color=lightgray;

    Rhapsody [label="Rhapsody", color=lightblue, style=filled];
    Darwin [label="Darwin/Mac OS X", color=lightblue, style=filled];
    MacOSX [label="Mac OS X", color=lightblue, style=filled];
    Rhapsody -> Darwin -> MacOSX;
  }
  FreeBSD -> Darwin [label="FreeBSD 3.2", fontcolor=blue, fontsize=9];
  NetBSD -> Darwin [label="NetBSD 1.4 (?)", style=dotted, fontcolor=blue, fontsize=9];
  _44BSD -> Rhapsody;
}

コードの補足

上のコードについて、少し説明しておきます。

ノード

今回の題材では、

• "4.4BSD" (違反：数字で始まっている)
• "FreeBSD 9 -current" (違反：禁止文字(空白,ハイフン)を含む)

のように、そのままではノード名に使えない名詞が多いため、アンダースコア('_')に置き換えたりして制限を回避しています。全く違う名称に置き換えても良いのですが、自分で書いてて混乱しそうなので元の名称を参考にしました。

グラフに表示するテキストはlabel属性で指定しています。

_43BSD_NET2 [label="4.3BSD NET/2", shape=box];

ノードの属性を指定する時は、上記のように先にノード情報のみを定義しておきます。

ノードとノードの連結は、別の行で定義します。

_43BSD_NET2 -> _44BSD;

エッジ

エッジも修飾可能です。

FreeBSD -> DragonFly  [label="FreeBSD 4.8", fontcolor=blue, fontsize=9];

デフォルトではフォントサイズ：14ですが、ここでは少し小さめのサイズ：9を指定しています。またフォントカラーに青色を指定しています。

サブグラフ

また、subgraph 機能を使って、いくつかのサブグラフを指定しています。
またサブグラフのIDを“cluster”で始めると、枠を描画してくれます。

  subgraph cluster0{
    ...
  }

変換結果

このスクリプトをdotコマンドで変換すると、以下のような結果を得られます。

正しい使い方

ここまでの説明で、がんばれば凝ったグラフを作成できることは分かって頂けたと思いますが、 VISIOとかで書いた方が楽じゃんと思った人もいるかもしれません …それは正しいです。

人がスクリプトをごりごり書くのではなく、下の図のようにプログラムで自動生成したdotスクリプトからグラフを自動生成というのがGraphvizの正しい使い方と思います。(たぶん)

この図もGraphvizを使って作成しています。ソースコード

日本語も無事通ってますね。ドキュメントによるとUTF-8をサポートしています。

どうやって使うの？

普通はユーザーが知らない間にソフトウェアが裏でこっそりGraphvizを使ってグラフを自動生成 …というパターンになります。

私がお世話になっている以下のソフトウェアでも Graphvizを利用しています。

• doxygen

  ソースコードからドキュメントを自動生成するツールです。
  UML図は、関数呼び出し図などの作成に利用しています。

• KCachegrind

  Valgrind/Callgrind(プログラムのプロファイル用ツール)をアシストするデータ視覚化ツールです。
  プロファイル情報を視覚化して表示してくれます。

• visitors

  WEBサーバのアクセスログの解析ツールです。
  ユーザのページ遷移をグラフ化してくれます。

上で挙げたツールは全て技術者向けなので「裏でこっそり」とはいかず、ユーザーはGraphvizの存在を意識することになりますが…
(さすがに、自動生成するdotスクリプトの中身までは読む必要はありませんが)

正しく使ってみよう

裏でこっそりやってくれるんなら関係ないや…という結論だと後が続かないので、ここは一つ裏でこっそりやってくれるプログラムを作ってみましょう。

プログラムの仕様

今回はXMLファイルを題材としたサンプルを作ってみます。

仕様

今回作成するプログラムの仕様は次の通りです。

XMLファイルを読み込んで、要素(エレメント)をdotのノードに変換して、dotスクリプトを出力する。
ただし、全てのエレメントの親子関係を線で結ぶこと。

親子関係を表現するには、Rootエレメントを起点に、全エレメントを “親エレメント -> 子エレメント;” と継いで出力すれば可能です。

このプログラムを使ったグラフ作成の流れは次の様になります。赤い部分が今回の作成対象です。

期待する動作

入力

例えば、次のようなXMLファイルを受けとると、

addressbook.xml

<?xml version="1.0" encoding="UTF-8"?>
<addressbook>
    アドレス帳
    <person>
      <name>foo</name>
      <address>osaka</address>
      <phone>0120-xxx-xxx</phone>
    </person>
    <person>
      <name>hoge hoge</name>
      <address>kobe</address>
      <phone>0120-yyy-yyy</phone>
    </person>
</addressbook>

結果

dotスクリプトを出力し、それをdotコマンドで変換すると次のような結果が得られます。

addressbook.png

注意事項

1. dotでは、同じノード名は同じノードと扱うので、同じエレメント名が複数回出現したとき、それぞれを違うノード名を割り当てる必要があります。
2. XMLのエレメントで使えるが、dotのノード名で使えない文字があります。
   例えば、dotではノード名にハイフン('-')は使えません。出現したら何らかの対処が必要です。

今回はプログラムで自動生成する(=人が介在しない)ので、ノード名にはXMLエレメント名と関係ないユニークなIDをつける事にします。表示するXMLエレメント名はlabel属性で指定します。

サンプルプログラム

せっかく入力がXMLなので、XSLTスタイルシートで作成しました。

xml2dot.xml

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
   version="1.0">

  <xsl:strip-space elements="*" />
  <xsl:output method="text" encoding="UTF-8"></xsl:output>

  <xsl:template match="/">
    <xsl:text>digraph sample{ graph [rankdir = LR];
</xsl:text>
    <xsl:apply-templates></xsl:apply-templates>
    <xsl:text>}</xsl:text>
  </xsl:template>

  <xsl:template match="*">
    <xsl:param name="id"><xsl:value-of select="generate-id()"></xsl:value-of></xsl:param>
    <xsl:param name="parent-id"></xsl:param>

    <xsl:value-of select="$id"></xsl:value-of><xsl:text> [label = "</xsl:text>
    <xsl:value-of select="name()"></xsl:value-of>
    <xsl:text>", color=cyan, style=filled]; </xsl:text>
    <xsl:if test="../..">
      <xsl:value-of select="$parent-id"></xsl:value-of>
      <xsl:text> -> </xsl:text>
      <xsl:value-of select="$id"></xsl:value-of>
      <xsl:text>; </xsl:text>
    </xsl:if>
    <xsl:text>
</xsl:text>
    <xsl:apply-templates>
      <xsl:with-param name="parent-id"><xsl:value-of select="$id"></xsl:value-of></xsl:with-param>
    </xsl:apply-templates>

  </xsl:template>

  <xsl:template match="text()">
    <xsl:param name="id"><xsl:value-of select="generate-id()"></xsl:value-of></xsl:param>
    <xsl:param name="parent-id"></xsl:param>

    <xsl:value-of select="$id"></xsl:value-of>
    <xsl:text>_text [label = "</xsl:text>
    <xsl:value-of select="normalize-space()"></xsl:value-of>
    <xsl:text>", shape=box, color=yellow, style=filled]; </xsl:text>
    <xsl:value-of select="$parent-id"></xsl:value-of>
    <xsl:text> -> </xsl:text>
    <xsl:value-of select="$id"></xsl:value-of>
    <xsl:text>_text; </xsl:text>
    <xsl:text>
</xsl:text>
  </xsl:template>

</xsl:stylesheet>

使い方

実行にはXSLTプロセッサが必要です。ここでは2種類(libxml, MSXSL) のXSLTプロセッサでの実行方法について説明します。

libxml

Unix系, Windowsの両方で使用可能です。

$ xsltproc  -o [出力ファイル名]  [XSLTスタイルシート]  [入力XMLファイル]

引数説明

• -o 出力ファイル名
  生成したdotファイル名の保存先を指定します。
  -o オプションを省略すると標準出力に出力します。
• XSLTスタイルシート
  xml2dot.xmlを指定します。
• 入力XMLファイル
  addressbook.xml を指定します。

Windowsユーザーでlibxmlを試したい方はlibxmlの公式サイトから取得してください。

MSXSL (Windows only)

Microsoft製のXSLTプロセッサで、Windows限定です。
libxmlと引数の順番が異なるので注意して下さい。

$ msxsl  [入力XMLファイル]  [XSLTスタイルシート]  -o [出力ファイル名]

Microsoft Download Centerから取得できます。

実行例

次のように実行します。

libxml

$ xsltproc -o addressbook.dot xml2dot.xsl addressbook.xml

MSXSL

$ msxsl addressbook.xml xml2dot.xsl -o addressbook.dot

成功すれば、次のようなファイルが作成されます。ただし、生成する度にノード名は違う値になっていると思います。

addressbook.dot

digraph sample{ graph [rankdir = LR];
id2273096 [label = "addressbook", color=cyan, style=filled];
id2273047_text [label = "アドレス帳", shape=box, color=yellow, style=filled]; id2273096 -> id2273047_text;
id2272492 [label = "person", color=cyan, style=filled]; id2273096 -> id2272492;
id2273073 [label = "name", color=cyan, style=filled]; id2272492 -> id2273073;
id2273057_text [label = "foo", shape=box, color=yellow, style=filled]; id2273073 -> id2273057_text;
id2273123 [label = "address", color=cyan, style=filled]; id2272492 -> id2273123;
id2273124_text [label = "osaka", shape=box, color=yellow, style=filled]; id2273123 -> id2273124_text;
id2273121 [label = "phone", color=cyan, style=filled]; id2272492 -> id2273121;
id2272599_text [label = "0120-xxx-xxx", shape=box, color=yellow, style=filled]; id2273121 -> id2272599_text;
id2272603 [label = "person", color=cyan, style=filled]; id2273096 -> id2272603;
id2272938 [label = "name", color=cyan, style=filled]; id2272603 -> id2272938;
id2272939_text [label = "hoge hoge", shape=box, color=yellow, style=filled]; id2272938 -> id2272939_text;
id2272941 [label = "address", color=cyan, style=filled]; id2272603 -> id2272941;
id2272942_text [label = "kobe", shape=box, color=yellow, style=filled]; id2272941 -> id2272942_text;
id2272944 [label = "phone", color=cyan, style=filled]; id2272603 -> id2272944;
id2272945_text [label = "0120-yyy-yyy", shape=box, color=yellow, style=filled]; id2272944 -> id2272945_text;
}

これをdotコマンドを使って画像ファイルに変換します。

$ dot -Tpng addressbook.dot -o addressbook.png

出来た画像ファイルをブラウザ等で開いて確認して下さい。

今回作成したXSLTスタイルシート(xml2dot.xml)を使えば色々なXMLファイルが変換可能です。
皆さんの手元にあるXMLファイルで実験してみて下さい。

別の実行方法

以下のように変換プログラムとdotコマンドをパイプで連結して1行で処理することもできます。

$ xsltproc  xml2dot.xsl  addressbook.xml  | dot -Tpng  -o addressbook.png

最後に

今回は、いかにGraphvizを実務に適用するかに焦点を絞って説明しました。

Graphvizを使ってグラフを作成するメリットとして、以下のような事が挙げられると思います。

1. レイアウトの自動化

   ノードが増えても、Graphvizが賢くレイアウトを整えてくれます。私はこれが嬉しいです。

2. ソースコードのシンプル化

   よくある描画ライブラリのように、線を一本ずつ書いたり、色をつけたり、dot位置を調整する必要がありません。

有向／無向グラフにターゲットを絞ったツールなので万能という訳には行きませんが、適用できれば非常に便利なツールと思います。
機会があれば、ぜひ使ってみてください。

• 抽象データ型
• 継承
• 多態

をオブジェクト指向の三本柱などと称しています。その中でも抽象データ型(あるいはデータの抽象化)はオブジェクト指向の最も基本的で重要な概念ではないかと考えます。

"データを抽象化する"とは、データをそれに対して適用できる操作の集合で定義することです。

簡単な例として"カウンタ"を考えてみましょう。カウンタには3つの操作:

• +1する (increment)
• -1する (decrement)
• 現在値を取得する

を提供させることにします。

さて、このカウンタをCで実現するとどうなるでしょうか…

typedef struct {
  long value_;
} Counter;

Counter* counter_create();
void     counter_incr(Counter*);
void     counter_decr(Counter*);
long     counter_value(const Counter*);
void     counter_release(Counter*);

/* ---- ここから実装部。Counterの利用者には見せない ---- */

Counter* counter_create() {
  Counter* c = (Counter*)malloc(sizeof(Counter));
  c->value_ = 0;
  return c;
}

void     counter_incr(Counter* c) { ++c->value_; }

void     counter_decr(Counter* c) { --c->value_; }

long     counter_value(const Counter* c) { return c->value_; }

void     counter_release(Counter* c) { free(c); }

…こんな感じになりますか。C++の入門書の中には、

データ(構造体) + アルゴリズム(関数) = オブジェクト(クラス)

と説明されたものもあります。つまり、構造体に、それに適用される操作を付け加えたものがクラスだ、というのです。

class Counter {
private:
  long value_;
public:
  Counter();
  ~Counter();
  void incr();
  void decr();
  long value() const;
};

/* --- ここから実装部。Counterの利用者には見せない --- */

Counte::Counter() : value_(0) {}

Counte::~Counter()  {}

void Counter::incr() { ++value_; }

void Counter::decr() { --value_; }

long Counter::value() const { return value_; }

Counterのメンバ変数value_は、利用者に勝手にアクセスさせないようprivate部に置きました。

カウンタの利用者にしてみればprivateメンバに何が定義されているかなんて(どうせアクセスできないのだから)知る必要もありません。+1できて、-1できて、値を取得できるということだけで十分です。

カウンタの実装者にしても同様です。+1する、-1する、値を返す、の3つの機能をきちんと実装できるのなら、privateメンバはその実現のためになら何を定義しようがかまわない。メソッドが呼ばれるたびに電話回線を通してはるか遠くにあるデータベースを更新・参照したっていいでしょうよ。

結局カウンタについて利用者と実装者との間できめておかなければならないのは、カウンタに対する操作だけなんです。

"Xに対して何ができるか"で定義したX、それが抽象データ型なんですね。

Javaにおける抽象データ型

Javaは、抽象データ型を直接サポートするキーワードinterfaceを持っています。

public interface Counter {
  void incr();
  void decr();
  int  value();
}

interfaceはclassではありません。実体が存在しません。Counterの実装者はinterfaceを実装(implements)するclassを作ります。

class CounterImpl implements Counter {
  private int value_;
  public CounterImpl() { value_ = 0; }
  // interface Counter を実装する
  public void incr() { ++value_; }
  public void decr() { --value_; }
  public int value() { return value_; }
}

利用者にCounterImplの存在を気づかせないために、Counterを生成するクラスCounterFactoryを用意しましょう。

public class CounterFactory {
  public static Counter create() { return new CounterImpl(); }
}

CounterFactory.create()はCounterImplをnewし、それをCounterとして返します。利用者にはCounterFactory.create()で手に入れたオブジェクトが実際にはCounterImplだということを隠しています。それでいいんです。利用者が欲しがっているのはCounterImplではなく、Counterに対する操作なのですから。

public class Client {
  public static void main(String[] arg) {
    Counter c = CounterFactory.create();
    for ( int i = 0; i < 3; ++i ) {
      c.incr();
      System.out.println("value= "+c.value());
    }
  }
}

Clientをアプレット化するとこんな感じになります。[1]

C++における抽象データ型

残念ながらC++ではJavaのinterfaceのような抽象データ型を直接にはサポートしていません。が、それと同等のことなら可能です。一切のメンバ変数を持たず、そして全メンバ関数を純粋仮想関数とするのです。

class Counter {
public:
  virtual ~Counter() {}
  virtual void incr() =0;
  virtual void decr() =0;
  virtual long value() const =0;
};

そしてこのCounterから派生したCounterImpl、およびCounterFactoryを作りましょう。

class CounterFactory {
public:
  static Counter* create();
  static void     release(Counter*);
};

/* --- ここから実装部。Counterの利用者には見せない --- */

class CounterImpl : virtual public Counter {
private:
  long value_;
public:
   CounterImpl() : value_(0) {}
   virtual void incr() { ++value_; }
   virtual void decr() { --value_; }
   virtual long value() const { return value_; }
};

Counter* CounterFactory::create() {
  return new CounterImpl;
}

void CounterFactory::release(Counter* c) {
   delete c;
}

利用者(Client)は以下のようになります。

using namespace std;

int main() {
  adt::Counter* c = adt::CounterFactory::create();
  for ( int i = 0; i < 3; ++i ) {
    c->incr();
    cout << "value= " << c->value() << endl;
  }
  adt::CounterFactory::release(c);
  return 0;
}

言語を越えて…

抽象データ型はその利用者と実装者との間の申し合わせです。これを発展させると、抽象データ型を利用者と実装者双方が認識できる、すなわち実装者はそのインタフェースをサポートするオブジェクトを生成し、利用者はそのインタフェースを提供するオブジェクトを手に入れて利用することができるなら、利用者と実装者が互いに異なる言語で書かれていてもいいはずです。それを実現したのがCOM、そしてCORBAです。

COM (Component Object Model)

Visual C++ 6.0 ATLを使ってCOMサーバ(実装側)を作ってみましょう。

Visual C++の”ATL COMAppWizard”を使えばCOMサーバをとっても簡単に作れます。

CounterのインタフェースICounterを作ってできたファイルadt.idlを以下に示します。

...
  interface ICounter : IDispatch {
    [id(1), helpstring("+1する")] HRESULT incr();
    [id(2), helpstring("-1する")] HRESULT decr();
    [propget, id(3), helpstring("値を返す")] HRESULT value([out, retval] long *pVal);
  };
...
  coclass Counter {
    [default] interface ICounter;
  };
...

adt.idlの中に、incr,decr,valueをサポートするインタフェースICounterと、ICounterをインタフェースとして持つクラスCounterがあることがわかるでしょう。

以下に示すのは最終的にできあがったCounterの実装部CCounterです。

class ATL_NO_VTABLE CCounter :
  public CComObjectRootEx<CComSingleThreadModel>,
  public CComCoClass<CCounter, &CLSID_Counter>,
  public IDispatchImpl<ICounter, &IID_ICounter, &LIBID_ADTLib> {
public:
  CCounter() { value_ = 0; }

DECLARE_REGISTRY_RESOURCEID(IDR_COUNTER)
DECLARE_PROTECT_FINAL_CONSTRUCT()

BEGIN_COM_MAP(CCounter)
  COM_INTERFACE_ENTRY(ICounter)
  COM_INTERFACE_ENTRY(IDispatch)
END_COM_MAP()

public:
  STDMETHOD(get_value)(long *pVal);
  STDMETHOD(decr)();
  STDMETHOD(incr)();
private:
  long value_;
};
/* --- implementation --- */

STDMETHODIMP CCounter::incr() {
  ++value_;
  return S_OK;
}

STDMETHODIMP CCounter::decr() {
  --value_;
  return S_OK;
}

STDMETHODIMP CCounter::get_value(long *pVal) {
  *pVal = value_;
  return S_OK;
}

これをコンパイルすればadt.dllができあがり、レジストリに登録されます。これでCOMをサポートする言語ならなんであれ、利用者はCounterを使うことができるはずです。

Visual BasicからCounterを使ってみましょうか。VisualBasicのメニューから”プロジェクト|参照設定”ることで、VisualBasicがCounterのインタフェースを認識します。

フォーム上にテキストボックス(txtValue)とボタンをふたつ(btnIncr,btnDecr)配置して:

Option Explicit

Private c As Counter

Private Sub btnDecr_Click()
  c.decr
  txtValue = c.Value
End Sub

Private Sub btnIncr_Click()
  c.incr
  txtValue = c.Value
End Sub

Private Sub Form_Load()
  Set c = New Counter
End Sub

Private Sub Form_Unload(Cancel As Integer)
  Set c = Nothing
End Sub

なんとまぁ、たったこれだけで動いてしまうんです。

CORBA (Common Object Request Broker Architecture

CORBAはインタフェースを利用者と実装者が共有するという考えをもう一歩すすめ、異なるマシン/異なるOS/異なるプロセス/異なる言語による利用者/実装者を可能にしてくれます。

Orbixを使ってCounterを作ります。まずはインタフェースの定義から。

module adt {
  interface Counter {
    void incr();
    void decr();
    readonly attribute long value;
  };
};

avaのinterfaceとそっくりです。このインタフェース定義ファイルadt.idlをIDLコンパイラに食わせると、利用者/実装者それぞれのためにスタブ/スケルトンを吐いてくれます。実装者はスケルトンを基にCounterを実装し、利用者はスタブを使ってCounterにアクセスします。

/*
 * interface Counter の実装
 */
#include "Counter.hh"

namespace adt {

  class CounterImpl : public virtual CounterBOAImpl {
  private:
    CORBA::Long value_;

  public:
    CounterImpl() : value_(0) {}

    virtual void incr(CORBA::Environment &IT_env=CORBA::default_environment) ;
    virtual void decr(CORBA::Environment &IT_env=CORBA::default_environment) ;
    virtual CORBA::Long value(CORBA::Environment &IT_env=CORBA::default_environment) ;
  };

}

namespace adt {

  void CounterImpl::incr(CORBA::Environment &IT_env) {
    ++value_;
  }

  void CounterImpl::decr(CORBA::Environment &IT_env) {
    --value_;
  }

  CORBA::Long CounterImpl::value(CORBA::Environment &IT_env)  {
    return value_;
  }

}

実装者(サーバ)は(COMをレジストリに登録するように)あらかじめOrbixデーモンに登録しておきます。利用者はデーモンの仲介でCounterを手に入れ、利用します。

/*
 * クライアント
 */
#include "Counter.hh"
#include <iostream.h>

int main() {
  adt::Counter_var c;
  c = adt::Counter::_bind(":adt");
  for ( int i = 0; i < 3; ++i ) {
    c->incr();
    cout << "value= " << c->value() << endl;
  }
  return 0;
}

注釈

1. ^弊社のWebサイト公開ポリシーによりアプレットは削除しております。

Cではsizeofによって構造体がメモリ上で占める大きさ(バイト数)を知ることができます。

struct s{
  int x;
  int y;
};
...
cout << sizeof(s) << endl;

僕の愛用する処理系、Visual C++ 6.0では 8が得られました。intひとつにつき4byteを消費するからでしょう。

それではC++でのclassの大きさはどうでしょう。内包するメンバ変数それぞれの占めるバイト数の総和になるのでしょうか。

class c {
  int x;
  int y;
};
...
cout << sizeof(c) << endl;

答は…やはり 8 です。でもね、C++ではいつもこうなるとは限らないのですよ。

「C++はCよりデカい」と言われることがあります。その理由のひとつがここに明らかになります。

仮想関数

上記class cにメンバ関数を追加します。

class c {
  int x;
  int y;
public:
  int sum();
};
...
cout << sizeof(c) << endl;

結果は 8 でした。メンバ関数を追加してもサイズに変化はないようです。

ところが、仮想関数を追加すると…

class c {
  int x;
  int y;
public:
  virtual int sum();
};
...
cout << sizeof(c) << endl;

結果は12。4バイト増加しています。まるでメンバ関数へのポインタがクラス内にこっそり追加されたかのようです。
ならば仮想関数が2つあったら8バイト増えるのかな…

class c {
  int x;
  int y;
public:
  virtual int sum();
  virtual int sub();
};
...
cout << sizeof(c) << endl;

依然として 12 のままです。実体を伴わない純粋仮想関数を追加したら…

class c {
  int x;
  int y;
public:
  virtual int sum() =0;
};
...
cout << sizeof(c) << endl;

…ふむ、純粋仮想関数を追加してもクラスの大きさは 12 ですね。

これらのことから、クラスに仮想関数がひとつ以上あるとき、クラスの大きさは 4 バイト増加すると思われます。

何故でしょう。その理由は仮想関数が実行されるときのからくりにあります。

仮想関数を含むクラスを宣言すると、そのクラスの中メンバ変数'vptr'がひとつ、こっそり追加されます。これは"仮想関数へのポインタ配列'vtbl'へのポインタ"です。
vtblはクラス内にある仮想関数のポインタを配列内に納めたもので、仮想関数を含むクラス毎にひとつ作られます。仮想関数がコールされるとき、vptrの指す配列vtblの特定の位置から仮想関数へのポインタを取り出し、そこをコールします。

このようなからくりのために、仮想関数を含むクラスは、仮想関数のないクラスより少し大きいのです。

継承

継承したときのクラスの大きさはどうでしょうか。

class c0 {
  int x;
  int y;
};

class c1 : public c0 {
  int a;
  int b;
};
...
cout << sizeof(c0) << endl;
cout << sizeof(c1) << endl;

結果はそれぞれ 8,16 でした、予想通りの結果です。

仮想関数を含むとどうなるでしょう。

class c0 {
public:
  int x;
  int y;
  virtual int sum();
};

class c1 : public c0 {
public:
  int a;
  int b;
  virtual int diff();
};
...
cout << sizeof(c0) << endl;
cout << sizeof(c1) << endl;

sizeof(c0)が 12だから、c1はそれにint2個分(8byte)と'vptr'(4byte)を加えて 24 …ではなくて 20 となりました。仮想関数テーブルポインタ'vptr'はクラス内にひとつあればいいからです。

cout << offsetof(c1,x) << endl;
cout << offsetof(c1,y) << endl;
cout << offsetof(c1,a) << endl;
cout << offsetof(c1,b) << endl;

の結果はそれぞれ、4, 8, 12, 16 となりました、このことから、class c1のメモリ上でのレイアウトは、

となっていると考えられます。

多重継承

多重継承の場合、ちょっとばかしややこしくなります。

class c0 {
public:
  int x0;
  int y0;
  virtual void f0() {}
};

class c1 {
public:
  int x1;
  int y1;
  virtual void f1() {}
};

class c2 : public c0, public c1 {
public:
  int x2;
  int y2;
  virtual void f2() {}
};
...
cout << "c0  :        " << sizeof(c0)  << endl;
cout << "c1  :        " << sizeof(c1)  << endl;
cout << "c2  : c0, c1 " << sizeof(c2)  << endl;

'仮想関数ポインタテーブル(vptr)はクラスにひとつ'であるならば、sizeof(c2)は、10,c1,c2それぞれのメンバ変数領域の総和(8×3=24byte)にvptr(4byte)を加えた28byteとなりそうです。

ところが結果は予想に反して 32となりました。vptrが2つ含まれているようです。

cout << offsetof(c2, x0) << endl;
cout << offsetof(c2, y0) << endl;
cout << offsetof(c2, x1) << endl;
cout << offsetof(c2, y1) << endl;
cout << offsetof(c2, x2) << endl;
cout << offsetof(c2, y2) << endl;

の結果: 4, 8, 16, 20, 24, 28 から察するに、c2のメモリ・レイアウトは:

であろうと考えられます。

仮想継承

さらに仮想継承を考えると、話はさらにややこしくなります。

class c0 {
public:
  int x0;
  int y0;
  virtual void f0() {}
};

class c1 : virtual public c0 {
public:
  int x1;
  int y1;
  virtual void f1() {}
};

class c2 : virtual public c0 {
public:
  int x2;
  int y2;
  virtual void f2() {}
};

class c3 : public c1, public c2 {
public:
  int x3;
  int y3;
  virtual void f3() {}
};
...
cout << "c0  :        " << sizeof(c0)  << endl;
cout << "c1  : c0     " << sizeof(c1)  << endl;
cout << "c2  : c0     " << sizeof(c2)  << endl;
cout << "c3  : c1, c2 " << sizeof(c3)  << endl;

sizeof(c3)は 52 となりました。なんとも不思議な結果です。上記の各クラスから仮想関数を抜き取ってみましょう。

class c0 {
public:
  int x0;
  int y0;
};

class c1 : virtual public c0 {
public:
  int x1;
  int y1;
};

class c2 : virtual public c0 {
public:
  int x2;
  int y2;
};

class c3 : public c1, public c2 {
public:
  int x3;
  int y3;
};
...
cout << "c0  :        " << sizeof(c0)  << endl;
cout << "c1  : c0     " << sizeof(c1)  << endl;
cout << "c2  : c0     " << sizeof(c2)  << endl;
cout << "c3  : c1, c2 " << sizeof(c3)  << endl;

このとき、sizeof(c3)は 40となりました。仮想継承したベースクラスc0の各メンバは、c3内にはひとつしかないはずなので、予想されるサイズは (8×4=)32
であるはずなのに、8byte余計な領域を必要としています。仮想関数を元に戻し、

cout << offsetof(c3, x1) << endl;
cout << offsetof(c3, y1) << endl;
cout << offsetof(c3, x2) << endl;
cout << offsetof(c3, y2) << endl;
cout << offsetof(c3, x3) << endl;
cout << offsetof(c3, y3) << endl;

を実行すると、それぞれ 8, 12, 24, 28, 32, 36
となりました。この結果から得られるメモリ・レイアウトは:

'???'の領域のうち、少なくとも2つはc0::x0とc0::y0でしょう。

「C++はCよりデカい」か?

結論から言うと、仮想関数、多重継承、仮想継承などなどを駆使したC++コードは確かにデカくなることがわかりました。最後の例など、Cでなら32byteで済むところが、20byteも余計にメモリを消費します。インスタンスひとつにつき20byteのメモリを余計に消費するのですからアプリケーション全体では無視できないでしょうね。

しかし、だからといってC++コードから仮想関数を排除するのは決して得策とは思えません。仮想関数と同じふるまいを仮想関数なしで実現するには、オブジェクトの本来の型を識別するためのIDをメンバとして用意しなければなりませんし、関数呼び出しのたびに、IDによる処理の振り分けを行なうことになります。結局仮想関数を用いた場合と同等のサイズになることが予想されるうえ、コードのメンテナンス性が著しく低下するでしょう。

※注意:
これはMicrosoft Visual C++ v6.0での実験結果です。
これ以外のOSや処理系では異なる結果が得られることでしょう。

おまけ : やりがちな誤り

仮想関数のお話ついでに、うっかりやってしまいそうな誤りをひとつ紹介しておきます。あなたはいくつかのクラスを設計/実装することになり、それぞれのコンストラクタ/デストラクタが確実に行われているか、画面に表示して確かめたくなりました。そこであなたはこんなコードを書きました。

class base {
public:
  base();
  virtual ‾base();
  virtual void on_ctor();
  virtual void on_dtor();
};

base::base() {
  on_ctor();
}

base::‾base() {
  on_dtor();
}

void base::on_ctor() {
  cout << "base::ctor¥n";
}

void base::on_dtor() {
  cout << "base::dtor¥n";
}

class baseはそのコンストラクタ/デストラクタの中からそれぞれ仮想関数on_ctor()/on_dtor()を呼んでいます。ですからbaseの派生クラス側でon_ctor()/on_dtor()を再定義すればいいはずです。

class c0 : public base {
public:
  virtual void on_ctor();
  virtual void on_dtor();
};

void c0::on_ctor() {
  cout << "c0::ctor¥n";
}

void c0::on_dtor() {
  cout << "c0::dtor¥n";
}

class c1 : public base {
public:
  virtual void on_ctor();
  virtual void on_dtor();
};

void c1::on_ctor() {
  cout << "c1::ctor¥n";
}

void c1::on_dtor() {
  cout << "c1::dtor¥n";
}

int main() {
  c0 x;
  c1 y;
  return 0;
}

さて、結果はどうなったでしょう…

base::ctor
base::ctor
base::dtor
base::dtor

惨澹たる結果となりました。

そう、C++ではコンストラクタ/デストラクタの中から仮想関数を呼んでも、導出クラスで再定義された関数には飛んでこないんです。

この例のように、コンストラクタ/デストラクタから直接仮想関数を呼んでいるのであればそれに気づくのにそう時間はかからないのですが、コンストラクタ/デストラクタが呼んでいる関数の中、あるいはさらにそこから呼ばれている関数…
コンストラクタ/デストラクタが終了するまでに直接的あるいは間接的に呼ばれている一連の関数の中に仮想関数が含まれていたとき、そのふるまいは意図しているものとは異なることになるのです。

コンストラクタ/デストラクタ内から仮想関数を呼び出すことはできませんから、仕方なしにコンストラクト/デストラクトと初期化/後始末を分離しなければなりません。

// ----- これならちゃんと動く,,, -----
class base {
public:
  base() {}
  virtual ‾base() {}
  void    start();
  void    stop();
  virtual void on_ctor();
  virtual void on_dtor();
};

void base::start() {
  on_ctor();
}

void base::stop() {
  on_dtor();
}

void base::on_ctor() {
  cout << "base::ctor¥n";
}

void base::on_dtor() {
  cout << "base::dtor¥n";
}

/*
 * c0, c1 はそのまま...
 */

int main() {
  c0 x; x.start();
  c1 y; y.start();
  y.stop();
  x.stop();
  return 0;
}

これがJavaだと思った通りに動いてくれます。ま、Javaにはデストラクタがありませんけど…

// ----- Trial.java -----
class base {
  base() {
    on_ctor();
  }
  void on_ctor() {
    System.out.println("base::ctor");
  }
  protected void finalize() {
    System.out.println("base::dtor");
  }
}

class c0 extends base {
  void on_ctor() {
    System.out.println("c0::ctor");
  }
  protected void finalize() {
    System.out.println("c0::dtor");
  }
}

class c1 extends base {
  void on_ctor() {
    System.out.println("c1::ctor");
  }
  protected void finalize() {
    System.out.println("c1::dtor");
  }
}

public class Trial {
  public static void main(String[] arg) throws Exception {
    c0 x = new c0();
    c1 y = new c1();
  }
}

実行結果:

c0::ctor
c1::ctor

…ほらね。

異なる型への変換において、C/C++ではキャストが用いられます。

// intからlongへのキャスト
int ival;
int lval = (long)ival;

ご存知のとおり、キャストは非常に危険です。 本来ならば型の不一致によるコンパイルエラーをねじ伏せるのですから。

キャストの使われ方(意味)は、大きく3種(型変換/型変更/const外し)に分類されます。

1. 型変換

   // int から double へ
   int ival;
   double dval = (double)ival;

2. 型変更

   // long から int* へ
   long lval;
   int* iptr = (int*)lval;

3. const外し

   // const int* から int* へ
   const int* ciptr;
   int* iptr = (int*)ciptr;

上記のどの目的でキャストしても、構文としてはどれも同じ

(型)式

です。つまりコードからは”何が目的でキャストしたのかはっきりしない“のですね。

4種類の新しいキャスト

キャストは使わずに済ませられるならそれに越したとはないのですが、どうしても使わざるを得ないシチュエーションは少なからず存在します。
ならばせめて少しでも安全にキャストするために新たに定められたキャスト構文が、以下に挙げるstatic_cast / reinterpret_cast / const_cast / dynamic_cast です。

static_cast

static_cast<type>(expr)

static_castはexprの型からtypeへの暗黙の型変換、あるいはtypeからexprへの暗黙の型変換が存在する場合にだけキャストします。キャスト不可能であればコンパイルエラーとなります。

// int から long へ
int ival;
long lval = static_cast<long>(ival);

reinterpret_cast

reinterpret_cast<type>(expr)

reinterpret_castはtype(expr)が許されるなら、exprをtypeに単にキャストします。

// long から int* へ
long lval;
int* iptr = reinterpret_cast<int*>(lval);

reinterpret_castは単なる型変更であり、たとえ派生関係があったとしてもポインタのアドレス自体はキャスト前と変わりません。
その意味でreinterpret_castは非常に危険なキャストといえるでしょう。

const_cast

const_cast<type>(expr)

const_castはconstおよびvolatile修飾子を無効にするだけのキャストを行ないます。そのほかのときはコンパイルエラーとします。

// const int* から int* へ
const int* ciptr;
int* iptr = const_cast<int*>(ciptr);

dynamic_cast

dynamic_cast<type>(expr)

dynamic_castは基底クラスへのポインタ(or 参照)から派生クラスへのポインタ(or 参照)への型保証キャストを行ないます。

上記3種のキャストはコンパイル時にキャストしますが、dynamic_castは実行時に型の検査が行なわれ、変換不可能であれば0を返します。

class Base { ... };
class Derived : public Base { ... };

Base base;
Derived derived;

Derived* pd1 = dynamic_cast<Derived*>(&base); // 失敗 pd1 == 0
Derived* pd2 = dynamic_cast<Derived*>(&derived);

参照のキャストに失敗すると、std::bad_cast例外がthrowされます。

try {
  Derived& rd1 = dynamic_cast<Derived&>(base);
} catch ( const std::bad_cast& e ) {
  std::cout << e.what() << std::endl;
};

dynamic_castにより、従来のキャストでは不可能であった クロス・キャスト、そして抽象基底クラスからのダウン・キャストが可能になりました。

クロス・キャスト

/*
 * Shape と Drawable は派生関係にない
 */
class Shape {
 ...
};

class Drawable {
public:
  virtual void draw() =0;
};

/*
 * Circle は Drawable にキャスト可能
 */
class Circle : public Shape, public Drawable {
public:
  virtual void draw();
};

Shape* shape = new Circle;
/* 従来のキャスト (Drawable*)shape では、
 * 場合によっては暴走する */
Drawable* drawable = dynamic_cast<Drawable*>(shape);
if ( drawable )
  drawable->draw();

抽象基底クラスからのダウン・キャスト

class Machine {
  ...
};

class TV : virtual public Machine {
public:
  void tune(int channel);
};

class VTR : virtual public Machine {
public:
  void record();
};

class TeleVideo : public TV, public VTR {
  ...
};

Machine* machine = new TeleVideo;
/* 従来のキャスト (TeleVideo*)machine はコンパイルエラー */
TeleVideo* televideo = dynamic_cast<TeleVideo*>(machine);
if ( televideo ) {
  televideo->tune(8);
  televideo->record();
}

※注意

dynamic_castが適用できるのはポリモルフィック・クラス、 すなわち少なくとも一つのメンバ関数が仮想関数でなくてはなりません。

struct non_polymorpic { ... }; // 仮想関数が存在しない
struct something : non_polumorphic { ... };
non_polymorphic* p;
something* q = dynamic_cast<someting>(p); // error!

新しいキャストは従来のキャストよりはるかに安全です。
また､grepなどで”_cast”をキーにすればキャストした個所を簡単に検索できるという副次的な効果もあります。

• 9.1 生成
• 9.2 例

RWBTreeOnDisk クラスは、ディスク上のファイルで B ツリーを管理するために設計されています。このクラスは、キーと値の関連付けを順序よく並べたコレクションを表わします。その順序はキーを比較することによって内部的に決定されます。キーを指定すると、値を取り出すことができます。キーの重複は許可されません。

キーは char の配列で、キーの長さはコンストラクタによって設定されます。B ツリー内の順序は、キーを外部関数 (変更可能) と比較することによって決定されます。

値の型は次のとおりです。

typedef long RWstoredValue;

値は通常、オブジェクトが格納されているファイル内の場所へのオフセットを表わします。キーを指定すると、オブジェクトが格納されている位置を見つけ、それを取り出すことができます。ただし、RWBTreeOnDisk クラスに関するかぎり、この値は特別な意味を持ちません。これを解釈するのはプログラマ次第です。

RWBTreeOnDisk クラスは、RWFileManager クラスを使って B ツリーノードの領域の割り当ておよび解放を管理します。B ツリーとデータが同じファイル内にある場合は、同じ RWFileManager を使って、オブジェクト自体の領域を管理できます。または、別の RWFileManager を使って別のファイルを管理し、B ツリーとデータを別々のファイルに格納することも可能です。

RWBTreeOnDisk クラスのメンバ関数は、メモリにおける RWBTreeDictionary クラスのメンバ関数と似ています。違う点は、キーが RWCollectable ではなく、char の配列であることです。メンバ関数には、キーと値のペアを追加する、ペアを削除する、キーに関連付けられている値を置き換える、キーに関連付けられている情報を照会する、キーと値の全ペアで順序正しく操作する、ツリーに項目数を返す、キーがツリーに含まれているかどうかを決定する、などの関数があります。

第 15章「RWCollectable クラスの設計」で、RWCollectable を継承する Bus クラスを構築しました。すでに Bus クラスが存在すると仮定すると、以下のように多重継承を使って、Bus と RWCollectable の機能を持つ新しいクラスを作成し、手間を省くことができたはずです。

class CollectableBus : public RWCollectable, public Bus {
  .
  .
  .
};

これは、Rogue Wave の多くのコレクションクラスで取られている手段です。例えば、RWCollectableString は RWCollectable と RWCString の両方のクラスを継承します。一般的な概念は、まずオブジェクトを作成し、それを RWCollectable クラスに付け加えて、全体をコレクション可能にすることです。この方法を使うと、RWCollectable クラスを継承したくないような他の場合にもオブジェクトを使用できます。

この手段をとる別の理由は、曖昧な基底クラスを避けることにあります。次に例を示します。

class A { };

class B : public A { };

class C : public A { };

class D : public B, public C { };

void fun(A&);

main () {
  D  d;
  fun(d);                                           // どちらの A ?
}

fun() の呼び出しから曖昧さを取り除くには、2 つのやり方があります。以下のように変更するか、

fun((B)d);                         // B の、A の発生

または、A を仮想基底クラスにすることです。

最初の方法は、適切なキャストを実行するためにユーザが継承階層の詳細を把握している必要があるため、エラーが発生しやすくなります。

A を仮想関数にするという 2 番目のやり方でこの問題は解決しますが、別の問題が発生します。派生元のクラスへキャストし戻すのがほとんど不可能になります。これは、継承階層に複数のパスができてしまうからです。物理的に説明すると、コンパイラが仮想基底クラスを基底クラスへのポインタとして実装し、ポインタを逆方向にはたどれないからです。

オブジェクトの継承階層で、一致を探して可能なパスをすべて検索しつくすことができます (これは、NIH クラスのやり方です)。ただし、キャストごとに検索しなければならないため、結果のアドレスを記憶することによって速度を上げたとしても、この検索は遅くなります。また、サイズが大きく常に複雑なため、この方法は受け入れられないと判断しました。

これらの理由で最初の方法に戻りました。同じ基底クラスからすべてのクラスを派生しないようにして、継承ツリーを単純にして受け入れることができるようにしました。多くの機能を持つ大きな基底クラスではなく、機能を別々の小さな基底クラスに分けることにしました。

目的は、まずオブジェクトを構築して、それから収集性などの必要な機能を基底クラスに付け加えることにあります。つまり、同じ型の複数基底クラスを避け、その結果、曖昧な呼び出しを避けることになります。

以下のグローバル関係を用いて、クラスの参照関係あるいはポインタ関係を格納して取り出す方法は、14.5.1節で説明しました。

Rwvostream&  operator<<(RWvostream&, const RWCollectable&);
RWFile&      operator<<(RWFile&,     const RWCollectable&);
Rwvostream&  operator<<(RWvostream&, const RWCollectable*);
RWFile&      operator<<(RWFile&,     const RWCollectable*);
Rwvistream&  operator>>(RWvistream&, RWCollectable&);
RWFile&      operator>>(RWFile&,     RWCollectable&);
Rwvistream&  operator>>(RWvistream&, RWCollectable*&);
RWFile&      operator>>(RWFile&,     RWCollectable*&);

これらの関数がどのように機能するかを理解することは、RWCollectableで作業する上で大切です。まず、簡単に説明します。

初めてコレクションオブジェクトのどれかに対して左シフト演算子 << の 1 つを呼び出すとき、アイデンティティ辞書が内部的に作成されます。オブジェクトのアドレスが、その出力ファイルでの順序(例えば、1 番目、2 番目、6 番目など) と共に辞書に納められます。

いったんこれが完了すると、オブジェクトの仮想関数である saveGuts() が呼び出されます。これが仮想関数であるため、呼び出しは派生クラスによって使用される saveGuts() の定義に行きます これまで説明したように、saveGuts() の役目はオブジェクトの内部コンポーネントを格納することです。オブジェクトに RWCollectable を継承する他のオブジェクトが含まれている場合、そのオブジェクトの saveGuts() は含まれている各オブジェクトごとに operator<<() を再帰的に呼び出します。

その後の operator<<() の呼び出しでは、新しくアイデンティティ辞書は作成されず、すでに存在している辞書にオブジェクトのアドレスが格納されます。アドレスがすでに書き込まれているオブジェクトのアドレスと同一である場合は、saveGuts() は呼び出されません。その代わり、そのオブジェクトが以前のオブジェクトと同一であるという参照が書き込まれます。

コレクション全体が走査され、saveGuts() への最初の呼び出しが戻ると、アイデンティティ辞書が削除され、operator<<() への呼び出しが戻ります。

operator>>() 関数は、restoreGuts を呼び出してオブジェクトをストリームまたはファイルからメモリに復元し、この処理全体を本質的に逆に行います。既に作成されているオブジェクトへの参照に出会うと、この関数は、RWFactory に新しいオブジェクトの作成を要求するのではなく、単に旧オブジェクトのアドレスを返します。

以下は、これらの関数を使うより複雑な例です。

#include <rw/collect.h>
#include <rw/rwfile.h>
#include <assert.h>

class Tangle : public RWCollectable
{

public:

  RWDECLARE_COLLECTABLE(Tangle)

  Tangle* nextTangle;
  int     someData;

  Tangle(Tangle* t = 0, int dat = 0){nextTangle=t; someData=dat;}

  virtual void saveGuts(RWFile&) const;
  virtual void restoreGuts(RWFile&);

};

void Tangle::saveGuts(RWFile& file) const{
   RWCollectable::saveGuts(file);          // 抽象基底クラスを保存する

   file.Write(someData);                        // 内部を保存する

   file << nextTangle;                      // 次のリンクを保存する
}

void Tangle::restoreGuts(RWFile& file){
   RWCollectable::restoreGuts(file);    // 抽象基底クラスを復元する

  file.Read(someData);                       // 内部を復元する

  file >> nextTangle;                    // 次のリンクを復元する
}

// ヘッド "p" を持つヌル区切りのリストの内部統合性を調べる
void checkList(Tangle* p){
   int i=0;
   while (p)
   {
     assert(p->someData==i);
     p = p->nextTangle;
     i++;
   }
}

RWDEFINE_COLLECTABLE(Tangle, 100)

main(){
   Tangle *head = 0, *head2 = 0;

   for (int i=9; i >= 0; i--)
     head = new Tangle(head,i);

   checkList(head);                    // オリジナルのリストを調べる

   {
     RWFile file("junk.dat");
     file << head;
   }

   RWFile file2("junk.dat");
   file2 >> head2;

   checkList(head2);                   // 復元したリストを調べる
   return 0;
}

この例では、Tangle クラスが循環リンクリストを実装します。何が起こるでしょうか? 初めて operator<<() 関数が Tangle のインスタンスに呼び出されると、operator<<() 関数は前述したようにアイデンティティ辞書を設定し、Tangle の saveGuts() を呼び出します。ここで定義されているように、これは Tangle のメンバデータを格納し、次のリンクで operator<<() を呼び出します。この再帰性は、環状に継続します。

チェーンが nil オブジェクトで終わる場合 (すなわち、nextTangle がゼロ) の場合、operator<<() はこれを内部的に記録し、再帰を停止します。

その一方で、リストが環状である場合は、operator<<() が Tangle の最初にインスタンス (このチェーンすべてを開始したインスタンス)で再び呼び出されます。これが発生すると、operator<<() はこれはすでに処理したことがあるインスタンスであることを認識し、再び saveGuts() を呼び出すのではなく、前に書き込んだリンクへの参照を作成します。これにより、一連の再帰的な呼び出しが停止し、スタックが解放されます。

チェーンは、同様な方法で復元されます。次の呼び出しにより、

RWFile& operator>>(RWFile&, RWCollectable*&);

新しいオブジェクトがヒープ領域に作成され、そのオブジェクトへのポインタ、前に読み込んだオブジェクトのアドレス、あるいはヌルポインタが返されます。最後の 2 つの場合は、再帰が停止し、スタックが解放されます。

この章では、ストリームのバイトの最終的な出力先がメモリかディスクかを考えることなく、オブジェクトをどのようにストリームに格納し、読み出すかについて述べました。また、ストリームの最終形式が ASCII かバイナリかを考慮する必要もありません。

また、RWpostream および Rwpistream のように、独自の特殊仮想ストリームクラスを書くこともできます。仮想ストリームの大きな利点は、独自の特殊仮想ストリームを書く場合に、クライアントクラスのコードをまったく変更する必要がないことです。つまり、単にストリームクラスを引数として使用するだけです。

RWvostream& operator<<(RWvostream&, const ClassName&);
RWvistream& operator>>(RWvistream&,       ClassName&);

オブジェクトを仮想ストリームに格納し読み出すほかに、すべてのクラス自体をバイナリで RWFile に格納し読み出すことができます。このファイルは、ANSI-C スタイルのファイル I/O をカプセル化します。ストリーム I/O に比べその機能に、より多くの制限がありますが、仮想関数のディスパッチを必要としないため、この形式でディスクへ格納し読み出す方がやや速くなります。

次の例はさらに複雑なもので、Windows DDE 機能を介して、RWDDEstreambuf クラスを使い、RWBinaryTree を交換する方法を示します。Windows クリップボードの場合にも、同様なテクニックを使用することができます。

#include <rw/bintree.h>
#include <rw/collstr.h>
#include <rw/bstream.h>
#include <rw/winstrea.h>
#include <windows.h>
#include <dde.h>

BOOL
PostCollection(HWND hwndServer, WORD cFormat){
   RWBinaryTree sc;                                          // 1
   sc.insert(new RWCollectableString("Mary"));
   sc.insert(new RWCollectableString("Bill"));
   sc.insert(new RWCollectableString("Pierre"));

   // RWDDEstreambuf を割り当て、それを使って初期化する
   // RWbostream:
   RWDDEstreambuf* sbuf = new RWDDEstreambuf(cFormat,        // 2
                                             FALSE,          // 3
                                             TRUE,           // 4
                                             TRUE);          // 5
   RWbostream bostr( sbuf );                                 // 6

   // コレクションを Rwbostream に格納する:
   bostr << sc;                                              // 7

   // 出力ストリームをロックし、そのハンドルを取得する:
   HANDLE hDDEData = sbuf->str();                            // 8

   // DDE メッセージを同定するアトムを取得する:
   ATOM atom = GlobalAddAtom("SortedNames");                 // 9

   // DDE の応答をポストする:
   return PostMessage(0xFFFF, WM_DDE_DATA, hwndServer,       //10
                      MAKELONG(hDDEData, atom));
}

のコードでは、大きなメモリモデルが前提とされています。次に、コードの説明を行ごとに示します。

//1

RWBinaryTree が構築され、それに項目が挿入されます。

//2-//5

RWDDEstreambuf が割り当てられます。コンストラクタはいくつかの引数をとります。最初の引数は Windows クリップボードの形式です。この例では、形式の種類が引数として渡されていますが、一般には Windows に形式を登録し (RegisterClipboardFormat() を使う)、それを使用します。
その他の引数は、DDE データ交換およびメモリ管理に関連しています。引数の一覧に関しては『Tools.h++ Class Reference』を参照してください。それらの意味については、『Programming Windows 3.0』、または 『Microsoft Windows Guide to Programming』を参照してください。

//6

RWbostream が与えられた RWDDEstreambuf から生成されます。ここで RWpostream を使うこともできますが、DDE 交換は同じマシンアーキテクチャ内で行われるので、余分な手間のかかる移植可能な ASCII 形式を使っても意味がありません。また、streambuf の型によって設定されるバイトの状態が、どのように Rwvostream の型によって設定される形式から切り離されるかに注意してください。

//7

コレクションは Rwbostream に保存されます。RWbostreamと関連付けられている streambuf は実際には RWDDEstreambuf であるため、コレクションは GMEM_DDESHARE 属性を持つ Windows のグローバルメモリ割り当て領域に保存されます。この割り当て領域は、オーバーフローすると自動的にサイズ変更されます。その他の strstreambuf と同様、メンバ関数 setbuf() を使って割り当て領域の大きさを変更できます。

//8

RWDDEstreambuf がロックされます。いったん str() を使ってロックしたら、他の strstreambuf と同様、この streambuf を再び使用することはできません。ただし、RWDDEstreambuf::str() は char* ではなく、ハンドルを返すことに注意してください。このハンドルは、返す前にロック解除されます。

//9

この DDE データを同定するためにアトムを生成します。

//10

RWDDEstreambuf::str() によって返されたハンドルが、アトムを同定するとともにポストされます。

クリップボードを介したデータのやり取りには、より簡単な同様の方法を使用できます。

特殊化された streambuf の RWCLIPstreambuf と RWDDEstreambuf は、Rogue Wave 仮想ストリーム機能と共に使わなければならないものではありません。それらは通常の istream および ostream と共に、きわめて簡単に使用することができます。ただし、実行時に形式を設定することができません。