この記事はC++ Advent Calender 2014の参加記事です。

感覚的には、組み込み関係の業界では、Ｃ＋＋の取り組みはかなりお寒いものがあります。

現代の組み込みでは、３２ビットＣＰＵ、ＦＰＵ内蔵、１００ＭＨｚ動作、そんなデバイスが５３９円、gcc で開発でき、もちろんＣ＋＋を使えます、ＳＴＬやｂｏｏｓｔは限定的に使えます。
※メモリーが少ないので、メモリーを多く必要なライブラリーに起因したクラスは使えません（たとえば、iostream 関係は、非常に多くメモリーを消費する為、デバイスによっては使えません）

去年は「WinAVR C++ の実力とは！？」を書きました。
ＡＶＲマイコンは８ビットのＲＩＳＣマイコンで、扱えるリソースが少ない為もあり、ＳＴＬが使えないなど制限がありました。
今回は、ルネサス エレクトロニクスの３２ビットマイコンであるＲＸ６００シリーズで、Ｃ＋＋の開発環境や、Ｃ＋＋で実装するＩ／Ｏ定義クラスの紹介をしたいと思います。

ＲＸ６２１マイコンボード

・搭載マイコン：Ｒ５Ｆ５６２１８ＢＤＦＰ（３２ビットＲＸコア）
・プログラム用フラッシュメモリ：５１２Ｋバイト
・データ用フラッシュメモリ：３２Ｋバイト
・ＲＡＭ：９６Ｋバイト（ノーウェイト動作）
・動作周波数：９６ＭＨｚ（１２ＭＨｚをＰＬＬにより８逓倍動作）

ＲＸマイコンは、ＣＩＳＣ型の３２ビットマイコンで、低消費電力、安価、高機能、高速など、色々なメリットがある国産のマイコンです。
組み込み系マイコンと言えば、ＡＲＭの人気がもの凄く高く、色々なメーカーが採用している為、バリエーションも多く価格も安く、開発環境も整っていると言えるでしょう。
しかしながら、ＲＸマイコンは、自分が評価した価格ゾーンでは、ＡＲＭより多くのメリットがあると感じます。
日本のメーカーにエールを送りたいとゆーのもありますが、コストが同じ程度なら、性能、入手性、日本語マニュアルなど、より扱いやすい物を使う方が効率が良いと感じます。
それでも、本当はＡＲＭの方が優位だとは思いますが、天邪鬼なんでＲＸ押しです！ｗｗｗ

開発環境：

ルネサスでは、開発ツールとして、自社開発の統合開発環境を用意しており、無料版（６４キロバイト以上のバイナリーを作れない）もあります。
又、ＧＮＵを使った無料の統合開発環境「ＫＰＩＴ」も使う事が出来ますが、ルネサス提供のサンプルプログラムをコンパイル出来ないなど、冷遇されており、自分のようにコマンドラインで、コンパイラ、リンカー、Makefile、emacs で開発を進めるスタイルにも合いません。
・統合開発環境では多くの場合、裏で、目に見えない「何か」をやっており、「つぶし」が利かない。
・サターンの時代（ＳＨ２）に、自社開発のコンパイラを使った経験から、あまり良い印象が無いので、最初から使う気にもならず評価もしていません。
・新しい統合開発環境の操作を学ぶのに時間がかかる。
・少し大きなプログラムを作ったら、簡単に６４キロバイトを超えてしまい、有料版ツールが必須になるが、数十万円の開発ツールは買う気にはなりません。
・ gcc ならソースコードを取ってきて、自分でコンパイルすれば、ＲＸ用の gcc を使う事が出来ます。
・自分で開発環境を用意する場合、デバッグ環境も自分で整えなければなりませんが、そこは、経験とアイディアで乗り切りますｗｗｗ
・マイコンのフラッシュメモリーにプログラムを書き込むツールは、無料版があり（Windows環境のみ）こちらは、大きな制限はありません。
・メーカー専用のコンパイラは、gcc より、進んだ最適化が出来るとか言いますが、非常に限られた場合の評価しか宣伝していない為、懐疑的です。
・メーカー製ＩＤＥの良い部分としては、Ｊ−ＴＡＧプローブなどで行うリアルタイムのデバッグ環境などです。

