今まで、自分で細々と作っているフレームワークはGLFW３をベースにしているものの、Windows 環境しかテストしていなかった。
MacBook Pro を買ったので、Mac に対応させるべく作業をした。
最近はフルタイムで仕事をしているので、自分のプログラミングは時間が限られる、最近ようやく、Windows 版と遜色なく動作するようになったので、要点をまとめてみたい、同じような事をしている人に参考になればと思う。

・カレントディレクトリーの扱いが違う。
アプリケーションが動作しているカレントディレクトリーの、挙動が異なるようだ。
Mac(unix) では基本的に、コンソールから起動した場合と、finder などから起動した場合で、main 関数のパラメーター「argv[0]」に入ってくるパスが異なる。
unix では、アプリケーションのカレントディレクトリーの管理は、シェルが行っており、シェルから起動しない場合を想定しておく必要がある。

Windows では、アプリを起動させたパスをカレントパスとして設定している。

良く、アプリを置いたパスに初期に読み込むファイルなどを置いておく事があるけど、何らかの方法で、相対パスから絶対パスを生成する必要がある。
自分は、「argv[0]」にアプリケーションの起動パスがあるので、それを使って何とかした。
※また、シェルから起動した場合は、argv[0]には、「./xxxx」など、シェルのコマンドラインがそのまま反映されるだけなので、「getcwd」APIなどで、カレントディレクトリーを取得する必要がある。
しかしながら、「getcwd」は、シェルから起動しないと正しいパスを返さないようだ。

・ランタイムライブラリー（要するに DLL、unix 的にはシェアードライブラリー？）
OS-X では、コンパイル時のライブラリーのリンクが固定していて、実行バイナリーを他の環境に持って行く場合には、ライブラリーを期待した場所に置いておく必要がある。（これは設定ファイルで変えられるかもしれないが調べていない）
俺俺フレームワークでは、色々なオープンソースを使っているのだけど、OS-X ではコンソールからコンパイルしてインストールすのが、比較的楽なので、問題は少ないかもしれない。

・システムフォントのパス
当然だけど、OS-X では、フォントパスが違うので、それを対応する必要がある。
ちなみに

/System/Library/Fonts

となる、標準的日本語フォントは

ヒラギノ角ゴ ProN W3.otf

を使っている。

・コンソールの扱い
Windows（mingw）では、リンカーのオプションに「-m window」があり、コマンド起動後にコンソールを表示して、stdout や stderr の表示をするなどに対応出来るけど、OS-X では、必ずコンソールも起動してしまう。
コンソールが必要無い場合はどうするのか？、謎だったけど、色々調べたら、フォルダーで全体を管理するようだ、その際、アプリケーションのアイコンやら、何やら、色々な設定を「info.plist」の XML ファイルに記述する方法のようで、Windows のアプリケーションとは全く考えが違う。

・解像度に対しての対応
MacBook Pro riteina では、高解像度の液晶を使っている、解像度が高い為、見た目の大きさを揃える為には、Window の仮想サイズと、実際のサイズ（フレームバッファのサイズ）が異なり、それ相応の対処をしなければならない。
OpenGLでは、「glViewport」で指定するサイズは、実際の解像度ベースで指定して、プロジェクションマトリックスで指定する大きさは、仮想サイズで指定することになる。
仮想サイズは、実際のサイズの丁度半分となるようだけど、自由なサイズに対応しておく必要がありそうだ。

・スレッド
OS-X は pthread に対応との事だが、pthread の仕様を全て満足している訳では無く、使えるのは一部の API だけなので注意が必要だ、特に悲惨なのは、コンパイルは通るけど、API は何もしないで、エラーコードと共に素通りする。
※名前無しセマフォなど
※現状では、POSIX の API に完全に全て対応しているのは Linux カーネルのみなのかもしれない。
OS-X で pthread のプログラムを作成する場合には、注意して設計する必要がある。
boost や、C++11 の API を使うのが賢いかもしれない。
ただ、現状では、Mingw の環境では、C++11 でも、thread をサポートしていない為、マルチプラットホームでは、コードを共有出来ない。
※一方 Windows には、pthread_win32 ライブラリーがある為、pthread のプログラムを作成するのに、問題は少ない。

