sqlite3 C++ラッパーライブラリ「SQLiteCpp」の使い方

りやさんです。
今日はsqlite c++ラッパーライブラリ「SQLiteCpp」を紹介しようと思います。

ゲームではマスターデータ、ユーザーデータ管理のために、ソースコード埋め込みではなくリソースファイルとしてデータを管理することが多いと思います。
形式が何であれ、XML、JSON、バイナリ、SQL…いろいろ選択肢はあります。

今回はSQLについて取り扱っていこうと思います。

SQLは膨大なデータを扱うのに優れていて、スレッドセーフであり、データの検索がとてもしやすい形式です。

C++カジュアルゲームでSQLを使う場合、ライブラリ単体で動作するSQLiteがオススメです。

ただ、公式のC言語向けSQLiteライブラリは、C言語ゆえの手続きじみた面倒な処理を書かなくてはなりません。

openしてclose。ポインタのポインタを渡したり、どこか懐かしい構文です。

prepareでクエリの最適化やバインディングを行う際は

うーん面倒くさい。
プログラマは怠惰で忘れっぽい生き物なので、こういうコードを書いてるといつか破綻しそうです。
オブジェクト指向っぽく書きたい。

そんな人のために、SQLiteには多くのC++ラッパーライブラリが存在します。

その中の一つ、「SQLiteCpp」を紹介します。

SQLiteCpp

非常にシンプルに作られており、とても使い易いライブラリです。

cmakeでビルドする方法が記載されていますが、xcodeではもっと簡単にプロジェクトに組み込めます。