マイコン用クロス開発用 gcc のビルドは、以下の３つのバージョンがマッチしないと、コンパイルに失敗する場合があります。
ＲＸマイコンの場合、最新版は、以下の３つの組み合わせになるようです。
GCC 4.8.3
Binutils 2.24
Newlib 2.1.0
※まだ、自分は4.7.3を使っているので、試していません。

Windows の cygwin 環境では、コンパイルを通す為には、色々なオプションを付ける必要があるようで、大抵標準のオプションだけではコンパイルに失敗します。
又、コンパイルに必要な、ツールのバージョンにも影響するようで、再現性に乏しく困難なので、最近は MSYS(MinGW) でコンパイルしています、こちらは、比較的普通にコンパイルに成功します。
MacOSやLinuxでは、何の苦労も無くコンパイル出来ます、ただし、デバイス内臓のフラッシュＲＯＭに書き込むツールが対応していないので、現実的には Windows を使う事になります、現在、コマンドラインから、フラッシュへ書き込むプログラムを独自開発している最中です。

組み込みマイコン用の gcc が、ＰＣの gcc と違う点は、スタートアップルーチンをデバイス毎に用意する必要があり（デバイスによって、持っているＲＡＭ、ＲＯＭのサイズが違い、初期化を行う方法が異なっているのが普通です）、多少複雑です、マイコンの場合、コールドスタートした状態では、割り込みは禁止され、最低限の設定状態で起動しています。
なので、最初に行うべきは、デバイスの必要な部分を初期化して、スタックや、記憶割り当てが使うメモリーの領域設定、Ｃ＋＋の場合は、静的なクラスのコンストラクターを呼び出して初期化するなど、行う必要があります。

rx-elf/lib/rx.ld
ＲＸ用 gcc をビルドしたら、上記パスに、スタートアップに必要なファイルが用意されています。
「rx.ld」は、リンカースクリプトで、データセクション、プログラムセクション、など、初期化が必要な領域、初期化を必要とするクラスのコンストラクターやデストラクターのエントリーテーブルなど必要なリンク情報が入っています。
また、リンカースクリプトで、デバイスに適合するＲＡＭやＲＯＭ領域のアドレスを指定します。

以下は、リンカースクリプトの一部です。