・OpenGL プログラムのスワップフレーム
OS-X では、OpenGL のプログラムを待機状態にしたり、他の Window で全て隠すと、スワップフレームが画面のリフレッシュと同期しなくなり素通りになる為、実質的に、描画ループが最高速で回り始める、そうすると、CPU の空き時間を全て食いつぶして負荷が１００％に近くなる。
これは、色々調べたけど、「仕様」のようだ、そこで、この問題を回避する対策が必要だ。
自分のアプリケーションは、GLFW3 を介して、システムと繋がっている為、「待機状態」を検出する方法が無い為、別の方法で、この問題を回避した。
(1)16ミリ秒のタイマータスクを用意する。（usleep、nanosleep など）
※ OS-X の sleep 系は意外と正確なようだ。（Windows のタイマーが不正確すぎなのかもしれない）
(2)フレームの先頭で、先に用意したタスクをスレッドで起動する。（C++11 の future を利用した）
(3)スワップフレームの手前で、先のスレッドの終了を待つ。
この戦略は、フレームレートが 60Hz（16.677ミリ秒） の場合、タイマーが正確な場合を前提としている。
※オーバーヘッドが、0.677 ミリ秒より大きい場合は、待機時間を調整する必要がある。
※スレッドの追加で、システムの負荷が１〜２％増加する。（意外と重い）
※プログラムは、common/glcore.hpp, common/glcore.cpp を参照
※ Windows では、プログラムが待機状態になると、メインループは停止するので、回り続ける仕様自体は、歓迎されるべきなのかもしれない。
なので、Windows では、動かし続ける必要のあるタスクは、メインループに依存しないように設計する必要がある。

--------------------

OS-X は、実質 unix マシンなので、X-code を利用しなくても、コンソールとテキストエディターだけで、遜色無くアプリケーションを開発できて、非常に快適な事が判った。
コンソールは多国語対応で（当然日本語にも）、複雑な設定をする事なく、日本語をスマートに入力、表示出来る。
emacs もコンソールで起動でき、日本語入力にも対応している。
今まで食わず嫌いで、OS-X を使わなかったけど、まぁ、なかなか良い。

今まで、従属規則の生成には、X11 のコマンドであるところの「makedepend」を長らく使って来た、しかし、makedepend コマンドが無い場合（X11 関係アーカイブをインストールする必要がある）
や、コンパイラがインクルードファイルを検索する挙動とは多少違う場合もあったりしていた。
そこで、「gcc」の「-MM」オプションを使ってインクルードパスを収集する方法に切り替えた。
※このコンパイラーオプションは、コンパイラー自らのパスでインクルードファイルのフルパスを出力する、この時、「#if、#endif」などの制御文なども評価する。

通常、コンパイラーは、ソースコードと同じ場所にオブジェクトを生成する、ソースコードを共有して、複数のアプリケーションを作成すると、それでは、不具合が起こる場合もあり（コンパイラーオプションや、デバッグ、リリースビルドなど）、アプリケーション毎に、生成されたオブジェクトコードを管理したい。
そこで、生成オブジェクトを特定のディレクトリーに集中させるようにした。

また、複数のアプリケーションで Makefile の修正を最小限に出来るように、多少の工夫をしてみた。

Makefile の構文を学習しなおしたり、google 先生に教えてもらった make 関係のリンクを観たりで、自分の思ったような構成に出来たので紹介する。

ディレクトリーは以下のような構成にしている。

project:
    common:      ---> アプリケーション共通のソースコードを格納するディレクトリー
        ...:     ---> ソースモジュール毎のディレクトリー
            ...  ---> ソース郡
        ...:
            ...
        ...:
            ...
    xxxx:           ---> xxxx アプリケーションディレクトリー
        xxxx.cpp    ---> xxxx アプリケーション固有のソースコード
        Makefile    ---> xxxx アプリケーションの Makefile
    yyyy:           ---> yyyy アプリケーションディレクトリー
        yyyy.cpp
        Makefile

・各アプリケーションで共通するソースコード郡を「common」ディレクトリーに配置している。
・アプリケーションは、専用ディレクトリーを設けて、そこで、生成された二次ファイルを格納する。
※通常、「release」、「debug」のどちらか

一番のキモは、-MM コマンドの仕様で痛い部分を回避する為の小細工で、以下のリンクを参考にした。
※スイマセン、殆ど同じような物です、VPATH の指定が追加されたくらいです。

Makefile 別ディレクトリに中間ファイル & 自動依存関係設定

この問題は、オブジェクトファイルのパスがフルパスにならない点で、これを改善する為、sed による整形を使って、回避している。
リンクの sed スクリプトでは、「.o」のマッチングが不十分で、特定のファイル名の組み合わせなどで整形を失敗する、そこで、適切に修正した。
「\.o:」「.」を「\.」にする事で、正確に「.」（ピリオド）にマッチするようになる、また、一応、セパレーター「:」を追加して、厳密にマッチするようにしてある。
※詳しくは sed の仕様、-MM の説明を参照の事

「VPATH」を指定すると、make が、ファイルを検索するルートを指定出来るので、関係ソースコードを羅列する部分がスッキリする。

・以下の例は、アプリケーション「player」の Makefile です。
・「TARGET」アプリケーション名（Windows では .exe を追加する）
・「ICON_RC」アプリケーションアイコン指定がある場合、リソースの記述を行う
icon.rcの例

EXE_ICON ICON res/player.ico

