2005-06-27-02-まだまだ OreCa for C++ について
>> Site top >> weblog >> 月別アーカイブ >> 2005年06月のlog >> 2005-06-27-02-まだまだ OreCa for C++ について
最終更新日付：2005/06/27 02: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-2020 project-enigma.
Generated by CL-PREFAB.
