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-2021 project-enigma.
Generated by CL-PREFAB.