・「BUILD」ビルドディレクトリー（debug、又は、release）
※従属規則 *.d 、とオブジェクトファイル *.o が格納される。
・「VPATH」共有ソースコードのルートディレクトリー
・「CSOURCES」C 言語ソースコードのリスト
・「PSOURCES」C++ 言語ソースコードのリスト
・「STDLIBS」標準的ライブラリーのリスト
・「OPTLIBS」オプションライブラリーのリスト
・「INC_SYS」システム系のインクルードパス
・「INC_LIB」ローカルライブラリーのインクルードパス
※従属規則に含まれない
・「PINC_APP」C++ 言語用、インクルードパス
・「CINC_APP」C 言語用、インクルードパス
※従属規則に含まれる
・「LIBDIR」ローカルライブラリーオブジェクトのリンクパス

# Makefile
TARGET    = player.exe

ICON_RC   = icon.rc

# 'debug' or 'release'
BUILD     = release

VPATH     = ../common

CSOURCES  = minizip/ioapi.c \
            minizip/unzip.c

PSOURCES  = main.cpp \
            player.cpp \
            core/glcore.cpp \
.....

STDLIBS    =
OPTLIBS    =    glfw3 glew32 opengl32 glu32 gdi32 imm32 \
                pthread \
                openal winmm dsound \
                png16 jpeg_x86 openjp2 \
                freetype \
                id3tag \
                z \
                mad \
                faad mp4ff

INC_SYS     =    /usr/local/boost_1_54_0

INC_LIB	    =    /usr/local/include \
                 /usr/local/include/libpng16 \
                 /usr/local/include/libjpeg_x86 \
                 /usr/local/include/openjpeg-2.0 \
                 /usr/local/include/freetype2

PINC_APP    =   . ../common
CINC_APP    =   . ../common
LIBDIR      =   /usr/local/lib

INC_S   =    $(addprefix -I, $(INC_SYS))
INC_L   =    $(addprefix -I, $(INC_LIB))
INC_P   =    $(addprefix -I, $(PINC_APP))
INC_C   =    $(addprefix -I, $(CINC_APP))
CINCS   =    $(INC_S) $(INC_L) $(INC_C)
PINCS   =    $(INC_S) $(INC_L) $(INC_P)
LIBS    =    $(addprefix -L, $(LIBDIR))
LIBN    =    $(addprefix -l, $(STDLIBS))
LIBN   +=    $(addprefix -l, $(OPTLIBS))

#
# Compiler, Linker Options, Resource_compiler
#
CP      =    g++
CC      =    gcc
LK      =    g++
RC      =    windres

POPT    =   -O2 -std=gnu++11
COPT    =   -O2
LOPT    =

PFLAGS  =   -DWIN32 -DHAVE_STDINT_H
CFLAGS  =   -DWIN32

ifeq ($(BUILD),debug)
    POPT += -g
    COPT += -g
    PFLAGS += -DDEBUG
    CFLAGS += -DDEBUG
endif

ifeq ($(BUILD),release)
    PFLAGS += -DNDEBUG
    CFLAGS += -DNDEBUG
endif

# 	-static-libgcc -static-libstdc++
LFLAGS	=

# -Wuninitialized -Wunused -Werror -Wshadow
CCWARN	= -Wimplicit -Wreturn-type -Wswitch \
          -Wformat
CPPWARN	= -Wall

OBJECTS	= $(addprefix $(BUILD)/,$(patsubst %.cpp,%.o,$(PSOURCES))) \
          $(addprefix $(BUILD)/,$(patsubst %.c,%.o,$(CSOURCES)))
DEPENDS = $(patsubst %.o,%.d, $(OBJECTS))

ifdef ICON_RC
    ICON_OBJ = $(addprefix $(BUILD)/,$(patsubst %.rc,%.o,$(ICON_RC)))
endif

.PHONY: all clean
.SUFFIXES :
.SUFFIXES : .rc .hpp .h .c .cpp .o

all: $(BUILD) $(TARGET)

$(TARGET): $(OBJECTS) $(ICON_OBJ) Makefile
    $(LK) $(LFLAGS) $(LIBS) $(OBJECTS) $(ICON_OBJ) $(LIBN) -o $(TARGET)

$(BUILD)/%.o : %.c
    mkdir -p $(dir $@); \
    $(CC) -c $(COPT) $(CFLAGS) $(CINCS) $(CCWARN) -o $@

lt;
$(BUILD)/%.o : %.cpp

    mkdir -p $(dir $@); \

    $(CP) -c $(POPT) $(PFLAGS) $(PINCS) $(CPWARN) -o $@

lt;
$(ICON_OBJ): $(ICON_RC)

    $(RC) -i

lt; -o $@
$(BUILD)/%.d : %.c

    mkdir -p $(dir $@); \

    $(CC) -MM -DDEPEND_ESCAPE $(COPT) $(CFLAGS) $(INC_C)

