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

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

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

簡単な例として"カウンタ"を考えてみましょう。カウンタには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 と共に、きわめて簡単に使用することができます。ただし、実行時に形式を設定することができません。

streambuf クラスは、iostream 機能の基礎となるシーケンス層です。これは、文字の順序の生成と利用を行います。コンパイラに付属のものには、いくつかの種類の streambuf があります。例えば、filebuf クラスは最終的に文字をファイルに入力および出力します。strstreambuf クラスは、メモリベースの文字ストリームで入力および出力をします。つまり、ANSI-C の sprintf() 関数と同等の iostream と考えることができます。今回、Tools.h++ には次の Windows ベースの拡張機能が付け加えられました。

• Windows クリップボードでの入力および出力を行うための RWCLIPstreambuf クラス
• Windows の DDE (動的データ交換) 機能を経由して入力および出力を行うためのRWDDEstreambuf クラス

これらのクラスは、バッファがオーバーフローまたはアンダーフローすると、Windows からのメモリの割り当てと解放を行います。RWDDEstreambuf クラスの場合は、関連する DDEDATA ヘッダも自動的に書き込まれます。Rogue Wave の仮想ストリームクラスと同様に、istream と ostream を含め、ios クラスを継承したすべてのクラスはこれらの streambuf と共に使用できます。

例えば、複雑な構造を一般のディスクベースのファイルに格納するためのコードは、DDE 機能でその構造を別のアプリケーションに転送するためにも使用できるということです。

#include <rw/bstream.h>
#include <rw/cstring.h>
#include <fstream.h>

#ifdef __BORLANDC__
# define MODE ios::binary                                    // 1
#else
# define MODE 0
#endif

void save(const RWCString& a, RWvostream& v){
  v << a;                    // 仮想出力ストリームに保存する
}

RWCString recover(RWvistream& v) {
   RWCString dupe;
   v >> dupe;            // 仮想入力ストリームから復元する
   return dupe;
}

main(){
   RWCString a("A string with\ttabs and a\nnewline.");

   {
     ofstream f("junk.dat", ios::out|MODE);                  // 2
     RWbostream bostr(f);                                    // 3
     save(a, bostr);
   }                                                         // 4

   ifstream f("junk.dat", ios::in|MODE);                     // 5
   RWbistream bistr(f);                                      // 6
   RWCString b = recover(bistr);                             // 7

   cout << a << endl;  // 2 つの文字列を比較する            // 8
   cout << b << endl;
   return 0;
}

出力:

A string with   tabs and a newline. A string with   tabs and a newline.

関数 save(const RWCString& a, RWvostream& v) の役目は、文字列 a を仮想出力ストリーム v に保存することです。関数 recover(RWvistream&) はその結果を読み出します。これらの関数は、文字列の格納に使用される最終形式には関知しません。次に各行に対する注釈を示します。

//1-//2

この 2 行では、ファイル junk.dat に対してファイル出力ストリーム f が作成されます。多くの PC コンパイラのファイルオープン時のデフォルトモードは text であるため、DOS の自動改行変換を避けるために明示的にフラッグ ios::binary を使用しなければなりません。[1]

//3

この行で、f から RWbostream が作成されます。

//4

この文は { … } で囲まれているので、f のデストラクタがここで呼び出されます。これにより、ファイルを閉じます。

//5

ファイルを再び入力のために開きます。

//6

f から RWbistream が作成されます。

//7

文字列がファイルから読み出されます。

//8

最後に、オリジナルの文字列と読み出された文字列を比較のために出力します。

このプログラムは、fstream クラスを使って簡略化することができます。fstream クラスは、出力と入力のために ofstream と ifstream を多重継承します。結果を読み込む前に、ファイルの先頭を見つける必要があります。seekg() の早期実装は、信頼性が証明されていないので、上記例ではこの手段がとられていません。

注釈

1. ^ 多くの PC コンパイラでは、 ios::binary フラッグ付きでファイルが開かれていないかぎり、ostream::write() および istream::read() はテキスト変換を実行します。