2005-06-27-02-まだまだ OreCa for C++ について - project-enigma

2005-06-27-02-まだまだ OreCa for C++ について

>> Site top >> weblog >> 月別アーカイブ >> 2005年06月のlog >> 2005-06-27-02-まだまだ OreCa for C++ について

最終更新日付:2014/01/02 00:00:00


まだまだ OreCa for C++ について

2005 年 06 月 27 日

今日の昼間に到達した連想配列の考え方は、やはりベストプラクティスになりそうだ。ちなみに、クラス名が長くなりすぎるので名前空間 NSBasicUtil というのを導入することにした。スコープ解決演算子の使用が面倒なら using namespace ね。一発代入形式なら以下のように書ける。

    using namespace NSBasicUtil;
 
    Database db( "testDB" );
 
    db["name"] = "kagelow";
    db["age"] = 30;

最後の 2 行で何が起きているか。Database::operator[]( const char* ) は Record クラスのオブジェクトを生成して返す。返された一時オブジェクトに対して operator=( )が呼ばれるというわけだ。つまり、以下のようにも書ける。

    using namespace NSBasicUtil;
 
    Database db( "testDB" );
 
    Record rc = db["name"];
    rc = "kagelow";
 
    rc = db["age"];
    rc = 30;

つまり、Record クラスはコピーコンストラクタと代入演算子をサポートする...と、まてよ、代入演算子はレコード内のデータの保存にも使用されるから、なんだか上記のコードはわかりにくいかもしれないな...それに Database::operator[]( const char* ) が呼ばれた時点で該当するキーを持つレコードが存在しなかった場合、あらたにレコードを作成してから返すことになるが、その時点でレコードのサイズはどうやって決定するのか? 最低限としてキー文字列長か?

どうするべきかを考える前に、なぜこうなっているかをもう一度考えよう。例えば STLの map クラスであれば、 operator[] 演算子のオーバーロードが直接値の参照を返す。しかし、それは map がクラステンプレートであり、格納するデータの型が決定されているからだ。その一方で、今考えているクラスはレコードごとに格納するデータの大きさが異なっていてもよい。そのために Record クラスを導入し、Record オブジェクトを左辺とする代入演算子をオーバーロードできるようにすることで未知のデータ型の入出力をサポートできるようにしたのだ。そう考えると、どうやらこれで行くしかないような気がする。

ひとまず実装してみるか...

 

コメント

このページにコメントする

 

このページのタグ

Page tag : Palm

 

 


Copyright(C) 2005-2017 project-enigma.
Generated by CL-PREFAB.