lt; \

    | sed 's/$(notdir $*)\.o:/$(subst /,\/,$(patsubst %.d,%.o,$@) $@):/' > $@ ; \

    [ -s $@ ] || rm -f $@
$(BUILD)/%.d : %.cpp

    mkdir -p $(dir $@); \

    $(CP) -MM -DDEPEND_ESCAPE $(POPT) $(PFLAGS) $(INC_P)

lt; \

    | sed 's/$(notdir $*)\.o:/$(subst /,\/,$(patsubst %.d,%.o,$@) $@):/' > $@ ; \

    [ -s $@ ] || rm -f $@
run:

    ./$(TARGET)
clean:

    rm -rf $(BUILD) $(TARGET)
clean_depend:

    rm -f $(DEPENDS)
dllname:

    objdump -p $(TARGET) | grep "DLL Name"
tarball:

    tar cfvz $(subst .exe,,$(TARGET))_$(shell date +%Y%m%d%H).tgz \

    *.[hc]pp Makefile ../common/*/*.[hc]pp ../common/*/*.[hc]
bin_zip:

    $(LK) $(LFLAGS) $(LIBS) $(OBJECTS) icon.o $(LIBN) -mwindows -o $(TARGET)

    rm -f $(subst .exe,,$(TARGET))_$(shell date +%Y%m%d%H)_bin.zip

    zip $(subst .exe,,$(TARGET))_$(shell date +%Y%m%d%H)_bin.zip *.exe *.dll res/*.*
-include $(DEPENDS)



完全な Makefile は Github にプシュした！

以前に、文字列を渡す場合に、「const char*」と、「const std::string&」などの参照コンテナで渡すのと、どちらを選択すべきか書いた。

C++ はオブジェクト指向言語であり、ポインターを渡すより、コンテナを参照渡しする方が殆どの場合有利なのは明白なのだが、C から移って来た場合、オブジェクト指向プログラムに不慣れな場合もあり、中途半端な設計（ポインターだったり、コンテナだったり）になってしまう事がある。
※思い返してみると、これは自分もそうだった・・・

今回、同じような事例として、「ｘ、ｙ軸」の位置を渡す方法を考えてみたい。

たとえば・・・

void set(int x, int y) { }

のような関数がある場合・・・

struct xy {
    int x;
    int y;
};
void set(const xy& p) { }

このように、「ｘ、ｙ軸」をコンテナに入れて、参照渡しにする方が何かと都合が良い。

しかし、多くの場合、直で値を入れたい場合は、冗長では？
みたいな意見もあるのだが、通常、直で値を入れて呼ぶ事は「稀」と思うけど、それでもそのようなケースが多いなら、以下のようにすべきだろう。

struct xy {
    int x;
    int y;
    xy() { }
    xy(int x_, int y_) : x(x_), y(y_) { }   ///< コンストラクターを定義
};
void set(const xy& p) { }
void set(int x, int y) { set(xy(x, y)); }   ///< 直で呼べるように定義を追加

    set(100, 200);        ///< 直接指定
    set(xy(100, 200));    ///< 直で呼びたい場合、このように書ける。

ここで、構造体 xy だが、メンバーは、public になっていて、アクセサーを使わずにダイレクトにアクセスしている点を検討すべき問題として付け加えておく。
※この例では、自分の流儀でそのような仕様にしているだけで、本来は、このような単純なクラスでも、アクセサーを用意してアクセスする事が望ましいと思う、自分の裁量で、メンバーに与える影響などが少ない場合は、ダイレクトでも良いと思っている為で、このようなダイレクトなアクセス方法に注意して欲しい。
内部の変数にアクセサーでアクセスするようにする事で、安全性や最適化など得られるメリットは他に色々あるのですが、範囲が大きくなり過ぎると思うので、これは、又、別の機会に論じる事とします。

上の例では、メンバーの型は「int」でしたが、構造体 xy をテンプレートにする事で、他の型も簡単に定義できる。

typedef xy<short> s_xy;
typedef xy<int>   i_xy;
typedef xy<float> f_xy;

template<typename T>
struct xy {
    typedef T value_type;
    T x;
    T y;
    void set(T x_, T y_) { x = x_; y = y_; }
    xy() { }
    xy(T v) : x(v), y(v) { }     ///< カスタムコンストラクター（同じ値で初期化）
    xy(T x_, T y_) : x(x_), y(y_) { }    ///< カスタムコンストラクター（個別に初期化）
    xy& operator = (const s_xy& p) { set(static_cast(p.x), static_cast(p.y)); return *this; }
    xy& operator = (const i_xy& p) { set(static_cast(p.x), static_cast(p.y)); return *this; }
    xy& operator = (const f_xy& p) { set(static_cast(p.x), static_cast(p.y)); return *this; }
};

「operator = 」を使い、複数の型に対応する事で、型が違う代入をスムーズに行えるようになるが、「float -> short」や、「float -> int」は、変換出来ない場合がある為注意する必要がある。
※そのような変換が起こった場合は、例外を出すなどが必要かもしれない。

typedef T value_type;

は、テンプレートの実装では、よく使われるやり方で、元の「型」を再定義する事で、そのクラスで使われている「型」にアクセスする方法を提供する。

    s_xy pos(0);    ///< カスタムコンストラクターが定義されている為、ｘ、ｙ、を同じ値で初期化する事が出来る。
    for(s_xy::value_type i = pos.x; i < (pos.x + 10); ++i) {
        ...
    }

※これは、例題なので、名前空間に入れていないが、実際に使う場合には、必ず、何らかの名前空間に入れて運用する必要がある、そうしないと、クラス名が既存のクラスとぶつかってしまう事になる。

「代数」のクラスは、自分で実装しなくても、ネットを探すと、色々なソースを見つける事が出来る、自分で実験的に実装する事で、より広範囲な理解とスキルを身につける事が出来る、そうしてから、より洗練された実装を利用しても良い。
※ある程度自分で作って、利用していると、愛着も沸くし、他の同じような実装に移るのが難しくなる、しかしながら、自分で作ったクラスはメンテナンスし易く、機能を追加したり改良するのが、楽であるメリットがある。

「printf」の功罪と「iostream」

C++ 初心者の頃 C 言語から C++ に移行して、大きな驚きを感じたのは、文字の入出力関係でしょうか？

現在 C++ でプログラムを作成するのが「常」となり、結論から言わせてもらうと、C++ では、もはや「printf」を使う理由は全く無い事です。

今「え？」と言った人は、C++ にまだ移行できていない中途半端な状態だと思われます。

    printf("Hello !!!\n");

では無くて、

    std::cout << "Hello !!!" << std::endl;

です！

C++ に馴染みの無い人には、今まで観た事の無いような、記述で、凄く奇妙に写ると思います。
C++ ではオペレーターをオーバーロード出来る為、「<<」を「シフト」では無く、全く別の意味で使う事が出来ます。
「iostream」クラスでは、cout（stdout）オブジェクトに対して、文字列を流し込む事で、文字の表示を行う事が出来るような設計になっています。
※入力は、std::cin オブジェクトから「>>」で行えます。

以前にとあるプログラマーが「iostream はわかりずらいので使う価値が無い」的な事を言っていましたが、甚だしい勘違いです。
「使い易い」、「使いずらい」と言う感覚は、単純に個人の「慣れ」の問題であって、その感覚だけで「扱いづらい」と結論してしまう事に危機的な危うさを感じます。
多分、iostream を設計した人々は、printf に関連する諸問題にとっくの昔に気がついていて、それを避け、尚且つ簡単に扱えるようにするにはどうしたら良いかを長い時間考えたり、ディスカッションして、現在の実装になったと思います。
iostream は、printf に比べると速度が遅い（負荷が大きい）と言うのはあるかもしれませんが、printf に比べると、安全で、プログラマーが受けられる恩恵が大きい優れた物です、それを良く理解しないままにわざわざ禁止する必要は無いのです。

「どんなに注意しても、人間は間違いを犯す」と言う基本的な事実があります。
printf 内のフォーマットと、可変長の引数の「型」の整合性は、コンパイラではチェックに限界があり、極めて深刻な問題をそのままエラー無くコンパイルする事が可能で、その場合、スタックを破壊する事で、微妙で見つけにくいバグをアプリケーションの動作に取り込んでしまう事があります。

iostream であれば、うっかりミスは、コンパイラがエラーを出しますし、スタックを壊すような危険な事もありません。

それでも、尚、printf の使い易さが忘れられない人には、「boost/format.hpp」を使って下さい。
これなら、ほとんど printf のような感覚で、しかも、安全に運用する事が出来ます。
※フォーマットと、引数の型の誤りには「例外」がスローされます。

文字列から数値、数値から文字列の変換には、「boost/lexical_cast.hpp」
と言うのがあり、非常に便利です、これがあれば、scanf を使う必要もありません。
※変換の失敗には「bad_lexical_cast 例外」がスローされるので、それをキャッチして、変換の失敗に備える必要がある。

これはゲームの開発での話ですが、ほとんど何処の会社でも printf を使う事を禁止しています、それは、どんなに注意しても、ミスを無くす事は出来ない為、見つける事が困難な問題をシステムに混入させてしまう危険を避ける為です。
※通常、リリースビルドでは #define で printf、sprintf などをオーバーロードして、命令を無効にするようなマクロが組まれています。

ただ、組み込みでは、残念な事があります、gcc の stdc++ ライブラリーでは、iostream クラスは他との依存が大きく巨大で、リンクすると、通常数百キロバイトのプログラムメモリーと、数十キロバイトのワークエリアを消費してしまいます、これでは、少ないリソースのマイコンでは物理的に使えません。
そこで、もし必要なら、小規模な iostream クラスを作成する必要があります（これは車輪の再発明ではありません）、ホビーで使うのであっても、あくまでも、安全性と利便性から、printf を使わない決断をすべき事項だと思います。
※以前、C 言語の時代でも、printf が巨大な為、多くの人が、tiny printf のような物を作って使っていました。
※オペレーターや、オブジェクト指向の勉強にもなるので、自分で作ってみると楽しいかもしれません。

一応、私が実装した、クラスを紹介します。
※これは、出力先として、「void sci_put(char);」、「void sci_puts(const char*);」などのシリアルインターフェースを使っています。

namespace utils {
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  chout クラス
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    struct chout {
    static const char endl = '\n';

    private:
    char        sup_ch_;
    char        hex_ch_;
    uint8_t     len_;

    public:
        //-----------------------------------------------------------------//
        /*!
            @brief  コンストラクター
        @param[in]  out 文字出力関数
        */
        //-----------------------------------------------------------------//
     chout() : sup_ch_('0'), hex_ch_('a'), len_(0) { }

        //-----------------------------------------------------------------//
        /*!
            @brief  16 進表示の英数字を大文字にする
        @param[in]  cap 「false」を指定すると小文字
        */
        //-----------------------------------------------------------------//
    void hexa_decimal_capital(bool cap = true) {
        if(cap) hex_ch_ = 'A'; else hex_ch_ = 'a';
    }

        //-----------------------------------------------------------------//
        /*!
            @brief  表示文字数を指定
        @param[in]  len 表示文字数
        */
        //-----------------------------------------------------------------//
    void set_length(uint8_t len) { len_ = len; }

        //-----------------------------------------------------------------//
        /*!
            @brief  ゼロサプレス時の文字を指定
        @param[in]  ch  文字
        */
        //-----------------------------------------------------------------//
    void suppress_char(char ch) { sup_ch_ = ch; }

        //-----------------------------------------------------------------//
        /*!
            @brief  文字表示
        @param[in]  ch  文字
        */
        //-----------------------------------------------------------------//
    void put(char ch) const { sci_putch(ch); }

        //-----------------------------------------------------------------//
        /*!
            @brief  文字列の表示
        @param[in]  str 文字列
        */
        //-----------------------------------------------------------------//
    void string(const char* str) const { sci_puts(str); }

        //-----------------------------------------------------------------//
        /*!
            @brief  長さ指定文字列表示
        @param[in]  str 文字列
        @param[in]  len 長さ
        */
        //-----------------------------------------------------------------//
    void len_string(const char* str, uint8_t len) const {
        while(len_ > len) {
            put(sup_ch_);
        ++len;
        }
        string(str);
    }

        //-----------------------------------------------------------------//
        /*!
            @brief  16 進数の表示
        @param[in]  val 値
        */
        //-----------------------------------------------------------------//
    uint16_t hexa_decimal(uint32_t val) const {
        char tmp[8 + 1];
        uint16_t pos = sizeof(tmp);
        --pos;
        tmp[pos] = 0;
        do {
        --pos;
        char n = val & 15;
        if(n > 9) tmp[pos] = hex_ch_ - 10 + n;
        else tmp[pos] = '0' + n;
        val >>= 4;
        } while(val != 0) ;

        len_string(&tmp[pos], sizeof(tmp) - pos - 1);
        return sizeof(tmp) - pos - 1;
    }

        //-----------------------------------------------------------------//
        /*!
            @brief  10 進数の表示
        @param[in]  val 値
        @param[in]  minus   マイナス符号を表示する場合「true」
        @return 表示文字数
        */
        //-----------------------------------------------------------------//
    uint16_t decimal(uint32_t val, bool minus = false) const {
        char tmp[11 + 1];
        uint16_t pos = sizeof(tmp);
        --pos;
        tmp[pos] = 0;
        do {
            --pos;
        tmp[pos] = '0' + (val % 10);
        val /= 10;
        } while(val != 0) ;

        if(minus) {
        --pos;
        tmp[pos] = '-';
        }

        len_string(&tmp[pos], sizeof(tmp) - pos - 1);
        return sizeof(tmp) - pos - 1;
    }

        //-----------------------------------------------------------------//
        /*!
            @brief  符号付き 10 進数の表示
        @param[in]  val 値
        @return 表示文字数
        */
        //-----------------------------------------------------------------//
    uint16_t decimal(int32_t val) const {
        bool minus = false;
        if(val < 0) {
            minus = true;
        val = -val;
        }
        return decimal(static_cast(val), minus);
    }

    chout& operator << (const uint32_t val) {
        decimal(val);
        return *this;
    }

    chout& operator << (const int32_t val) {
        decimal(val);
        return *this;
    }

    chout& operator << (const char* str) {
        string(str);
        return *this;
    }

    chout& operator << (const char ch) {
        put(ch);
        return *this;
    }
    };
}

