間が開いてしまいましたが、前回のEASTLをビルドするで「次回以降」と書いた2点の補足をします。

1つ目は、/Zl (既定ライブラリ名の省略)の使用です。

これはEASTLのLIBを使用するEXEまたはDLLのプロジェクトで、ランタイムにDLL版を使うか静的ライブラリ版を使うか（/MD, /MT, /MDd, /MTdの選択）に関係なくEASTLのLIBを使用できるようにするためです。/Zlを使用しない場合、LIB (EASTL)のプロジェクトとそれを使用するプロジェクトで/MD, /MT, /MDd, /MTdのどれを使うか統一する必要があり不便です。

もちろん、DLLか静的リンクか、あるいはデバッグ版を使用するか否かで、LIBに変化を加える必要がある場合は、/Zlを使用すべきではありません。しかし、EABaseとEASTLはそうではないと判断し、/Zlを使用することとしました。

2つ目は、Visual C++ 2010でのchar16_t問題です。

元のコード（take-cheeze/EASTLのコード）でコメントに書かれている方法は、Visual C++ 2010のヘッダにあるchar16_tなどのtypedefの定義を抑止して、EABaseのtypdefを使用するというものです。これの問題は、「EABaseのヘッダをインクルードしたファイルとそうでないファイルとでchar16_tの定義が異なる」という点です。

たとえば、次の2ファイルをコンパイル・リンクすると、fが見つからないというリンクエラーになります。

1
2
3
4

// A.cpp
#include <EABase/eabase.h>
 
void f(char16_t) {}
1
2
3
4
5
6
7
8
9

// B.cpp
#include <yvals.h>
 
void f(char16_t);
 
int main()
{
  f(0);
}

この問題を回避するには、すべてのファイルで同じchar16_tの定義を使うしかありません。それゆえ、私はEABaseでもyvals.hのchar16_tの定義を使用する方法（EA_COMPLER_IS_CPLUSPLUS_0Xを定義する）をおすすめすることとしました。

もちろん、EABaseのtypedefを使用する方法にも利点はあります。char16_tをwchar_tのtypedefとしているので、ワイド文字列リテラルL”string”をchar16_tに対して使用できると言うことです。私の方法では、char16_t const* p = reinterpret_cast<char16_t const*>(L”string”);としなければならず、大変面倒です。

無論、「EASTLをビルドする」のエントリで書いたように、char16_tがコンパイラ組込型になってu”string”文字列リテラルが使えればこんなに悩む必要ないのですけどね。

スポンサード リンク

この記事のカテゴリ

  • ⇒ 「EASTLをビルドする」の補足