Chapter 14. Boost.PropertyTree

パスをルートから渡すことで途中の構造を柔軟に解析できるというのがポイントかと思いました。これで数値や文字列など基本的な型であれば値を取得することができ、リストの場合はループで巡回することもできると。なんとも便利じゃないですか。

次のゲーム制作には使うところがありませんが、覚えておいて損はなさそうです。

ただ、 Windows の場合はユーザのホームディレクトリ以下に、まさしくこういった用途の Local ディレクトリがありますので、本来はここに入れてもいいファイルなのです。しかしながら、 C:\local に配置したのは「ユーザの垣根を越えて共有したい」という意図があります。

こうなると C:\local という名前に違和感を感じるようになります。「共有してるよ（できるよ）」というのを主張したいです。ここで、 Linux に目を向けてみました。

Linux 系 OS では /usr/bin 以下のバイナリなどをほとんどのユーザが使えるようになっている状態を目にします（たぶんこれが基本かと）。これにあやかって C:\local を C:\user-local と改めてはいかがだろうか？…と考えました。パッケージシステムが /usr/local を浸食しないという特性も、インストーラーで入れたソフトが C:\user-local には入らないという使い方にマッチしているような気がします。

今週届くであろう ThinkPad でこれを適用してみたいと思います。

#include <iostream>

#include <boost/smart_ptr/shared_ptr.hpp>


class aClass
{
public:
  aClass()
  {
    std::cout <<"Created !" <<std::endl;
  };
  ~aClass()
  {
    std::cout <<"Deleted !" <<std::endl;
  };
};

int main(int argc, char* argv[])
{
  aClass *rawPtr = new aClass();

  boost::shared_ptr<aClass> ptr1(rawPtr);
  boost::shared_ptr<aClass> ptr2(rawPtr);

  return 0;
}

書籍によるとこれは失敗例らしく、自分もそう思います。最後に同じ領域が２回 delete されそうな気がします。ただ、手持ちの環境では不正終了などもなく、デストラクタが２回実行されて終わりました。 Windows って不要なメモリを回収するのが早いような印象があったのですが、メモリの残滓だけでもデストラクタが動くのでしょうか。

関数とか、スコープを違えると不正終了するかも…

普段 C/C++ に触れていないと、その存在意義もわかりにくいでしょうし、ほとんど理解してもらうのをあきらめていたところがあるのですが、よく考えたらハードリンクを例にとると簡単に伝わったのかもしれません。

なんでそのとき気づかなかったのかと後悔しそうになります（残念ながら、もう、会う機会もない方々だと思いますし）。たぶん、本気でゲーム作る用事がなかったので問題ないと思いますが、珍しく良い例えがある分野だっただけにひらめきの悪さが悔やまれます。

ちょっと昔のことを思い出してみた日曜日の夜更け。お仕事、今日も終わりませんでした。明日からもがんばります。

More C++ Idioms

ゲーム作ってると、「これ書くのにこの実装で良いだろうか？」という不安に直面するのですが、うまい具合にはまるイディオムが見つかったらしめたものです。一度探してみると良いと思います。

Boost の中にこういったイディオムの実装もあるようで、理解を深める意味でも参考になりそうです。

ソースコードやバイナリを配置した場所は次のようになります。

コマンドは次のようになります。

cd C:\local\Boost\boost_1_39_0

C:\local\Boost\boost-jam-3.1.17-1-ntx86\bjam.exe ^
  -sBZIP2_SOURCE=C:\local\bzip2\bzip2-1.0.5 ^
  -sZLIB_SOURCE=C:\local\zlib\zlib123 ^
  --stagedir=C:\local\Boost\boost-build ^
  --build-type=complete ^
  toolset=msvc-9.0 ^
  link=static ^
  runtime-link=static ^
  threading=multi ^
  variant=release,debug ^
  stage

圧縮データを読み書きしたいので zlib と bzip2 を取り込んでコンパイルしました。また、最終的にスタティックライブラリが欲しかったので link=static 、 Visual C++ のランタイムを必要としないで動作させたかったので runtime-link=static を指定しました。コンパイラの種類はバージョン含めて toolset=msvc-9.0 のように指定した方が良いそうです。マルチスレッドの指定は必要だっただろうか…

これでシリアライズのサンプルを動かしてみましたが、できあがったバイナリはランタイムに依存しておりませんでした。よかったよかった。

わかります。私もプログラミングを学び始めた頃は、理解のためにライブラリに頼らない方向で考えていました。でも、 Boost は別格ですので、ぜひとも利用を検討してみて下さい。

まず、 Boost は作ってる人からして違います。 Boost は C++ 標準に大きく関わる方々が更新しています。時期 C++ 標準に Boost のアイデアが入ることすらあります（実際に C++0x でも Boost のアイデアが取り入れられています）。いわば規格公認のライブラリとでも申しましょうか。

もう、私は言語の一部と思って使うことにしました。他の言語でも Generics が台頭してきてますし、 C++ を知らない人に「これは全く未知のパラダイムだ！」と思われることもなくなってくると思います。

まず、自分が作ったクラスをシリアライズ可能にするためには、シリアライザにデータを渡したり、デシリアライザからデータを受け取ったりするメソッドを追加し、シリアライズのライブラリがそれにアクセスできるように friend 定義を追加します。

ここまでは想像できるかと思います。しかし、少し考えると、自分で作ったクラスの中で STL 等を使いたい、 STL でなくとも他人が作ったクラスを使いたい、と思い至り、この方法ではシリアライズできないことに気づくと思います。

はい、どうやらできないようです。

しかし、 string や vector やスマートポインタ等、代表的なデータ構造はシリアライズ対応版が Boost のヘッダファイルにあるそうです。これは安心ですね。

#include <boost/serialization/string.hpp>

#include <boost/serialization/vector.hpp>

他人が作ったクラスは、シリアライズメソッドの中で、シリアライズに似たようなことを自分で書くしかないかもしれません。何か良い方法があるのかもしれませんが、自分はゲームでしか使う予定がないので、これ以上追求しませんでした。とりあえずセーブデータが入ればいいかと思います。

やっぱりプレゼンテーションレイヤーが鬼門ですね。作るゲームによって適切に切り替えられるような仕組みが必要です。大丈夫です、きっと yomogi さんが良いゲームエンジンを作ってくれます。

#include <boost/numeric/ublas/vector.hpp>

#include <boost/numeric/ublas/matrix.hpp>

見てわかるとおり、ベクトルと行列を使うことができます。さらに、ベクトル同士の足し算、引き算、スカラー倍、内積、外積、ノルム計算、線形方程式の解を求めるなど、もはや 3D ゲームを作るためにしか存在していないかのようなラインナップとなっております。

ちなみに 2D ゲームでもその恩恵を受けることができますので、メルマガで高度な内容を扱うことになったら使ってみようと思います。期待して待て！です。