※ただ、このクラスでは、浮動小数点や、２進数、８進数の表示をサポートしていません、浮動小数点表示が出来ないのは痛いので、改修する予定です。

現在、独自の format クラス一式を実装してあります、GitHUB 参照下さい。

今まで、Windows では主に cygwin64 を使って開発環境を整えていた。
しかし、ここにきて、色々な不具合に遭遇する・・・

たとえば、組み込みマイコンのクロス開発環境として、gcc をビルドするのだけど、cygwin では途中で必ず失敗する。
※cygwin では、何か特別なオプションを追加するのかもしれないが、情報が無いし、原因を追って、試すのに時間が掛かり過ぎる。
※大抵は、gcc がコンパイルエラーで止まる。
また、少し大きなライブラリー（bullet physics）をコンパイルしようとした場合にスタック不足で gcc-w64-mingw32-gcc がクラッシュしたり、リンク中に止まったりと、非常に辛い状況が連発していた。
状況を改善する為に、ソースを追ったり、オプションを追加したり、情報を求めて時間を浪費したものの、良い改善策が見つからない、これは、cygwin のバージョンアップにより解消するのかも知れないと思ったりもしたが、もう疲れた・・・
そこで、別の解決策として、MinGW 環境を試してみる事にした。

MinGW は、よりコンパクトに必要最小限のコマンドを集約した、gcc を使った Windows の開発環境と思えば良いと思う。
MinGW には MinGW の流儀（常識）があり、それを学ぶ必要がある為、時間がかかるので、躊躇していたが、使ってみない事には判らない。

