xkikeg / ares Goto Github PK

#1 が完了したらそれに合わせてaresの実装自体を変更する。

Now SQLiteStmt class provides step() which is simple wrapper of raw sqlite3_step().
This interface is quite C-like dirty one. Code shown below is better.

for(SQLiteStmt::iterator itr=stmt.begin(); itr != stmt.end(); ++itr)
{
  std::cout << static_cast<int>(*itr) << std::endl;
}

-Iterator is Input Iterator.
-NULL checking is needed.

文字通り。

const char hoge[] = "AA";

は

const char * hoge = "AA";

より効率がいいらしい。

aresで用いる程度のコントロールがGTKとWindows双方でうまく動作することを確認してから用いたい。
現時点ではwxWidgetsが有力候補なので、サンプルプログラムをLinux, Windowsでビルドしてみよう。

Linux

Ubuntu 11.10 oneiricでデフォルトのサンプルは無事動作した。日本語も入力できるようだ。

Windows

未確認。VC++2010で確認すべき。

#4 の一種だが社線に対応するべき

特定の区間利用時の加算運賃や特定運賃を処理する。

• 特定区間に対して加算運賃
• 特定区間に対して特定運賃

三島会社と本州の乗り継ぎに対応する。
本四備讃線では加算運賃が発生するので #4 も解決する必要があるが、このIssue自体では取り扱わない。

API

APIで受け渡しに使う際の文字コードを何にするかは重大な問題。

• UTF-8をchar / std::stringで。
• ワイド文字列をwchar_t / std::wstringで。

  実行環境への依存

• SQLiteはUTF-8かUTF-16を選ばないといけない。
• LinuxはよくあるロケールではUTF-8だがもちろんEUC-JPの人もいる。ワイド文字列はUTF-32らしい。
• WindowsはデフォルトはShift_JISで、ワイド文字列がUTF-16である。
  一言で言うと普通の文字列もワイド文字列もSQLiteに渡すには本来使えないし使うべきではない。

  実装の都合

  文字の長さを取得するためにワイド文字列に変換をする所が１箇所あるが、ここも方策はいくつかある。
• libiconvやcodecvtなどを使って適切にUTF-8をUCS-4などの文字数一定の文字列に変換する。
• 直接文字数を計る。簡単に調べられる可能性がある。
  また、C++11(C++0x)からはu8""リテラルがあるので、UTF-8は扱いやすい気がする。
  ただ、UTF-16もリテラルがあり扱い易いことと、UTF-16のほうが却ってサイズが小さくなるかもしれないこと（日本語が多いから）を考えるとUTF-16を使うのもいいかもしれない。

なぜ実際の営業キロではなく両端駅の営業キロを返すべきかというと、運賃計算キロはそれぞれ駅の営業キロに1.1倍して四捨五入して決定されているからだ。つまり区間のキロに1.1倍するのはお門違いという訳である。
これをreal, fake（営業キロと擬制キロ）を両方もたせ、CKiloでも両方持たせることにした。しかし、CKiloの内部実装でどう持とうが勝手だが、CKiloのインターフェースとしてrealとfakeを両方入力させるのは冗長である。

#4 と違って特定の経路、つまり複数の区間に亙る運賃の特例がある場合に対応する。

顕著な例では特定運賃である。

ほとんど本州の会社と一緒。

キーボードで下を連打すると重い。
駅名表示を「キーだけ入れて動的に表示」に切り替えすべき

運賃の基本は大人片道。これに小人・学割というオプションがつきうる。
さらに、往復割引や周遊きっぷアプローチ券という割引も生じうる。
ただし、これらは大人片道運賃にのみ依存するので、

class CFare {
   int fare;
};

にいろんなメンバ関数を実装していく?

とりあえずルートをたどっていけば運賃が計算できる機能を付ける。

CDatabaseクラスのアーキテクチャの修正が必須かもしれない。
毎回std::vector<>を作って返すのはパフォーマンス面で明らかに無視できない。
const std::vector<>&を返すように修正して、内部ではデータの変更がないことは明らかなわけでキャッシュしてしまえばいいと思う（キャッシュのあるなしはifdefなりなんなりでスイッチしたほうがいいかもしれない）

地方交通線に対応する。
-幹線と乗り継ぎなら擬制キロ
-地方交通線で閉じるなら別テーブル

特定区間に収まる場合、運賃を特定のテーブルで計算する。

Windowsに限ればUTF-16で処理したほうが楽かもしれない。
あと、もしLinuxでもC++0x絡みでUTF-16が普及するなら楽だな。

CREATE VIEW station_kilo
   AS SELECT * FROM (SELECT station.*,count(*) AS jointcount
                          FROM station NATURAL JOIN kilo GROUP BY kilo.stationid)
                      NATURAL JOIN kilo;

というViewを現在与えているが、さらにNATURAL JOIN lineしてしまったほうが多分使い勝手はいい（それほど良くなるか？というのは置いておいて。）
しかし、自分のThinkPad X40で実行した時には付け加えた時の実行時間の遅さは半端無かった。今自分の手元のマシンで試してみると一瞬で出てきたのだが、これは再考の余地があるかもしれない（例えばたまたま重いプログラムが裏で走ってたとか）。
実際に後で実機で試して見るべき。

四国と九州は擬制キロの問題で計算手法が大きく異なる。

#1 に関連した内容だが、SQLiteStmtで構成する prepared statement と、実際の実行結果は異なるべきかもしれない。

typedef SQLiteResult * iterator; //! 嘘だけどそういう感じ。
SQLite db(":memory:");
db.execute("CREATE TABLE ...");
SQLiteStmt stmt("SELECT * FROM ...");
stmt.bind(1, ...);
for(iterator res = stmt.execute(); res; ++res)
{
   std::cout << (*res)[0] << (*res)["id"] << std::endl;
}

つまりイテレータじゃないんじゃね、というわけ。
イテレータという以上は「ポインタのような何か指し示すもの」を*演算子でデリファレンスすることで値が取れないといけない。
しかし、カラムの集合[5, 8, "foo", "bar", -5]みたいなものが取れるべき値なわけで…

cppunitよりgoogletestの方がいいかもしれない。

まずcppunitはテストメソッドの自動追加とかもしてくれない。一方googletestは自動で追加してくれる。（そういうマクロなんだろうけど）
他の機能はよくわかってない。

特定都区市内制度に対応する。

概要

• 出発駅から着駅に対応する中心駅、もしくは出発駅に対応する中心駅から着駅までが一定キロを超えると適用される。
• 一旦特定都区市内を出てもう一度その特定都区市内を通過する時は適用されない。
  • でも東京都区内-東京都区内の切符は正解らしい。

問題点

だいたいの特定都区市内はある駅から中心駅までの経路は一意に特定できるけど、東京都区内ではそうは行かない。

文字通り。boostを使った代替実装を作っておかないと互換性的にまずい気がする。
もちろん自分はコマンドラインを使って、他人に公開するのはwebでもいいんだけど。

ただし、UTF-8リテラルが無いのでUTF-8を使うのが厳しい。

• 新幹線と在来線の同一視
• 経路特定
• その他