OUTPUT_ARCH(rx)
ENTRY(_start)
MEMORY {
RAM(rwx) : org = 0x00000000, len = 0x00002000
ROM(rx) : org = 0xFFFF0000, len = 0x00010000
}
SECTIONS {
    _usp_init = 0x00001f00;
    _isp_init = 0x00002000;
    .fvectors 0xFFFFFFD0 : {
        vect.o(.fvectors)
    }

...

※ハードウェアーベクターテーブルの指定もあります。

マイコンは電源が入るとリセット信号がアサートされ、ハードウェアーベクターにあるリセットベクター先に飛び、プログラムを開始します。
以下はスタートルーチンで、マイコン独自の命令を実行する為、アセンブラで記述してあります。
※この部分だけはアセンブラを使う必要があります。

	.global _power_on_reset
_power_on_reset:
.global _start
_start:
# スタックの設定
    .extern _usp_init
    mvtc #_usp_init, usp
    .extern _isp_init
    mvtc #_isp_init, isp
# 割り込みベクタの設定
    .extern _interrupt_vectors
    mov.l #_interrupt_vectors, r5
    mvtc r5,intb
    mov.l #0x100, r5
    mvtc r5,fpsw
# Iレジスタを設定し、割り込みを許可する
    mov.l #0x00010000, r5
    mvtc r5,psw
# PMレジスタを設定し、ユーザモードに移行する
    mvfc psw,r1
    or	#0x100000, r1
    push.l r1
# UレジスタをセットするためにRTE命令を実行する
    mvfc pc,r1
    add	#0x0a,r1
    push.l r1
    rte
    nop
    nop
# init() 関数から開始
    .extern _init
    bsr	_init

    .global _set_intr_level
_set_intr_level:
    and	#15,r1
    shll	#24,r1
    or	#0x100000,r1
    mvtc r1,psw
    rts
    nop

    .global _exit
_exit:
    wait
    bra _exit

これは、「init.c」で、main に飛ぶ前に行う初期化を含んだものです。
※ＲＸマイコンでは割り込みベクターのベースアドレスを変更できるので、自分のシステムでは、利便性を考慮して、ＲＡＭ上に置いてあります。

int main(int argc, char**argv);
extern int _datainternal;
extern int _datastart;
extern int _dataend;
extern int _bssstart;
extern int _bssend;
extern int _preinit_array_start;
extern int _preinit_array_end;
extern int _init_array_start;
extern int _init_array_end;
extern void (*interrupt_vectors[256])(void);
extern void null_task_(void);
int init(void)
{
    // 割り込みベクターテーブルの初期化
    for(int i = 0; i < 256; ++i) {
        interrupt_vectors[i] = null_task_;
    }

    // R/W-data セクションのコピー
    {
        int *src = &_datainternal;
        int *dst = &_datastart;
        while(dst < &_dataend) {
            *dst++ = *src++;
        }
    }

    // bss セクションのクリア
    {
        int *dst = &_bssstart;
        while(dst < &_bssend) {
            *dst++ = 0;
        }
    }

    // 静的コンストラクターの実行（C++ ）
    {
        int *p = &_preinit_array_start;
        while(p < &_preinit_array_end) {
            void (*prog)(void) = (void *)*p++;
            (*prog)();
        }
    }

    {
        int *p = &_init_array_start;
        while(p < &_init_array_end) {
            void (*prog)(void) = (void *)*p++;
            (*prog)();
        }
    }

    // main の起動
    static int argc = 0;
    static char **argv = 0;
    int ret = main(argc, argv);
    return ret;
}

これで、main から実行でき、後は、通常のアプリケーションとほぼ同じとなります、最低限これだけあれば、後は、工夫次第で何とでもなります。
※リンカーで、独自のリンカースクリプトを使い、標準のスタートアップを行わないので、「-nostartfiles」を指定します。

最低限のデバッグとして、シリアルインターフェースを繋いで、ターミナルで文字の入出力が必要な場合、stdin、stdout に相当する部分を実装する必要があります。
RX63Tでは無理ですが、RX621では、それらの実装で、iostreamクラスを使え、通常のＰＣアプリとほぼ遜色無く動作します。
※ＰＣでは、メモリーの消費はあまり気にしませんが、組み込みでは、注意する必要があります。

Ｉ／Ｏ定義：

組み込みマイコンでのデバイスドライバーに相当する部分は、通常は、Linux のようなシステムとは違い、カーネルによるしばりは無く、自由に直接プログラム出来ます。
であるにも係わらず、未だに、「Ｃ」でプログラムする事が当たり前のような状況になっています。
デバイスメーカーが提供するサンプルプログラムも、Ｃ＋＋で作られたのは見た記憶がありません。（ＡＲＭではあるようです）
※それ以前に、サンプルプログラムの品質が低いと感じます。
趣味で、組み込みマイコンのプログラムをする場合でも、Ｃ＋＋は敬遠されている感じがします。

さて、組み込みマイコンでは、Ｉ／Ｏ（シリアルコミュニケーション、A/D 変換、ポートなど）の操作を直接行いますが、最近のＩ／Ｏは高機能で、非常に多くの機能があります。
定義は複雑で肥大化しており、マイコンのバリエーションにより、機能が微妙に異なったりする場合もあります、もはや、一つのヘッダーでは、管理できないと思われます。

たとえば、ルネサスは、マイコン内のＩ／Ｏの機能を定義したヘッダーを提供していますが、これは、処理系依存で実装されている為、gcc でそのまま使う事は出来ません。
また、基本的に「Ｃ」言語を想定した定義なので、Ｃ＋＋でプログラミングしたい場合にあまりメリットがありません。

これは、ＲＸ６２Ｎの定義ヘッダーの一部です（Ａ／Ｄ変換の部分です）

struct st_ad {
	unsigned short ADDRA;
	unsigned short ADDRB;
	unsigned short ADDRC;
	unsigned short ADDRD;
	char           wk0[8];
	union {
		unsigned char BYTE;
		struct {
			unsigned char :1;
			unsigned char ADIE:1;
			unsigned char ADST:1;
			unsigned char :1;
			unsigned char CH:4;
		} BIT;
	} ADCSR;
	union {
		unsigned char BYTE;
		struct {
			unsigned char TRGS:3;
			unsigned char :1;
			unsigned char CKS:2;
			unsigned char MODE:2;
		} BIT;
	} ADCR;
	union {
		unsigned char BYTE;
		struct {
			unsigned char DPSEL:1;
		} BIT;
	} ADDPR;
	unsigned char  ADSSTR;
	char           wk1[11];
	union {
		unsigned char BYTE;
		struct {
			unsigned char :6;
			unsigned char DIAG:2;
		} BIT;
	} ADDIAGR;
};

ビットフィールドが使われています、これは、処理系依存で、gcc では、ＬＳＢ、ＭＳＢが逆になります。
また、最適化した場合に、適切なビット幅のアクセス（３２ビットのＩ／Ｏに８ビットのアクセスなど）が行われない場合があり、ＲＯ（リードのみ）、ＷＯ（ライトのみ）などの表現も無く、読みにくく、使いやすいとは言えないと思います。

そこで、Ｃ＋＋をもっと積極的に使って定義ファイルを作ったらどうかと考えます。
下の実装は、上のビットフィールドから、テンプレートを使った実装です。（少し冗長な部分があります）

//=====================================================================//
/*!	@file
	@brief	RX62N, RX621 グループ・AD 定義 @n
			Copyright 2013 Kunihito Hiramatsu
	@author	平松邦仁 (hira@rvf-rc45.net)
*/
//=====================================================================//
#include "io_utils.hpp"

namespace device {

    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  AD 定義
        @param[in]  base  ベース・アドレス
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    template <uint32_t base>
    struct ad_t {

        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        /*!
            @brief  ADDRA レジスタ
        */
        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        io16<base + 0x00> ADDRA;

        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        /*!
            @brief  ADDRB レジスタ
        */
        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        io16<base + 0x02> ADDRB;

        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        /*!
            @brief  ADDRC レジスタ
        */
        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        io16<base + 0x04>	ADDRC;

        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        /*!
            @brief  ADDRD レジスタ
        */
        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        io16<base + 0x06>	ADDRD;

        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        /*!
            @brief  ADCSR レジスタ
        */
        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        typedef io8<base + 0x10> adcsr_io;
        struct adcsr_t : public adcsr_io {
            using adcsr_io::operator =;
            using adcsr_io::operator ();
            using adcsr_io::operator |=;
            using adcsr_io::operator &=;

            bits_t<adcsr_io, 0, 4>	CH;
            bit_t<adcsr_io, 5>	ADST;
            bit_t<adcsr_io, 6>	ADIE;
        };
        static adcsr_t	ADCSR;

        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        /*!
            @brief  ADCR レジスタ
        */
        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        typedef io8<base + 0x11> adcr_io;
        struct adcr_t : public adcr_io {
            using adcr_io::operator =;
            using adcr_io::operator ();
            using adcr_io::operator |=;
            using adcr_io::operator &=;

            bits_t<adcr_io, 0, 2>	MODE;
　          bits_t<adcr_io, 2, 2>	CKS;
            bits_t<adcr_io, 5, 3>	TRGS;
        };
        static adcr_t	ADCR;

        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        /*!
            @brief  ADDPRA レジスタ
        */
        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        typedef io8<base + 0x12> addpra_io;
        struct addpra_t : public addpra_io {
            using addpra_io::operator =;
            using addpra_io::operator ();
            using addpra_io::operator |=;
            using addpra_io::operator &=;

            bit_t<addpra_io, 7>	DPSEL;
        };
        static addpra_t	ADDPRA;

        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        /*!
            @brief  ADSSTR レジスタ
        */
        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        static io8<base + 0x13> ADSSTR;

        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        /*!
            @brief  ADDIAGR レジスタ
        */
        //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
        typedef io8<base + 0x15> addiagr_io;
        struct addiagr_t : public addiagr_io {
            using addiagr_io::operator =;
            using addiagr_io::operator ();
            using addiagr_io::operator |=;
            using addiagr_io::operator &=;

            bits_t<addiagr_io, 0, 2>	DIAG;
        };
        static addiagr_t	ADDIAGR;

    };
    typedef ad_t<0x00088040>	AD0;
    typedef ad_t<0x00088060>	AD1;
}

※io_utils.hppは、git にありますので参照の事。
今までにこのような取り組みは多少あり、同じような考えによる実装はいくつか参考にした事がありますが、不満な部分などがあり、結局自分で考えて実装したものです。
・ビットと機能の対比がわかりやすい。
・８、１６、３２ビットアクセス、ＲＯ、ＷＯ、ＲＷを表現できる。
・最適化レベルに関係無く、厳密なアクセスを行える。
・エンディアンに依存しない。
・処理系に依存しない。（実際は gcc 以外で試していませんが、x86 の clang でシュミレーターで実験しています）
・最適化されたアセンブラソースを確認して、これなら満足できると思う。
※但し、レビューもされていませんし、もっと良い方法、適切な実装があるかもしれません。
※参照ＲＸ、Ｉ／Ｏ関係
※ＲＯ、ＷＯ、ＲＷを分ける必要があるので、読み出しの場合は、（）オペレーターを使っています。

クラス化した事で色々な恩恵を受けられます。
たとえば、シリアルコミュニケーションは、通常複数チャネルがありますが、Ｉ／Ｏ部分のアクセスをクラス化した事で、かなりスッキリ書けるようになり、異なったチャネルの操作もテンプレートで簡単に記述できるようになりました。

Ｉ／Ｏ操作をＣ＋＋で書けると何がありがたいかと言うと、テンプレートが使える事で、微妙な違いを、隠蔽して、判りやすくて使いやすい入出力クラスをシンプルに書けます。

組み込みでＣ＋＋を使うべき理由の一つです。

最後に：

組み込みの世界では、何故か、Ｃ＋＋が敬遠される傾向にあると感じがしますが、Ｃ＋＋こそ、組み込みに適した言語と思えてなりません。

これらＲＸマイコン関連の成果は、以下のリンクで公開していますので、興味ある人はどうぞ。

ＲＸ関係ソースコード

OS-X 対応で、Windows はまぁとりあえずスルーしても良いかなぁーって思ったけど、やっぱり折角動くもんなら、
少しの労力でマルチプラットホームになる事だしサポートしようと思い、少しばかり修正した。

MSYS の Mingw 環境では、C++11 の thread 関係 API をサポートしていない。
そこで、それら API を使わないように修正をするだけの事で、Mac、Windows 両対応となった。

内部ソースには、機種依存の条件分岐が色々あるのだが、それらは、今後少しづつ無くしていき、クリーンな状態
へ移行する。

以前のブログで、Mingw 環境の構築を少しだけ載せたけど、新しいフレームワークでは、Mac 対応で、少しばかり
環境を更新したので、その辺りを少し解説しておく。

(1) MP3 タグ情報ライブラリー
以前のシステムでは、tag 情報を取得するライブラリーとして、id3tag ライブラリーを使っていて、機能的にどう
しても不足していた部分やバグを修正して使っていたのだけど、色々探したけど、修正したソースが無い事が判った・・
そこで、少し探して、簡単に使えそうなライブラリーとして、taglib を検討してみた、ソースは C++ なんだけど、
かなり、昔の C++ って感じで、イマイチ感があったけど、他の候補を色々探して、検討するのも時間がかかりそう
なので、とりあえず、このライブラリーを使わせてもらう事にして、実装した。
なので、Windows でも、このライブラリーをコンパイルしてインストールする必要がある。
※taglib-1.9.1 を使った。

(2) OpenJPEG ライブラリー
macport でインストールした OpenJPEG ライブラリーは 2.1 で、API も少し違う為、Windows も 2.1 にアップ
デートした。

(3) JPEG ライブラリー
macport では、MMX で高速化した JPEG ライブラリーとして、libjpeg-turbo がある、またこのライブラリーは
若干の拡張がしてある。（Alpha チャネルを扱える）
そこで、Windows でもこのライブラリーを使いたいのだけど、コンパイルする為に、nasm が必要で、インストール
が複雑になるので、とりあえず、Windows では以前のライブラリーを使う事にした。
※アルファ付き画像をセーブした場合、アルファチャネルは無くなる。

(4) Makefile の改修
Windows では、Makefile を共有する事が難しい為、Makefile.win と別にした。
※この辺りも、cmake を使うとか、今後工夫が必要と思う。

以上の対応で、音楽プレイヤーは同等の動作をするようになった。

※最新版ソースコードは GitHub に push してある。

C++11 では標準ライブラリーでスレッド関係の API が用意されている。

future テンプレートクラスは、お手軽に、平行処理で結果を受け取る方法としてコンビニエンスなやり方だ。

std::string task_(const std::string in)
{
    std::string text;

    // 何かの処理・・・

    return text;
}

std::string in;

std::future<std::string> f = std::async(std::launch::async, task_, in);

こんな感じで、簡単に実行委譲が出来る。

------
最近、俺俺フレームワーク内で、音楽ファイルのタグ情報を future を使って取得する実装を書いた。
しかしながら、思ったようには動作せず、色々調べたり、実験を行った。

結論を言うと、これは、OS-X、clang の C++11 ライブラリーに起因した問題のように思う。

症状としては：
・メインプログラムから、future を使って、タスクを起動しても、メインプログラムが全然軽くならない・・・
※ future で起動したタスクは、メインプログラムの負荷として加算される感じ。
・フラグがあって、それで「別スレッド」を指定してもだ・・( std::async::lanuch )
※ Android でも試したが、そもそも「別スレッド」を指定出来ない（コンパイルエラーとなる）ので、これは正しい動作なのかもしれない。
※これは clang3.4 で使っているライブラリーの問題なのかもしれないが、情報は探せなかった。
※ Windows の gcc や clang では、C++11 thread API 関係が実装されていない事と何か関係がありそうだー

結局、pthread を使って、やりたい事は出来たのだが、「future 便利だー」って盛り上がってたのに・・
何ともかんとも・・・
※ C++11 にも thread 関係があるのだけど、future で懲りたので、あえて、pthread を使った、pthread でもそんなに複雑化せずに平行処理を書ける。
ただし、future を使った場合と比べると実装量は増えるが、厳密な処理負荷は、少ないだろう。
もうしばらくしたら、C++11 の thread を本格運用して試す事とする・・
※石橋を叩いて渡る〜

今まで、自分で細々と作っているフレームワークは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) {
        ...
    }

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

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