それで、とりあえず、インストーラーを使ってインストールしてみた。

しかし、入れたハズの gcc すら動かない！？
何で？、と思って数日、profile のパスにバグがあり、それが原因だったようだ。

/c/MinGW/msys/1.0/etc/profile
の１９、２１行目
/mingw/bin:/bin ---> /c/mingw/bin:/bin
ドライブレターが抜けているようだが、正規のインストーラーでインストールしてこの完成度は「痛い」としか言い様が無い、ホント大丈夫なの？

気を取り直して、コマンド窓を、評判の mintty にしてみた、これは簡単、情報も多く直ぐに導入出来た。

自分は emacs 使いなので、コンソールで使える emacs を使いたかったが、MinGW では標準では無いので、仕方なく、Windows の emacs を入れて、パスを通した。

ここまで出来て、判った事。

・MinGW では、コンソールで emacs を動かすのは難しいようだ。（vim は標準であるが、キーバインドの慣れもあるので自分には使いづらい）
・Windows の日本語ファイル名などをスマートに解決出来ないようだ。（色々な理由で UTF-8 を使いたいが、それだと色々破綻する、とはいえ、CP932（Shift-JIS）も駄目で、日本語ファイル名の文字化けは我慢するしか無いようだ。
・cygwin では、大抵の unix コマンドは揃っていて、インストーラーで簡単にインストール出来るが、MinGW では、標準に無い物は自分でコンパイルして導入する必要があり、簡単に導入出来るものと、パッチを当てたり、改修する必要がある物など、簡単では無い場合があるようだ。