SQLiteCppフォルダをプロジェクトに配置し
SQLiteCpp/include をHeader Serch Pathsに追加して
SQLiteCpp/src/*.cpp、SQLiteCpp/sqlite3.cファイルすべてをCompile Sourcesに追加するだけです。

SQLiteCppの使い方

インスタンスの作り方

コンストラクタやクエリは例外を投げるのでtry-catchした方がいいです。
コンストラクタは第4引数まで持ちます。

第一引数:ファイル名
第二引数:オープンタイプ

OPEN_READONLY : 読み込み専用
OPEN_READWRITE : 読み書き
OPEN_CREATE : なかったら作る
OPEN_URI : URIも許可する

複数のタイプを組み合わせることができます。(例:SQLite::OPEN_READWRITE | SQLite::OPEN_CREATE)
デフォルト値: OPEN_READONLY

第三引数:データベースがロックされている時のタイムアウト時間[ms]
デフォルト値:0

第四引数: VFSの設定
独自のファイルシステムを指定する際に使う。
デフォルト値:空文字列

成功したかどうかさえわかれば良いタイプのクエリを送る(例: CREATE TABLE)

返り値:SQL文で変更された行の数

返り値でSQLITE_OKはかえってきません。
内部でSQLITE_OKかどうかをチェックし、例外を投げる機構が作られてるので、OKチェックをしたい場合はtry-catchしてください。

トランザクションの作成

明示的にトランザクションを使う場合はTransactionクラスを使います。

もしcommitせずにtransactionインスタンスが破棄された場合、デストラクタでロールバックが行われます。

データを取ってくるクエリ

Statementクラスを使います。

エラーをとりたい場合は同様にtry-catchします。

バインドはプレースホルダ「?」を使って行います。
プレースホルダインデックスは1から始まります。注意してください(本家sqlite3は0から)

getColumn関数は対応するインデックスのデータを取得しますが、返り値がColumnというデータラッパクラスです。
プリミティブ型になら何でもキャスト出来る型なので、インデックス等をよく確認するか、isIntegerメソッド等を利用するとデバッグに便利かもしれません。
非explicitキャスト演算子がオーバーロードされているため、以下の3文は等価です。

1行目が暗黙キャスト、2行目がC++風キャスト、3行目がC風キャスト。
すべて内部でgetIntメソッドを呼びます。
他の型も同様です。

また、bindは内部でprepareしてくれます。
内部で扱われてるsqlite_stmtラッパクラスのコンストラクタとデストラクタが、prepare-rest-finalizeをやってくれてるからです。

こんなところでしょうか。

他にもexecAndGetとかisOkとかありますが、結局組み合わせだったり単なる問い合わせやGetterなので解説の必要はないでしょう。

このように、使いづらいC言語ライブラリでも、C++でラップすることによってたちまち使いやすくなります。
オブジェクト指向言語は偉大ですね。

今回はこの辺で。

階層型ステートマシンによるステートデザインパターン

新卒のりやさんです。

こいつブログばっか書いてんな、もしかして暇なのか? とか思わないでください。

今回は、ゲームプログラミングの中でもとても重要なデザインパターン、ステートデザインパターンについて紹介しようかと思います。

通常、クラスというものは「属性」と「振る舞い」の二種類の要素を兼ね備えています。
一般に、データとインターフェースと呼ばれるものですね。

クラスは自身の状態を保持し、きっとカプセル化されたデータに応じて要求された操作に対し適切な振る舞いをすることでしょう。
そのようなコードは列挙体とswitch-caseで簡単に表現できます。

例として、村によくいる住人のオブジェクトを考えます。
住人は、走ったり、歩いたり、或いは居眠りをする挙動を考えます。

この程度のコードならまあ、これでいいんでしょうが、あまりにも拡張性に欠けます。
状態(State)は今3つだけですが、当然追加が発生することもありますし、遷移の順番も変わるかもしれません。

さらに、状態というものはネストすることがあります。例えば、「機嫌が良い/悪い」という状態が加わったらどうでしょう。「歩いている」と「機嫌が良い」は同時に発生しうる状態であり、両方とも別変数で管理し、switch-caseをネストさせて条件分岐させなくてはなりません。

そんなswitch-caseのコードのメンテナンスをしていると、とんでもないことになります(なりました)。

具体的にどうするべきかというと、「状態」というものをクラスにしカプセル化しましょう。
NPCクラス自身が次の状態は何か、今どうするべきかを判断する構造は良くないです。

NPCクラスが呼び出すのはStateのupdateだけ。
あとは勝手に状態遷移をやってくれそうな感じです。

ステートデザインパターンとしてはまだまだ実装すべき項目がありますが、コンセプトとしてはこの方針で問題なさそうです。

私が作成するステートマシンの基本要件は以下。

 

ステートマシンクラス

      1. ステートマシンは必ず「現在のステート」を持つ

2. ステートマシンは階層構造になっており、ステートマシンには親ステートマシンや子ステートマシンが存在する場合がある

3. ステートマシンは特定の間隔(ゲームであるならば、毎フレームが望ましい)でステートに次の遷移先ステートを問い合わせ、状態が更新される

4. 遷移先ステートが同一である場合、遷移は行わないと定義する(本来ステートマシンの元となる有限オートマトンにおいては、この操作は「自己遷移」と呼ばれるものだが、省略する)

5. ステートの遷移が行われた場合、遷移前のステートのイグジット処理と、遷移後のステートのエントリー処理を実行する

6. ステートマシンはイベントの通知を受けた時、現在のステートに処理すべきかどうか問い合わせる。この操作は、イベント処理するステートが見つかるまで子ステートマシンより再帰的に行われる

ステートクラス

      1. ステートは「次のステート」を持つ

2. ステートは「イベント」と「アクション/トランジション」のマップを持つ。ステートマシンより問い合わせが来た時、該当するイベントアクションが存在する場合、実行する

3. アクションは関数の実行、トランジションは遷移の発生である。ただし、拡張性のため、トランジションにはファクトリデザインパターンを採用する

 

そんなこんなで、実装したステートマシンが以下.
(業務のために本格的に作成したものですので、少し大規模になっています)

ステートマシンはupdate関数によってステートの状態を毎回チェックしています。
返ってきたステートが同一ではない場合、ステートの遷移を行います。
その際、ステートのentry関数とexit関数を実行します。

また、dispatchEvent関数によってイベントの処理を行います。
子ステートマシンに先に問い合わせた後、イベントが処理されるまで再帰的に実行されます。

また、メモリの安全性の考慮し、スマートポインタを使用します。

ステートクラスはアクションマップとトランジションマップを持ち、該当するイベントをprocessEvent関数によって実行します。
_nextメンバは次の遷移先ステートを表しており、update関数によって次のステートの問い合わせを受けた場合、_nextが存在するなら_nextを、存在しないならば自身を返します。

こんな感じで、実際にNPCが歩くだけのプログラムを作ってみました。
リポジトリを置いとくので、ステートマシンの使い方の参考がてらどうぞ!
cocos2dx v3.11が必要です。

https://github.com/Riyaaaaa/StateMachineSample

実行結果

ZjItNIl46X

こいつ…動くぞ!

素材提供者 直江ジャスティス様
(https://twitter.com/justicenaoe)

【Android】CrystaX NDKでgcc5を使いC++14のコードをコンパイルする【Cocos2dx】

どうも、ぺーぺーの新人のりやさんです

ちょこっとCosos2dxのゲームのAIを作る上でコンパイル時計算を使っていたら

コンパイラにconstexpr関数でnot return statementを使っていると怒られてしまいました。

Android NDKのgccにおいてc++14の機能は使えるものと使えないものがあることがわかり、gccのバージョンを調べてみると

なんと4.9! 最新のAndroid NDKでもこれは変わらず!

Relaxing requirements on constexpr functions:(constexpr関数の制限緩和)

に対応しているのはgcc5からなんですよね…

この機能によってconstexpr関数は

  • globally-visible side-effects, such as modification of an object of static storage duration (other than the object being constructed, if any);

  • expressions which cannot be evaluated during translation, such as dynamic memory allocation, comparisons with unspecified results and lvalue-to-rvalue conversions on objects which are neither constant nor created during the evaluation;

  • non-portable constructs, such as an attempt to violate type-safety or to inspect the underlying storage of the abstract machine (for instance, through a reinterpret_cast), or use of inline asm;

  • invocation of a function which is not constexpr; or

  • undefined behavior.

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3597.htmlより引用>

(グローバル、スタティックオブジェクトへのアクセス/動的割り当て/型安全性に違反する行為(reinterpret_cast等)、インラインアセンブラの利用/非constexpr関数の呼び出し/未定義動作)
以上に該当しない場合はコンパイル時に評価されます。

つまり副作用がなければ何でもあり。

逆にC++11仕様の場合、関数内にはreturn statement以外かけません。forやwhileは使えないので再帰を駆使、コンテナは独自のイテレータを使う、参照を取れないので複数の値はタプルで返す等、地獄の実装になります。

絶対Cocos2dxでC++14コードをAndroid向けビルドしたい! そんな時は

Android NDKを消しとばしてCrystaX NDKを使いましょう! CrystaX NDK ならgcc5.3に対応しています! しかもgcc6への対応も意欲的!

ただし、推奨環境ではないので色々弄る必要があります。

 

MacOSX 環境でのCocos2dx向けCrystaX構築方法

1. まずbrewを用いてCrystaXをインストールします。

ターミナルを開きます。brewは適宜インストールしてください。

2. ~/.bash_profileを弄ります。

このプロファイルには、皆さんがcocos2dxのsetup.pyを実行した時に入力したNDK_ROOTなるものがexportされているはずです。

AndroidNDKからCrystaXに変えましょう。

 

この辺は環境依存なので自分のbrewのパッケージ保管場所を入力してください。

 

3. android-studioの設定をいじります。(既存のプロジェクトがある場合)

現在のcocos2dxプロジェクトを開いて、タブのFile->Project Structure->SDK Locatinに飛び、Android NDK locationに先ほどと同じパスを入力します。

 

4. コンパイラのバージョンを指定します。
cocos2dxはAndroidNDKを想定しているので、toolchainを4.9に指定しています。

cocos2d-x-3.11.1/tools/cocos2d-console/plugins/plugin_compile/build_android.py

を開き、206行目あたりにある

を4.9から5に書き換えます。

環境によってはまずい感じの変更ですが、慈悲はなし。C++14道は険しいのだ。

 

5. cocos2dxのフレームワークでなぜかビルドエラーが出るので修正します。

YOUR_PROJECT_ROOT/cocos/uiUIWebViewImpl-android.h/cppにおいて

uint32_tがビルドで死ぬので、全部intに書き変えましょう。これもまずそうな変更ですが、おそらく今時32bit環境のAndroidなんてないと思います! きっとintは4byteですよ…

 

さて、ここまでやれば

cocos run -p android –android-studio

で実行です!ビルドが通れば勝ち!

もしerrorが出てきても大丈夫。環境が変わりシンボルリンクがかなり厳しくなります。今errorを吐いているSTLは本当に必要なヘッダをincludeしていますか? functional, type_traits, utility等、使ったSTLの所属するヘッダはしっかりincludeしましょう。

 

return statement以外を持つconstexpr関数を書いてみたり、変数テンプレートを使ってみたり(gcc 5から対応した機能)して、gccのメジャーバージョンが5になってるか確認してみてくださいね。

(ちなみにCrystaX NDKにおけるconstexpr関数の挙動がおかしい感じ…誰か調査してください)

今回はこの辺で!