まず、自分のフレームワークで使っているライブラリーをコンパイルする必要がある。
「configure、make」で解決できるものと、「cmake」を使う物があるみたいなので、cmake の windows 版をインストールして、パスを通した。
※cmake はMinGW で動作する実行ファイルを作るのでは無く、windows 専用の物を使うようで、GUI 環境で使える版も付いてくる。

（１）標準的な各種ライブラリーのインストール

Windows 関係ライブラリー：
    mingw-get install mingw32-w32api

pthread ライブラリー：
    mingw-get install mingw32-pthreads-w32

zlib ライブラリー：（標準では DLL しか入らないようだ）
    mingw-get install mingw32-libz

※「mingw-get」で、GUI が起動するので、それで、必要そうな物はインストール出来る。

（２）GLFW-3.0.4 のコンパイル
MinGW の常識が判っていなかった為、コンパイル出来るまで試行錯誤が続いた。
glfw3 のアーカイブを解凍したら、ディレクトリーを移って。

    cmake -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=/usr/local

として作成する。
※cmake は途中で失敗したら、キャッシュが残るようで、後何をやっても駄目ななので、アーカイブからやり直した（他にもっと良い方法があると思う）

後はお決まりの・・・

    make
    make install

とりあえず、GLFW3 のコンパイルは出来た。

ここまでの感触で、自分フレームワークを MinGW に移っても問題無いように感じた。

追記：2014/1/21
（３）freetype-2.5.2 ライブラリーの構築
freetype は、TrueType のレンダリングを行うオープンソースライブラリーで、自分のフレームワークでも日本語フォントの描画で使っている。
このライブラリーのコンパイルは、少し工夫が必要だった・・
インクルードファイルの相互依存の影響で、定義がすっぽ抜ける現象が起こる、本来はもっとスマートに解決したいが、無理やりだが以下のように解決した。

「ftgip.c」に、typedef を二行追加。
    typedef long off_t;
    typedef long long off64_t;

    ./configure --without-png
※ PNG が必要なのは、TrueType ファイル内に PNG でエンコードされたフォントのビットマップがあるのだろうけど、とりあえず、無視するようにした。

    make
    make install

（４）physics bullet-2.82 のコンパイルとデモプログラムの生成
bullet は物理法則をシュミレーションする演算ライブラリーで、色々な場面で使われている。
Visual Studio でコンパイルするのが一般的なようだが、MinGW でもライブラリーを作成する事が可能なようだ。
※現状の gcc-4.8.1 では、コンパイル中にクラッシュする為、ライブラリーを作れないが、クラッシュするソースを微妙に修正するとコンパイルが正常終了する事が判った。

修正１： src/BulletCollision/CollisionDispatch % emacs btInternalEdgeUtility.cpp
内「struct btConnectivityProcessor : public btTriangleCallback」クラスで、

btVector3 calculatedEdge = edgeCrossA.cross(edgeCrossB);
を、以下のように修正
calculatedEdge = edgeCrossA.cross(edgeCrossB);

btVector3 calculatedNormalB = normalA;
を、以下のように修正
calculatedNormalB = normalA;

変数として以下の二行を追加する。
	btVector3 calculatedEdge;
	btVector3 calculatedNormalB;
※この修正、厳密には正しく無いが、多分動作するだろうと思う、正しく動作しているかの検証はしていない、bullet は発展途上で、実装があっても使われていない事もあるので、どのデモプログラムを動作した場合にこのクラスが動くか見極めていない、コンパイルが通るだけのワークアラウンドと思って欲しい。

修正２： src/BulletDynamics/Character % emacs btKinematicCharacterController.cpp
383、384 行目をコメントアウト（単純に使われていないが、あるだけで gcc がクラッシュする・・）
///     btScalar hitDistance;
///     hitDistance = (callback.m_hitPointWorld - m_currentPosition).length();

GLUT の対応：
GLUT は、MinGW 用にコンパイルすれば良いのだが、GLFW3 を使うようになって OpenGL では使わなくなった為、bullet のデモを動かす為の対応として、
Glut/GL/glut.h ---> /c/MinGW/mingw32/include/GL にコピーする。
又、ライブラリー glut32.lib を、名前を変更して、コピーする ---> /c/MinGW/mingw32/lib/libglut32.a
※VisualStudio で C 言語ソースだけでコンパイルされたライブラリーは gcc のライブラリーと互換性がある。

    cmake -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=/usr/local
    make
    make install

（５）libpng-1.6.8 ライブラリーの構築
これは、普通に問題なく構築できる

    ./configure
    make
    make install

（６）openjpeg-2.0.0 ライブラリーの構築
標準的には、シェアードライブラリー形式（DLL）で生成される為、それをOFFにしてスタティックライブラリーにする

    cmake -G "MSYS Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF -DCMAKE_INSTALL_PREFIX=/usr/local
    make
    make install  

（７）JPEG ライブラリーの構築
JPEG ライブラリーは、x86 CPU の場合、マルチメディア命令で最適化されたバージョンがあるので、それを使う。
Independent JPEG Group's JPEG software release 6b
with x86 SIMD extension for IJG JPEG library version 1.02
※VisualStudio の C コンパイラで作成されたライブラリーファイルは、gcc と互換性があるので、「xxx.lib」を「libxxx.a」などにリネームすれば良い。
このライブラリーは非常に高速なので、画面をキャプチャーしてそれをリアルタイムに JPEG 圧縮して出力すれば、動画にも対応できる。（モーション JPEG 的な・・）
※生の画像を出力しない方が、ファイルサイズが小さくなり、高速化する。

（８）mupdf-1.3 ライブラリーの構築
mupdf ライブラリーはオープンソースの PDF ファイルを展開してビットマップを生成するライブラリーで、PDF を簡単に開けるので、便利に使っている。
このライブラリーは、freetype、openjpeg、jpeg、jbig2dec などを利用するのだけど、各ライブラリーのバージョンの違いを吸収する為、全てのソースコードを同梱している、構築には無駄にならないように、自前のライブラリーをリンクさせる。

まず Makefile を修正

3 行目「build ?= debug」を「build ?= release」としとく。

「include Makethird」をコメントアウトしておく「# include Makethird」

LIBS に追加「LIBS += -L/usr/local/lib -lpng -ljpeg_x86 -lopenjp2 -ljbig2dec -lfreetype -lz」

CFLAGS にも追加「CFLAGS += -I/usr/local/include -I/usr/local/include/openjpeg-2.0 -I/usr/local/include/libjpeg_x86 -I/usr/local/include/freetype2」
※JPEG ライブラリーは x86 CPU 用に最適化されたバージョンを使っている。

    make
    make install