teppy のすべての投稿

privateメンバへ合法的にアクセス

2015年7月10日 teppy

プライベートは大切にしたいほうです。

このアーティクルを書いている今、個人的な話ですが仕事がデスマーチでプライベートなんてありません。

普段なら、この時期はプライベートジェットでサイパンに飛んで、プライベートビーチに寝転がってiPadでプライベートライアンを見ているはずです。

自分のプライベートが守られない今、他人のクラスのプライベートも守りません。積極的に攻めていくスタイルです。

// 従業員
class Employer {
    float time_for_game_;   // ゲームの時間
    float time_for_anime_;  // アニメの時間
    float time_for_family_; // 家族との時間
public:
    float time_for_work_; // 仕事の時間
};

// 従業員

class Employer {

float time_for_game_; // ゲームの時間

float time_for_anime_; // アニメの時間

float time_for_family_; // 家族との時間

public:

float time_for_work_; // 仕事の時間

};

雇われサラリーマンにも生活があります。

仕事の時間の他に自分の時間も必要なのです。そして、その部分というのは完全にプライベートなのです。

この従業員クラスをもうすこし価値のあるものにしてみましょう。

// 従業員　改訂版
class Employer {
    float time_for_game_;   // ゲームの時間
    float time_for_anime_;  // アニメの時間
    float time_for_family_; // 家族との時間
public:
    float time_for_work_; // 仕事の時間

    // 挨拶する　ハロー☆
    template <class Rank>
    void greet(Rank target) {
        std::cout << "hello" << std::endl;
    }
};

// 従業員　改訂版

class Employer {

float time_for_game_; // ゲームの時間

float time_for_anime_; // アニメの時間

float time_for_family_; // 家族との時間

public:

float time_for_work_; // 仕事の時間

// 挨拶する　ハロー☆

template <class Rank>

void greet(Rank target) {

std::cout << "hello" << std::endl;

}

};

挨拶できるようになりました。

しかも挨拶する対象の職位に応じて挨拶を変えられます。

例えば

// 社長にだけは挨拶じゃなくて休暇をせがむ
template<>
void Employer::greet(President target) {
    std::cout << "holiday please" << std::endl;   
}

// 社長にだけは挨拶じゃなくて休暇をせがむ

template<>

void Employer::greet(President target) {

std::cout << "holiday please" << std::endl;

}

社長の時だけは休暇をせがむようテンプレートを特殊化しました。

int main() {
   President takeda;
   Employer mami;
   Employer jun;
    
   jun.greet(mami);
   jun.greet(takeda);
   return 0;   
}

int main() {

President takeda;

Employer mami;

Employer jun;

jun.greet(mami);

jun.greet(takeda);

return 0;

}

出力:
hello
holiday please.

出力:

hello

holiday please.

では外部から、このEmployerのprivateメンバにアクセスしてゲームの時間をごっそり仕事の時間に移すことは可能でしょうか。

アクセス指定子の無効化というアーティクルの中で、privateメンバにもアクセスする術について記載しました。あれはC++の言語ルール的にはまったくの違法行為です。

privateというc++のキーワードを再定義してはいけません。

では合法的にやってみましょう。

// Employerが定義されているファイルをインクルードする
#include "employer.hpp"

// ↓↓ ここからがキモ
namespace {
class X{};
}
template <>
void Employer::greet(X target) {
    time_for_work_ += time_for_game_; // ゲームの時間を仕事の時間に足す
    time_for_game_ = 0; // ゲームの時間なんてゼロだ！
}
// ↑↑ ここまでがキモ

int main() {
    // ゲームの為の時間を表示
    Employer jun;
    jun.printTime();
    jun.greet(X());  // 勝手に特殊化したgreetを呼ぶ
    jun.printTime();
    return 0;
}

// Employerが定義されているファイルをインクルードする

#include "employer.hpp"

// ↓↓ ここからがキモ

namespace {

class X{};

}

template <>

void Employer::greet(X target) {

time_for_work_ += time_for_game_; // ゲームの時間を仕事の時間に足す

time_for_game_ = 0; // ゲームの時間なんてゼロだ！

}

// ↑↑ ここまでがキモ

int main() {

// ゲームの為の時間を表示

Employer jun;

jun.printTime();

jun.greet(X()); // 勝手に特殊化したgreetを呼ぶ

jun.printTime();

return 0;

}

出力
game 5 work 5
game 0 work 10

出力

game 5 work 5

game 0 work 10

メンバにテンプレート関数があると、外部でその関数の特殊化を行うことができます。これを利用して本来不可侵だったはずのprivateメンバの内容を意のままに書き換えました。

しかも、アクセス指定子の無効化と違い、今回のアプローチは合法です。特殊化したメンバ関数は、まったく議論の余地がない正式なクラスのメンバ関数ですのでｃ++の言語ルールに一切抵触していません。

この男は言語ルールの抜け道を知っている法律家だ。彼が捕まることは絶対にない。というのも、彼は法の精神を侵蝕する間も、注意深く条文に従っているからだ

＿＿Exceptional C++ Style アクセス制御の使用と誤用

このアプローチが法に触れそうになる瞬間、それは特殊化に使用した型が既に別の箇所で同様の特殊化に使われており、結果この関数定義がODRに違反する場合です。しかしそれも無名ネームスペースに定義したオリジナルの型を用いることにより簡単に回避することができます。

まとめ

あるクラスがテンプレートメンバ関数を持っている場合、内部情報に合法的にアクセスできる
ODR違反を回避する為に特殊化に使用する型は無名ネームスペース内で定義する
プライベートは大事

Language

テンプレートの特殊化

2015年6月9日 teppy

C++が他の数多ある言語と一線を画している特徴的な機能の一つにテンプレートという機構があります。

……と、書くと一部のクラスタから猛烈な抗議のメールを受け取ることになるので気をつけましょう。彼らはHaskellという一般の人には理解できない言語を日常的に使い、その特性にあるように完全に純粋で、自分たちを第一級オブジェクトとして扱う為、建設的な議論が困難です。

テンプレートの話に戻りましょう。

template <typename T>
T x2(const T& t) {
    return t * 2;
}

template <typename T>

T x2(const T& t) {

return t * 2;

}

受け取った値を倍にして返すだけの関数ですが、組み込み型のint, floatはもちろん、ユーザー定義の型であっても、適切に*(int)演算子が定義されていれば倍にして返してくれます。便利ですね。

一度コードを書くだけで、型毎に自動的に関数を生成してくれる為、非常に柔軟で楽チンですが、それでも万能ではありません。

特定の型の時だけ振る舞いを変えたい場合も出てきます。

例えば文字列に対して倍にするって何だ？みたいな話があるので、文字列型に対してx2が呼ばれた場合は、受け取った文字列を２回繰り返した文字列にして返すようにしてみましょう。

template<>
std::string x2(const std::string& t) {
    return t + t;
}

template<>

std::string x2(const std::string& t) {

return t + t;

}

std::stringを受け取った場合はこちらのx2が呼ばれます。

これをテンプレートの特殊化といいます。

この場合はx2()をstd::stringに対して特殊化しました。

int main() {
    int a = 3;
    std::cout << x2(a) << std::endl;
    float b = 4.0f;
    std::cout << x2(b) << std::endl;
    std::string c = "abc";
    std::cout << x2(c) << std::endl;
    return 0;   
}

int main() {

int a = 3;

std::cout << x2(a) << std::endl;

float b = 4.0f;

std::cout << x2(b) << std::endl;

std::string c = "abc";

std::cout << x2(c) << std::endl;

return 0;

}

[出力]
6
8
abcabc

[出力]

abcabc

まとめ

一部の型向けにテンプレート関数（or クラス）の実装を変えたい時はテンプレートの特殊化を行えばいい
Haskellerには注意
D言語界隈にも注意

Compiler

ブレークポイントコード

2015年5月28日 teppy

__asm int 3;

1	__asm int 3;

これを見てピンと来た人は何人いるだろうか。

ああ、x86系CPU環境でブレークポイントと同じ効果をもたらすアセンブラコードだなーと思った人。正解ですが本質的ではありません。

ああ、闇夜のc++とか言いながらついにネタ切れでc++の話以外を書き始めたなーと思った人。正解だし本質的です。

xcodeやVisual Studioで以下のコードを実行してみましょう。

#include <cstdio>

int main() {
    std::printf("abc");
    __asm int 3;
    std::printf("def");
    return 0;
}

#include <cstdio>

int main() {

std::printf("abc");

__asm int 3;

std::printf("def");

return 0;

}

int 3というアセンブラ命令はデバッガへのトラップ用の割り込みを発生させるので、5行目で勝手にデバッガがブレークします。

そこからステップトレースも、再実行も可能です。

マクロを作っておくと何かと便利です。

// 条件が成立したらブレークするブレークポイントマクロ
#define BREAKPOINT_IF(exp)   do {if (exp) {__asm int 3;} } while(0)

1 2	// 条件が成立したらブレークするブレークポイントマクロ #define BREAKPOINT_IF(exp) do {if (exp) {__asm int 3;} } while(0)

より汎用的に使うためにglibでは環境毎にマクロ定義を切り替えてます。

glibのgbacktrace.hを覗いてみましょう。

/**
 * G_BREAKPOINT:
 *
 * Inserts a breakpoint instruction into the code.
 *
 * On x86 and alpha systems this is implemented as a soft interrupt
 * and on other architectures it raises a <literal>SIGTRAP</literal> signal.
 */
#if (defined (__i386__) || defined (__x86_64__)) && defined (__GNUC__) && __GNUC__ >= 2
#  define G_BREAKPOINT()        G_STMT_START{ __asm__ __volatile__ ("int $03"); }G_STMT_END
#elif (defined (_MSC_VER) || defined (__DMC__)) && defined (_M_IX86)
#  define G_BREAKPOINT()        G_STMT_START{ __asm int 3h }G_STMT_END
#elif defined (_MSC_VER)
#  define G_BREAKPOINT()        G_STMT_START{ __debugbreak(); }G_STMT_END
#elif defined (__alpha__) && !defined(__osf__) && defined (__GNUC__) && __GNUC__ >= 2
#  define G_BREAKPOINT()        G_STMT_START{ __asm__ __volatile__ ("bpt"); }G_STMT_END
#else   /* !__i386__ && !__alpha__ */
#  define G_BREAKPOINT()        G_STMT_START{ raise (SIGTRAP); }G_STMT_END
#endif  /* __i386__ */

/**

* G_BREAKPOINT:

* Inserts a breakpoint instruction into the code.

* On x86 and alpha systems this is implemented as a soft interrupt

* and on other architectures it raises a <literal>SIGTRAP</literal> signal.

#if (defined (__i386__) || defined (__x86_64__)) && defined (__GNUC__) && __GNUC__ >= 2

# define G_BREAKPOINT() G_STMT_START{ __asm__ __volatile__ ("int $03"); }G_STMT_END

#elif (defined (_MSC_VER) || defined (__DMC__)) && defined (_M_IX86)

# define G_BREAKPOINT() G_STMT_START{ __asm int 3h }G_STMT_END

#elif defined (_MSC_VER)

# define G_BREAKPOINT() G_STMT_START{ __debugbreak(); }G_STMT_END

#elif defined (__alpha__) && !defined(__osf__) && defined (__GNUC__) && __GNUC__ >= 2

# define G_BREAKPOINT() G_STMT_START{ __asm__ __volatile__ ("bpt"); }G_STMT_END

#else /* !__i386__ && !__alpha__ */

# define G_BREAKPOINT() G_STMT_START{ raise (SIGTRAP); }G_STMT_END

#endif /* __i386__ */

環境依存ついでに、より環境依存な話をしておくとmsvc向けに__debugbreak();という命令もあります。やってることはint 3と一緒なので覚える必要はないでしょう。

環境依存なので3DS向けゲームの開発しかしてない人には無用の知識です。

まとめ

c++について書くことが思いつかなくなった
__asm int 3;はブレークポイント発生コード
マクロ化しておくと使い勝手がいい
汎用的な実装がglibで提供されている

Language

共変型の戻り値とオーバーライドルールの緩和

2015年5月25日 teppy

C++では、一般的に戻り値だけが異なるメソッドをオーバーライドすることはできません。

struct Base {
    virtual int func() = 0;
};

struct Derived : public Base {
    float func() override;   // エラー！戻り値型が違うぞ！
};

struct Base {

virtual int func() = 0;

};

struct Derived : public Base {

float func() override; // エラー！戻り値型が違うぞ！

};

引数が違えば別関数と扱われ、単にメソッドが増えるだけなのですが、引数が同じ場合はオーバーライド対象なので、このコードはコンパイルエラーとなります。

ただし、戻り値の型が異なっていても、その型が共変型であるならばコンパイルエラーにはなりません。

オーバーライドする仮想関数の戻り値の型は、オーバーライド元の関数のものと同じか、または「共変（covariant）」でなければならない。

＿＿C++ランゲージクイックリファレンス

……聞き慣れないですね。

要するに「戻り値の型がクラス型の参照かポインタで、かつis-a関係にあるもの」に関しては親クラスと異なる型の戻り値であってもオーバーライドできますよっていう話です。

例を見てみましょう。

何はともあれ、まずはis-a関係を持つ型を用意します。

struct Shape {};

// Shapeとis-a関係にあるBox
struct Box : public Shape {};

struct Shape {};

// Shapeとis-a関係にあるBox

struct Box : public Shape {};

先ほどのエラーになったオーバーライドの例の戻り値に今定義した型ShapeとBoxを指定します。

struct Base {
    virtual Shape* get() = 0;
};

struct Derived : public Base {
    Box* get() override; // こんどは戻り値の型が共変なのでOK! 
};

struct Base {

virtual Shape* get() = 0;

};

struct Derived : public Base {

Box* get() override; // こんどは戻り値の型が共変なのでOK!

};

コンパイルは通りますが、共変型を持つメソッドはオーバーライドの挙動が通常のオーバーライドと異なるので注意が必要です。

以下のプログラムでは結果として”shape”と表示されます。

#include <iostream>

// Shapeを定義
struct Shape {
    void print() {
        printf("shape");
    }
};
// Shapeから継承したBoxを定義
struct Box : public Shape {
    void print() {
        printf("box");
    }
};


struct Base {
    virtual ~Base(){}
    virtual Shape* get() = 0;
};

struct Derived : public Base {
    // 純粋仮想関数getをオーバーライドしてBox*を返す
    // 基底クラスと戻り値の型が違うけど共変型なのでOK
    Box* get() override {
        return new Box();
    }
};

int main() {
    Base* b = new Derived; // Derived生成
    auto a = b->get();　// ポリモーフィックにget()を呼び出す
    a->print(); // Boxって表示されるかな？
    delete b;
    return 0;   
}

#include <iostream>

// Shapeを定義

struct Shape {

void print() {

printf("shape");

}

};

// Shapeから継承したBoxを定義

struct Box : public Shape {

void print() {

printf("box");

}

};

struct Base {

virtual ~Base(){}

virtual Shape* get() = 0;

};

struct Derived : public Base {

// 純粋仮想関数getをオーバーライドしてBox*を返す

// 基底クラスと戻り値の型が違うけど共変型なのでOK

Box* get() override {

return new Box();

}

};

int main() {

Base* b = new Derived; // Derived生成

auto a = b->get();　// ポリモーフィックにget()を呼び出す

a->print(); // Boxって表示されるかな？

delete b;

return 0;

}

Wandboxで確認

Boxと表示されそうな気がしますが、実際にはshapeと表示されます。

ただし、ここが超重要なのですが、Shape*を返してもb->get()は決してBase::get()の呼び出しでは無いということです。

ポリモーフィズムの挙動に準じて、あくまでDerived::get()が呼び出されますが、操作しているポインタbの型次第で、Derived::get()で指定した型Box*のまま戻り値が返されるか、Base::get()で指定した型に暗黙に変換された後、返されるかという挙動の違いが発生します。

慣れないとちょっと分かりづらいですね。

むしろ結構分かりづらいですね。

ひょっとしたらC++の挙動の中でトップレベルの分かりづらさかもしれないですね。

一応、共変型に対してオーバーライドのルールが緩和される為、純粋仮想関数による子クラスへの関数定義の強制のメリットと実際に取得する型が親クラスに引っ張られないメリットを享受できる……ということになっています。

自分自身の型を返す関数を定義する時など、親クラス固定だと、受け取った側でのキャストが面倒ですしね。

共変型の戻り値には、常に適切な抽象レベルで作業できるという利点があります。(中略)共変型の戻り値を使用すれば、ミスを誘いがちなキャストを使用したために、そもそも失うはずの無かった型情報を再度提供するはめになることもありません。

＿＿C++標準的コーディング技法#31 戻り値の共変型

まとめ

戻り値の型が違うメソッドはオーバーライドできません
ただし共変型の場合のみこのルールが緩和される
操作している型のタイプによって戻り値の型は暗黙に変換される
型が暗黙に変換されるだけで関数の呼び出し自体はポリモーフィック

Coding Tech

Pimplイディオム

2015年5月18日 teppy

オブジェクト指向の重要な概念のひとつに「カプセル化」というものがあります。

隠蔽化とも呼ばれ、ある機能を使いたい時に、ユーザーが実装詳細を意識しなくても動作し、ある日、実装の内容がドラスティックに変更されても、ユーザーは特に何もしなくても昨日までと同じようにその機能を使い続けられるということを期待するものです。

適切なカプセル化の思想の元に設計されたコードは変更に対して柔軟です。

あなたが学生時代に書いた、擬似乱数を生成するオブジェクトMyRandは昨日まで線形合同法で実装されていました。しかし、今日、急に思い立って擬似乱数の生成方法をxorshiftに変更したとしても、MyRandオブジェクトを使う側はその変更によって呼び出しコードを修正する必要はありません。

※この話はカルドセプトサーガおよび株式会社ロケットスタジオとは一切関係ありません。（http://www26.atwiki.jp/gcmatome/pages/2574.html）

クラスの実装を呼び出し側から完全に分離し、隠蔽する手法にPimplイディオムというものがあります。

通常、クラス設計では公開するヘッダーファイルの定義の中にpublicからprivateまでの定義をひととおり書きます。

class PasswordChecker{
public:  // 公開
    PasswordChecker();
    ~PasswordChecker();

public:
    bool check(const char* const pass);

private: // 非公開
    int makeCRC();

private:
    char pass_[16];
    int crc_;
};

class PasswordChecker{

public: // 公開

PasswordChecker();

~PasswordChecker();

public:

bool check(const char* const pass);

private: // 非公開

int makeCRC();

private:

char pass_[16];

int crc_;

};

このクラスにメンバを足したり減らしたり、またはコメントを追加したり、何かしら変更を加えると、このクラスを使う（＝ヘッダーファイルをインクルードしている）箇所全てが再コンパイルの対象になります。ライブラリの深いところのクラスをちょっと書き換えただけなのにフルビルドコースという話は決して珍しくありません。

また、ユーザーはクラスの公開されている部分にしか基本的にはアクセスできませんが、非公開関数のインターフェースとメンバ変数の詳細は見えています。

ああ、パスワードは最大16文字なんだな、とかCRC使ってるんだなとかの情報が読み取れてしまいますね。本例は多少作為的ですが、それでも外部に提供するクラスライブラリ等、なるべく情報を出したくないケースもあります。

データサイズとデータのレイアウトが想像できると、通信パケットやメモリダンプから情報を抜きやすくなってしまいますからね。これはもう圧倒的に抜かれます。

「公開されている部分にしか基本的にはアクセスできません」と書きましたが、基本的じゃない場合、その気になればメンバ変数pass_にも一瞬でアクセスできます。
→アクセス指定子の無効化

クラス編集による再ビルドの影響範囲をなるべく抑えたい時やプライベートメンバをユーザーが見れる状況が好ましくない場合、Pimplイディオムを使ってクラスの実装を呼び出し側から完全に分離しましょう。

Pimplイディオム実装方法

ヘッダーファイル側の定義ではprivateメンバを書くのではなく内部実装の為のクラスのポインタのみ持ちます。

#include <memory>

class PasswordChecker {
public:  // 公開
    PasswordChecker();
    ~PasswordChecker();

public:
    bool check(const char* const pass);

private: // 非公開
    class Impl;
    std::unique_ptr<Impl> impl_;
};

#include <memory>

class PasswordChecker {

public: // 公開

PasswordChecker();

~PasswordChecker();

public:

bool check(const char* const pass);

private: // 非公開

class Impl;

std::unique_ptr<Impl> impl_;

};

そして.cpp側でImplの詳細を定義することで実装を完全にヘッダーファイルから分離できます。

#include "password_checker.hpp"

class PasswordChecker::Impl {
    //
    // 実装に必要な定義をつらつらと書く
};

PasswordChecker::PasswordChecker()
    : impl_(new Impl) // 実装クラスを生成
{}

#include "password_checker.hpp"

class PasswordChecker::Impl {

// 実装に必要な定義をつらつらと書く

};

PasswordChecker::PasswordChecker()

: impl_(new Impl) // 実装クラスを生成

{}

impl_経由で処理を呼び出します。

bool PasswordChecker::check(const char* const pass) {
    return impl_->check(pass);
}

bool PasswordChecker::check(const char* const pass) {

return impl_->check(pass);

}

ちなみにPimplはピーインプルと読まれることが多く、Pointer To ImplementationやPrivate Implementationの意味で使われます。

Pimplイディオムは実装の詳細が分離できてコンパイル時間の減少にも貢献できる代償として、処理を呼び出す際にipml_を経由する過程で間接参照が必ず一回入るので、その分のオーバーヘッドのコストが発生する点だけ認識しておいてください。あと実際問題として、クラスの実装が委譲だらけになるので書くのが手間です。

まとめ

Pimplイディオムを使うとクラスの定義と実装を完全に分離できる
Pimplイディオムはコンパイル時間の抑制になる
Pimplイディオムには間接参照のオーバーヘッドが発生する

Coding Tech

アクセス指定子の無効化

2015年5月16日 teppy

世の中には知っていても「ほとんど悪にしかならない」知識があります。

例えば、簡易爆弾の作り方や、内鍵を糸だけで開ける方法などです。

さて、ここに誰かが定義したクラスがあります。

//  someone_defined.hpp
class SomeoneDefined {
    void private_func();
protected:
    void protected_func();
public:
    void public_func();
};

// someone_defined.hpp

class SomeoneDefined {

void private_func();

protected:

void protected_func();

public:

void public_func();

};

このクラスを使う側はpublic_func()しか呼べません。当たり前です。

#include "someone_defined.hpp"

int main() {
    SomeoneDefined sd;
    sd.public_func();    // OK
    sd.private_func();   // Error!!! プライベートメンバだぞ！
    return 0;
}

#include "someone_defined.hpp"

int main() {

SomeoneDefined sd;

sd.public_func(); // OK

sd.private_func(); // Error!!! プライベートメンバだぞ！

return 0;

}

private_func()にアクセスするにはどうすればいいでしょうか。

色々考えられます。

このクラスの設計者の家に押しかけてアクセスレベルの変更を迫るのも有力な手段です。また、我々はプログラマなので、お気に入りのエディタ（例えばEmacs）でおもむろにsomeone_defined.hppを開き、内容を勝手に書き換えてしまうのも悪くありません。

もっと（C++使い的に）スマートな方法もあります。

someone_defined.hppの内容を一切書き換えることなく、SomeoneDefinedクラスの内容に好きなだけアクセスする方法。

こちらを御覧ください。

#define class struct       // classをstructに！
#define protected public   // protectedをpublicに！

#include "someone_defined.hpp"

#undef protected
#undef class


int main() {
    SomeoneDefined sd;
    sd.public_func();    // OK
    sd.private_func();   // OK
    sd.protected_func(); // OK
    return 0;
}

#define class struct // classをstructに！

#define protected public // protectedをpublicに！

#include "someone_defined.hpp"

#undef protected

#undef class

int main() {

SomeoneDefined sd;

sd.public_func(); // OK

sd.private_func(); // OK

sd.protected_func(); // OK

return 0;

}

はい、一丁上がりです。

someone_defined.hppは自分が何をされたのか気づいてすらいません。

この手法を悪ではなく正義の為に活かしましょう。（そんなものはない）

この悪魔のような手法からアナタの大切なクラスを守る方法はPimplイディオムを使って、完全に内部実装を隠蔽することです。

あと、悪魔には悪魔払いを！というわけで、こういう魔のモノを拒絶する方法もあります。

#if !defined(protected) && !defined(private) && !defined(class) // 悪魔払い
#ifndef HOGE_H_INCLUDED // 通常のインクルードガード
#define HOGE_H_INCLUDED

// ヘッダーの内容を書く

#endif // HOGE_H_INCLUDED
#endif // 悪魔払い

#if !defined(protected) && !defined(private) && !defined(class) // 悪魔払い

#ifndef HOGE_H_INCLUDED // 通常のインクルードガード

#define HOGE_H_INCLUDED

// ヘッダーの内容を書く

#endif // HOGE_H_INCLUDED

#endif // 悪魔払い

怪しいマクロを定義しているヤツにはインクルードさせてやらねーよ！ということですね。

ただし開発業務は進まなくなります。

まとめ

アクセスレベルは簡単に書き換えられる
この知識との上手な付き合い方は単に使わないこと
防衛策はPimplイディオム

おまけ

このprivateを再定義するアプローチは厳密にはc++のルールに違反している（c++のキーワードを再定義している）ので、本来何がおこっても不思議ではありません。たまたま無効化できているといったところです。

ちなみにある条件の下では、c++のルールに違反せずprivateメンバにアクセスする方法もあります。

参照：privateメンバへ合法的にアクセス

Compiler

ローカルな文字列テーブル

2015年5月7日 teppy

関数内で使うローカルな文字列テーブル（配列）の定義には注意が必要です。

１月～１２月までの月を数値で渡すと、英語の文字列を取得できる関数monthToEnglishを作ってみましょう。

例．第一引数に５を渡すとMayという文字列が第二引数のバッファに格納される

#include <cstring>

constexpr int BUF_SIZE = 32;

void monthToEnglish(
    int month,
    char* buf
) {
    const char* MONTH_ENGLISH_TABLE[12] = {
        "January",
        "February",
        "March",
        "April",
        "May",
        "June",
        "July",
        "August",
        "September",
        "October",
        "November",
        "December",
    };
    std::strncpy(buf, MONTH_ENGLISH[month-1], BUF_SIZE);
}

int main() {
    char buf[BUF_SIZE];
    monthToEnglish(3, buf);
    return 0;
}

#include <cstring>

constexpr int BUF_SIZE = 32;

void monthToEnglish(

int month,

char* buf

) {

const char* MONTH_ENGLISH_TABLE[12] = {

"January",

"February",

"March",

"April",

"May",

"June",

"July",

"August",

"September",

"October",

"November",

"December",

};

std::strncpy(buf, MONTH_ENGLISH[month-1], BUF_SIZE);

}

int main() {

char buf[BUF_SIZE];

monthToEnglish(3, buf);

return 0;

}

無事、完成しました。

有効範囲のエラー処理など細かい部分は端折ってますが適切な値を渡す限りは要件に見合った挙動をします。

さてこの関数ですが、大いなる無駄処理が走る可能性があります。

最適化を有効にした上で、アセンブラを見てみましょう。

g++ main.cpp -S -std=c++11 -O3

1	g++ main.cpp -S -std=c++11 -O3

41行目～に注目です。

	.file	"main.cpp"
	.section .rdata,"dr"
.LC0:
	.ascii "January\0"
.LC1:
	.ascii "February\0"
.LC2:
	.ascii "March\0"
.LC3:
	.ascii "April\0"
.LC4:
	.ascii "May\0"
.LC5:
	.ascii "June\0"
.LC6:
	.ascii "July\0"
.LC7:
	.ascii "August\0"
.LC8:
	.ascii "September\0"
.LC9:
	.ascii "October\0"
.LC10:
	.ascii "November\0"
.LC11:
	.ascii "December\0"
	.text
	.p2align 4,,15
	.globl	_Z14monthToEnglishiPc
	.def	_Z14monthToEnglishiPc;	.scl	2;	.type	32;	.endef
	.seh_proc	_Z14monthToEnglishiPc
_Z14monthToEnglishiPc:
.LFB1213:
	subq	$104, %rsp
	.seh_stackalloc	104
	.seh_endprologue
	leaq	.LC0(%rip), %rax
	movl	$32, %r8d
	movq	%rdx, %r9
	movq	%rax, (%rsp)
	leaq	.LC1(%rip), %rax
	movq	%rax, 8(%rsp)
	leaq	.LC2(%rip), %rax
	movq	%rax, 16(%rsp)
	leaq	.LC3(%rip), %rax
	movq	%rax, 24(%rsp)
	leaq	.LC4(%rip), %rax
	movq	%rax, 32(%rsp)
	leaq	.LC5(%rip), %rax
	movq	%rax, 40(%rsp)
	leaq	.LC6(%rip), %rax
	movq	%rax, 48(%rsp)
	leaq	.LC7(%rip), %rax
	movq	%rax, 56(%rsp)
	leaq	.LC8(%rip), %rax
	movq	%rax, 64(%rsp)
	leaq	.LC9(%rip), %rax
	movq	%rax, 72(%rsp)
	leaq	.LC10(%rip), %rax
	movq	%rax, 80(%rsp)
	leaq	.LC11(%rip), %rax
	movq	%rax, 88(%rsp)
	movslq	%ecx, %rax
	movq	%r9, %rcx
	movq	(%rsp,%rax,8), %rdx
	addq	$104, %rsp
	jmp	strncpy
	.seh_endproc
	.def	__main;	.scl	2;	.type	32;	.endef
	.section	.text.startup,"x"
	.p2align 4,,15
	.globl	main
	.def	main;	.scl	2;	.type	32;	.endef
	.seh_proc	main
main:
.LFB1214:
	subq	$72, %rsp
	.seh_stackalloc	72
	.seh_endprologue
	call	__main
	leaq	32(%rsp), %rdx
	movl	$3, %ecx
	call	_Z14monthToEnglishiPc
	xorl	%eax, %eax
	addq	$72, %rsp
	ret
	.seh_endproc
	.p2align 4,,15
	.def	_GLOBAL__sub_I__Z14monthToEnglishiPc;	.scl	3;	.type	32;	.endef
	.seh_proc	_GLOBAL__sub_I__Z14monthToEnglishiPc
_GLOBAL__sub_I__Z14monthToEnglishiPc:
.LFB1234:
	subq	$40, %rsp
	.seh_stackalloc	40
	.seh_endprologue
	leaq	_ZStL8__ioinit(%rip), %rcx
	call	_ZNSt8ios_base4InitC1Ev
	movq	.refptr.__dso_handle(%rip), %r8
	leaq	_ZStL8__ioinit(%rip), %rdx
	leaq	_ZNSt8ios_base4InitD1Ev(%rip), %rcx
	addq	$40, %rsp
	jmp	__cxa_atexit
	.seh_endproc
	.section	.ctors,"w"
	.align 8
	.quad	_GLOBAL__sub_I__Z14monthToEnglishiPc
.lcomm _ZStL8__ioinit,1,1
	.ident	"GCC: (GNU) 4.9.2"
	.def	strncpy;	.scl	2;	.type	32;	.endef
	.def	_ZNSt8ios_base4InitC1Ev;	.scl	2;	.type	32;	.endef
	.def	_ZNSt8ios_base4InitD1Ev;	.scl	2;	.type	32;	.endef
	.def	__cxa_atexit;	.scl	2;	.type	32;	.endef
	.section	.rdata$.refptr._ZNSt8ios_base4InitD1Ev, "dr"
	.globl	.refptr._ZNSt8ios_base4InitD1Ev
	.linkonce	discard
.refptr._ZNSt8ios_base4InitD1Ev:
	.quad	_ZNSt8ios_base4InitD1Ev
	.section	.rdata$.refptr.__dso_handle, "dr"
	.globl	.refptr.__dso_handle
	.linkonce	discard
.refptr.__dso_handle:
	.quad	__dso_handle

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

.file "main.cpp"

.section .rdata,"dr"

.LC0:

.ascii "January\0"

.LC1:

.ascii "February\0"

.LC2:

.ascii "March\0"

.LC3:

.ascii "April\0"

.LC4:

.ascii "May\0"

.LC5:

.ascii "June\0"

.LC6:

.ascii "July\0"

.LC7:

.ascii "August\0"

.LC8:

.ascii "September\0"

.LC9:

.ascii "October\0"

.LC10:

.ascii "November\0"

.LC11:

.ascii "December\0"

.text

.p2align 4,,15

.globl _Z14monthToEnglishiPc

.def _Z14monthToEnglishiPc; .scl 2; .type 32; .endef

.seh_proc _Z14monthToEnglishiPc

_Z14monthToEnglishiPc:

.LFB1213:

subq $104, %rsp

.seh_stackalloc 104

.seh_endprologue

leaq .LC0(%rip), %rax

movl $32, %r8d

movq %rdx, %r9

movq %rax, (%rsp)

leaq .LC1(%rip), %rax

movq %rax, 8(%rsp)

leaq .LC2(%rip), %rax

movq %rax, 16(%rsp)

leaq .LC3(%rip), %rax

movq %rax, 24(%rsp)

leaq .LC4(%rip), %rax

movq %rax, 32(%rsp)

leaq .LC5(%rip), %rax

movq %rax, 40(%rsp)

leaq .LC6(%rip), %rax

movq %rax, 48(%rsp)

leaq .LC7(%rip), %rax

movq %rax, 56(%rsp)

leaq .LC8(%rip), %rax

movq %rax, 64(%rsp)

leaq .LC9(%rip), %rax

movq %rax, 72(%rsp)

leaq .LC10(%rip), %rax

movq %rax, 80(%rsp)

leaq .LC11(%rip), %rax

movq %rax, 88(%rsp)

movslq %ecx, %rax

movq %r9, %rcx

movq (%rsp,%rax,8), %rdx

addq $104, %rsp

jmp strncpy

.seh_endproc

.def __main; .scl 2; .type 32; .endef

.section .text.startup,"x"

.p2align 4,,15

.globl main

.def main; .scl 2; .type 32; .endef

.seh_proc main

main:

.LFB1214:

subq $72, %rsp

.seh_stackalloc 72

.seh_endprologue

call __main

leaq 32(%rsp), %rdx

movl $3, %ecx

call _Z14monthToEnglishiPc

xorl %eax, %eax

addq $72, %rsp

ret

.seh_endproc

.p2align 4,,15

.def _GLOBAL__sub_I__Z14monthToEnglishiPc; .scl 3; .type 32; .endef

.seh_proc _GLOBAL__sub_I__Z14monthToEnglishiPc

_GLOBAL__sub_I__Z14monthToEnglishiPc:

.LFB1234:

subq $40, %rsp

.seh_stackalloc 40

.seh_endprologue

leaq _ZStL8__ioinit(%rip), %rcx

call _ZNSt8ios_base4InitC1Ev

movq .refptr.__dso_handle(%rip), %r8

leaq _ZStL8__ioinit(%rip), %rdx

leaq _ZNSt8ios_base4InitD1Ev(%rip), %rcx

addq $40, %rsp

jmp __cxa_atexit

.seh_endproc

.section .ctors,"w"

.align 8

.quad _GLOBAL__sub_I__Z14monthToEnglishiPc

.lcomm _ZStL8__ioinit,1,1

.ident "GCC: (GNU) 4.9.2"

.def strncpy; .scl 2; .type 32; .endef

.def _ZNSt8ios_base4InitC1Ev; .scl 2; .type 32; .endef

.def _ZNSt8ios_base4InitD1Ev; .scl 2; .type 32; .endef

.def __cxa_atexit; .scl 2; .type 32; .endef

.section .rdata$.refptr._ZNSt8ios_base4InitD1Ev, "dr"

.globl .refptr._ZNSt8ios_base4InitD1Ev

.linkonce discard

.refptr._ZNSt8ios_base4InitD1Ev:

.quad _ZNSt8ios_base4InitD1Ev

.section .rdata$.refptr.__dso_handle, "dr"

.globl .refptr.__dso_handle

.linkonce discard

.refptr.__dso_handle:

.quad __dso_handle

MONTH_ENGLISH_TABLEはこの関数が呼び出される度にスタック上にコピーされます。ちなみにconst を constexprに変えても出力結果は同じです。

スタック上に値を生成したいという目的が無いのならば、このコードはこの関数が呼ばれる度にただただ不要な処理を走らせることになるのであまりよろしくありません。

例えばテクスチャ名のリスト、モーション名のリスト、気軽にローカルで定義することは良くあるかと思います。

そういう時に、gcc 4.9.2 で -O3ですら、前述のような（プログラマの意図に対して）無駄な処理が走ることは覚えておく価値があると思います。

この問題は定義にstaticを付けることで簡単に回避できます。

static const char* MONTH_ENGLISH_TABLE[12] = {
    "January",
    "February",
    "March",
    "April",
    "May",
    "June",
    "July",
    "August",
    "September",
    "October",
    "November",
    "December",
};

static const char* MONTH_ENGLISH_TABLE[12] = {

"January",

"February",

"March",

"April",

"May",

"June",

"July",

"August",

"September",

"October",

"November",

"December",

};

この場合のアセンブラコードを見てみましょう。

	.file	"main.cpp"
	.text
	.p2align 4,,15
	.globl	_Z14monthToEnglishiPc
	.def	_Z14monthToEnglishiPc;	.scl	2;	.type	32;	.endef
	.seh_proc	_Z14monthToEnglishiPc
_Z14monthToEnglishiPc:
.LFB1213:
	.seh_endprologue
	movl	$32, %r8d
	movq	%rdx, %r9
	leaq	_ZZ14monthToEnglishiPcE19MONTH_ENGLISH_TABLE(%rip), %rdx
	movslq	%ecx, %rax
	movq	%r9, %rcx
	movq	(%rdx,%rax,8), %rdx
	jmp	strncpy
	.seh_endproc
	.def	__main;	.scl	2;	.type	32;	.endef
	.section	.text.startup,"x"
	.p2align 4,,15
	.globl	main
	.def	main;	.scl	2;	.type	32;	.endef
	.seh_proc	main
main:
.LFB1214:
	subq	$72, %rsp
	.seh_stackalloc	72
	.seh_endprologue
	call	__main
	xorl	%eax, %eax
	addq	$72, %rsp
	ret
	.seh_endproc
	.p2align 4,,15
	.def	_GLOBAL__sub_I__Z14monthToEnglishiPc;	.scl	3;	.type	32;	.endef
	.seh_proc	_GLOBAL__sub_I__Z14monthToEnglishiPc
_GLOBAL__sub_I__Z14monthToEnglishiPc:
.LFB1234:
	subq	$40, %rsp
	.seh_stackalloc	40
	.seh_endprologue
	leaq	_ZStL8__ioinit(%rip), %rcx
	call	_ZNSt8ios_base4InitC1Ev
	movq	.refptr.__dso_handle(%rip), %r8
	leaq	_ZStL8__ioinit(%rip), %rdx
	leaq	_ZNSt8ios_base4InitD1Ev(%rip), %rcx
	addq	$40, %rsp
	jmp	__cxa_atexit
	.seh_endproc
	.section	.ctors,"w"
	.align 8
	.quad	_GLOBAL__sub_I__Z14monthToEnglishiPc
	.section .rdata,"dr"
.LC0:
	.ascii "January\0"
.LC1:
	.ascii "February\0"
.LC2:
	.ascii "March\0"
.LC3:
	.ascii "April\0"
.LC4:
	.ascii "May\0"
.LC5:
	.ascii "June\0"
.LC6:
	.ascii "July\0"
.LC7:
	.ascii "August\0"
.LC8:
	.ascii "September\0"
.LC9:
	.ascii "October\0"
.LC10:
	.ascii "November\0"
.LC11:
	.ascii "December\0"
	.align 64
_ZZ14monthToEnglishiPcE19MONTH_ENGLISH_TABLE:
	.quad	.LC0
	.quad	.LC1
	.quad	.LC2
	.quad	.LC3
	.quad	.LC4
	.quad	.LC5
	.quad	.LC6
	.quad	.LC7
	.quad	.LC8
	.quad	.LC9
	.quad	.LC10
	.quad	.LC11
.lcomm _ZStL8__ioinit,1,1
	.ident	"GCC: (GNU) 4.9.2"
	.def	strncpy;	.scl	2;	.type	32;	.endef
	.def	_ZNSt8ios_base4InitC1Ev;	.scl	2;	.type	32;	.endef
	.def	_ZNSt8ios_base4InitD1Ev;	.scl	2;	.type	32;	.endef
	.def	__cxa_atexit;	.scl	2;	.type	32;	.endef
	.section	.rdata$.refptr._ZNSt8ios_base4InitD1Ev, "dr"
	.globl	.refptr._ZNSt8ios_base4InitD1Ev
	.linkonce	discard
.refptr._ZNSt8ios_base4InitD1Ev:
	.quad	_ZNSt8ios_base4InitD1Ev
	.section	.rdata$.refptr.__dso_handle, "dr"
	.globl	.refptr.__dso_handle
	.linkonce	discard
.refptr.__dso_handle:
	.quad	__dso_handle

100

101

102

103

104

105

106

107

.file "main.cpp"

.text

.p2align 4,,15

.globl _Z14monthToEnglishiPc

.def _Z14monthToEnglishiPc; .scl 2; .type 32; .endef

.seh_proc _Z14monthToEnglishiPc

_Z14monthToEnglishiPc:

.LFB1213:

.seh_endprologue

movl $32, %r8d

movq %rdx, %r9

leaq _ZZ14monthToEnglishiPcE19MONTH_ENGLISH_TABLE(%rip), %rdx

movslq %ecx, %rax

movq %r9, %rcx

movq (%rdx,%rax,8), %rdx

jmp strncpy

.seh_endproc

.def __main; .scl 2; .type 32; .endef

.section .text.startup,"x"

.p2align 4,,15

.globl main

.def main; .scl 2; .type 32; .endef

.seh_proc main

main:

.LFB1214:

subq $72, %rsp

.seh_stackalloc 72

.seh_endprologue

call __main

xorl %eax, %eax

addq $72, %rsp

ret

.seh_endproc

.p2align 4,,15

.def _GLOBAL__sub_I__Z14monthToEnglishiPc; .scl 3; .type 32; .endef

.seh_proc _GLOBAL__sub_I__Z14monthToEnglishiPc

_GLOBAL__sub_I__Z14monthToEnglishiPc:

.LFB1234:

subq $40, %rsp

.seh_stackalloc 40

.seh_endprologue

leaq _ZStL8__ioinit(%rip), %rcx

call _ZNSt8ios_base4InitC1Ev

movq .refptr.__dso_handle(%rip), %r8

leaq _ZStL8__ioinit(%rip), %rdx

leaq _ZNSt8ios_base4InitD1Ev(%rip), %rcx

addq $40, %rsp

jmp __cxa_atexit

.seh_endproc

.section .ctors,"w"

.align 8

.quad _GLOBAL__sub_I__Z14monthToEnglishiPc

.section .rdata,"dr"

.LC0:

.ascii "January\0"

.LC1:

.ascii "February\0"

.LC2:

.ascii "March\0"

.LC3:

.ascii "April\0"

.LC4:

.ascii "May\0"

.LC5:

.ascii "June\0"

.LC6:

.ascii "July\0"

.LC7:

.ascii "August\0"

.LC8:

.ascii "September\0"

.LC9:

.ascii "October\0"

.LC10:

.ascii "November\0"

.LC11:

.ascii "December\0"

.align 64

_ZZ14monthToEnglishiPcE19MONTH_ENGLISH_TABLE:

.quad .LC0

.quad .LC1

.quad .LC2

.quad .LC3

.quad .LC4

.quad .LC5

.quad .LC6

.quad .LC7

.quad .LC8

.quad .LC9

.quad .LC10

.quad .LC11

.lcomm _ZStL8__ioinit,1,1

.ident "GCC: (GNU) 4.9.2"

.def strncpy; .scl 2; .type 32; .endef

.def _ZNSt8ios_base4InitC1Ev; .scl 2; .type 32; .endef

.def _ZNSt8ios_base4InitD1Ev; .scl 2; .type 32; .endef

.def __cxa_atexit; .scl 2; .type 32; .endef

.section .rdata$.refptr._ZNSt8ios_base4InitD1Ev, "dr"

.globl .refptr._ZNSt8ios_base4InitD1Ev

.linkonce discard

.refptr._ZNSt8ios_base4InitD1Ev:

.quad _ZNSt8ios_base4InitD1Ev

.section .rdata$.refptr.__dso_handle, "dr"

.globl .refptr.__dso_handle

.linkonce discard

.refptr.__dso_handle:

.quad __dso_handle

見違えるほどスッキリしました。

このように、関数ローカルな場所に文字列テーブルを作る時は呼吸をするようにstaticを付けるというプラクティスは悪くありません。

まとめ

ローカルな文字列テーブルの定義は無駄なコストが生じる可能性がある
ローカルな文字列テーブルにはstaticをつけよう

Language

do-while(0)によるマクロラッピング

2015年5月1日 teppy

inline関数やconst変数を使ってもC言語時代に#defineマクロによって実現していたことの全てをカバーできるわけではありません。

今でもCPP(C Pre Processor)の力は偉大です。

特に、ビルドレベルに応じて違う挙動になるような処理を実現するには#defineによるマクロは有効な選択です。

以下のような要件を満たすマクロを考えてみましょう

開発中のみ有効
ある条件を与えて結果が偽ならログ出力

#ifdef _DEBUG
  #define DEBUG_LOG(exp, ...)  do {if (!(exp)){std::printf(__VA_ARGS__);}} while(0)
#else
  #define DEBUG_LOG(exp, ...)  do {(void)(exp);} while(0)
#endif

#ifdef _DEBUG

#define DEBUG_LOG(exp, ...) do {if (!(exp)){std::printf(__VA_ARGS__);}} while(0)

#else

#define DEBUG_LOG(exp, ...) do {(void)(exp);} while(0)

#endif

以下のように使います。

int main() {
    int x = 99;
    DEBUG_LOG(x > 100,"warning! x = %d", x); // xが100以下だったら警告を表示
    return 0;
}

int main() {

int x = 99;

DEBUG_LOG(x > 100,"warning! x = %d", x); // xが100以下だったら警告を表示

return 0;

}

DEBUG_LOGの定義を見て下さい。

マクロで展開したい実際の処理(std::printf)をdo{…}while(0)で囲んでます。

これはどういう意図でしょうか。

do{…}while(0)としたところで、内部のステートメントは１度しか実行されません。

do-while(0)の部分を省いて

#define DEBUG_LOG(exp,...)   if ((!exp)){std::printf(__VA_ARGS__)}

1	#define DEBUG_LOG(exp,...) if ((!exp)){std::printf(__VA_ARGS__)}

と書くのと処理的には何も変わらないように見えます。

しかし実際には後者の定義は

行末の；（セミコロン）を強制できない
記述する場所によっては意図しない挙動になる
ビルドレベルによって記述できる箇所が変わる

という３点の理由により全く不十分なのです。

順番に見てみましょう。

1.行末の；（セミコロン）を強制できない

do-while(0)じゃないバージョンでは行末の;（セミコロン）を強制できません。

int main() {
    int x = 99;
    if (!(x > 100)) {
        std::printf("warning! x = %d", x);
    }
    return 0;
}

int main() {

int x = 99;

if (!(x > 100)) {

std::printf("warning! x = %d", x);

}

return 0;

}

このように展開されるのでセミコロンが無くてもc++のシンタックス上は問題の無いコードになります。(3-5行目)

しかしエディタ上での見た目は

int main() {
    int x = 99;
    DEBUG_LOG(x > 100,"warning! x = %d", x) //←セミコロン無し
    return 0;
}

int main() {

int x = 99;

DEBUG_LOG(x > 100,"warning! x = %d", x) //←セミコロン無し

return 0;

}

となります。これはc++のシンタックスに準じていないし、コード全体の一貫性も欠くことになります。しかし、そう書けてしまうというのは使う側ではなく、定義した側の責任です。

2.記述する場所によっては意図しない挙動になる

このマクロがブロック無しif文の直後で呼ばれた時に意図しない挙動になります。

if (p)
    DEBUG_LOG(x > 100, "warning!");
else
    p = nullptr;

if (p)

DEBUG_LOG(x > 100, "warning!");

else

p = nullptr;

ブロック無しif文なんて書くな、カッコ悪いぞ！っていう話ではあるのですが、こう書いた時に以下のように展開されます。

if (p)
    if (!(x > 100)) {
        std::printf("warning!");
    }
    else
        p = nullptr;

if (p)

if (!(x > 100)) {

std::printf("warning!");

}

else

p = nullptr;

if (p)と対だったはずのelse節がマクロから展開された方のif文との対になってしまいました。

これも使う側ではなく、定義した側の責任です。

do-whileで囲んだ最初の定義だと以下のように展開されます。

if (p)
    do {
        if (!(x > 100)) {
            std::printf("warning");
        }
    } while(0);
else
   p = nullptr;

if (p)

do {

if (!(x > 100)) {

std::printf("warning");

}

} while(0);

else

p = nullptr;

3.ビルドレベルによって記述できる箇所が変わる

マクロが展開を展開した時にシンタックスエラーになるケースが変わります。

DEBUG_LOG(x > 100, "warning!")
else {
    //// なんか処理
}

DEBUG_LOG(x > 100, "warning!")

else {

//// なんか処理

}

if文だけのマクロの場合はこのような書式がc++的に許されてしまいます。

しかもデバッグビルド時は問題無いのに、いざリリースしようとするとコンパイルエラーになってしまいます。

同じことが非デバッグ時のDEBUG_LOGの定義にも言え、例えば((void)0)を書かずに、展開結果をただ空白にしてしまうと、非デバッグビルド時には、どこにでも記述できるというマクロになってしまいます。

#else
  // リリース時には何にも展開されない
  #define DEBUG_LOG(exp, ...)
#endif

#else

// リリース時には何にも展開されない

#define DEBUG_LOG(exp, ...)

#endif

int main(DEBUG_LOG(1)) {
    return DEBUG_LOG(0) 0;
}

int main(DEBUG_LOG(1)) {

return DEBUG_LOG(0) 0;

}

このように書いてもエラーになりません。

マクロはc++のシンタックスを無視して、どこにでも記述できてしまいます。どこにでも記述させたい明確な理由が無い場合、このような記述はできるべきではありませんし、そもそもデバッグビルド時と記述可能箇所のルールが変わってしまいます。

ビルドレベルによって記述可能箇所のルールが変わるのは、単に分かりづらい上に、ビルドレベルを変えたタイミングで、初めてコーディングのミスに気づくことになるので効率も悪いです。

どういうスキルレベルのプログラマに使われても不具合が起こりにくくなるように、可能な限り、紛れの無いコーディングを促すような設計を心がけましょう。

まとめ

展開された時に意図しない挙動になるのを防ぐ為、マクロをdo-while(0)でくくるのは良いプラクティス
ビルドレベルが変わってもマクロを展開できる箇所には一貫性をもたせるべき

Language

非public継承の使いどころ

2015年4月29日 teppy

継承には３つのレベルがあります。

public
protected
private

オブジェクト指向的な考え方ではpublic継承はよくis-a関係を表すなどと言われたりしますね。

どら焼き is a 和菓子。

ベジータ is a サイヤ人。

B is a A（びーいずあえー）という関係なのでis-a関係です。

一方、private継承、protected継承はis-a関係ではありません。

is-a関係との対比でhas-a関係、またはis-implemented-in-terms-of関係なんて呼ばれたりします。

public継承以外はB is a Aの関係では無いため、AのポインタにBを代入することはできません。

class A {};
class B : A {};

int main() {
    A* = new B;   // エラー！cannot cast 'B' to its private base class 'A'
    return 0;
}

class A {};

class B : A {};

int main() {

A* = new B; // エラー！cannot cast 'B' to its private base class 'A'

return 0;

}

基底クラスのポインタへの代入を許すのはpublic継承だけです。

public継承以外の継承では基底クラスのメンバへは内部からしかアクセスできません。ですので、あるクラスをprivate継承していようが、メンバとしてもっていようが、Bというクラスの実装の詳細の為に内部でAの機能を使うという状態は実際のところ変わりません。

つまり、あるクラスの持つ機能を使いたい場合には

メンバとして持つ
継承する

という２つの選択肢があります。

基本的に継承はコードの複雑性を増すので避けられるなら避けた方が望ましいとされています。できるだけコンポジション（内包）を使って実装する方が良いでしょう。

それでも継承を使って実装するシチュエーションはなんでしょうか？

１つには、EBO(Empty Base Optimization)が効くケースがあるという点が挙げられます。これはメモリ効率の観点からすると大きなアドバンテージとなります。

２つ目は、あなたがライブラリの設計者で、自作するクラスBは、Aというクラスの仮想関数をオーバーライドして何かしたいけど、ユーザーには自分の作ったクラスをAのポインタとして管理させたくない。という場合です。何を言っているのでしょうか。

#include <iostream>

// もともとあったクラスA
class A {
public:
    void do3() { // do()を3回呼ぶメソッド
        do();
        do();
        do();
    }
    // この関数をオーバーライドして好きな挙動にすればいいさ
    virtual void do() {
        std::cout << "A-do" << std::endl;   
    }
};

// クラスAの実装を一部カスタマイズして実装したいB
class B : A {
public:
    void do3() {
        A::do3();
    }
private:
    // doの新しい挙動はこれだ！
    void do() override {
        std::cout << "B-do" << std::endl;
    }
};


int main() {
    B b;
    b.do3();
    return 0;
}

#include <iostream>

// もともとあったクラスA

class A {

public:

void do3() { // do()を3回呼ぶメソッド

do();

}

// この関数をオーバーライドして好きな挙動にすればいいさ

virtual void do() {

std::cout << "A-do" << std::endl;

}

};

// クラスAの実装を一部カスタマイズして実装したいB

class B : A {

public:

void do3() {

A::do3();

}

private:

// doの新しい挙動はこれだ！

void do() override {

std::cout << "B-do" << std::endl;

}

};

int main() {

B b;

b.do3();

return 0;

}

これで画面には”B-do”と３回表示されます。

あまり実用性を感じない例ですが、あるクラスの一部の挙動をオーバーライドでカスタマイズしたい場合は継承するしかありません。このようなケースは本来ならpublic継承でいいのですが、なんらかの理由（基底クラスのデストラクタがvirtualになっていない等）で基底クラスのポインタによる管理を許さない設計にしたい場合は前述のとおり、public継承しないことで実現できます。

STLのコンテナは全てデストラクタがvirtualではありません。ですのでこれらのクラスを拡張した便利コンテナクラスを作成したい場合も絶対にpublic継承してはいけません。とはいえ、例えばstd::vectorの拡張クラスを作りたい時に、std::vectorをメンバとして持つと、std::vectorの持つメソッドを全て再実装しなければいけないという手間が発生します。

上記のようなケースでは継承とusingを組み合わせることで実装がシンプルになります。

template <typename T>
class MyVector 
    : private std::vector<T, std::allocator<T>> { // STLコンテナは絶対public継承してはダメです
public:
    using std::vector<T>::push_back; // usingでpush_backのアクセスレベルをpublicに引き上げる
};

int main() {
    MyVector<int> v;
    v.push_back(99); // private継承したvectorのpush_backにアクセスできる
    return 0;
}

template <typename T>

class MyVector

: private std::vector<T, std::allocator<T>> { // STLコンテナは絶対public継承してはダメです

public:

using std::vector<T>::push_back; // usingでpush_backのアクセスレベルをpublicに引き上げる

};

int main() {

MyVector<int> v;

v.push_back(99); // private継承したvectorのpush_backにアクセスできる

return 0;

}

boost::noncopyableはデータを持たないクラスなのでEBOが効き、さらにデストラクタがvirtualではないので、private継承にうってつけの例と言えます。

まとめ

public継承以外は基底クラスのポインタへの代入はできない
デストラクタがvirtualではないクラスは絶対public継承してはいけない
継承ではなく内包で実装できる時はなるべくそうしたほうが良い
非public継承すべき時は特殊だが存在するので、c++の挙動を正しく理解して判断する

Language

virtualの伝播

2015年4月27日 teppy

このBoxクラスをpublic継承しても安全でしょうか？

class Box : public Object {
public:
    Box();
    ~Box();
};

class Box : public Object {

public:

Box();

~Box();

};

正解は……この情報だけでは何とも言えない。でした。

一見するとダメっぽいと感じる人も多いかと思います。特にc++のことをちょっと詳しくなった頃の人はまずデストラクタに目が行くかと思います。

デストラクタの前にvirtualが付いていませんね。virtualで無いデストラクタは継承してはいけないということはc++で最初に学ぶことの一つです。

もう少し情報を足して、Objectクラスの定義も見てみましょう。

class Object {
public:
    virtual ~Object();
};

class Object {

public:

virtual ~Object();

};

シンプルです。

virtualが定義されたデストラクタが定義されている模様です。

これではっきりしました。Boxはpublic継承しても安全です。

「Boxをpublic継承しても安全」という表現をもっと詳しく書くと「Boxを継承したクラスをnewで生成して、そのポインタをBox,もしくはObjectのポインタに入れて、deleteを呼んでも安全」ということです。

class MyBox : public Box {
public:
    MyBox();
    ~MyBox();
};

int main() {
   
    Box* box = new MyBox;
    delete box;  // OK 問題なくMyBoxのデストラクタが呼ばれる

    Object obj = new MyBox;
    delete obj;  // OK これも問題なくMyBoxのデストラクタが呼ばれる

    return 0;
}

class MyBox : public Box {

public:

MyBox();

~MyBox();

};

int main() {

Box* box = new MyBox;

delete box; // OK 問題なくMyBoxのデストラクタが呼ばれる

Object obj = new MyBox;

delete obj; // OK これも問題なくMyBoxのデストラクタが呼ばれる

return 0;

}

Objectクラスのデストラクタにvirtualが付いているので、Objectをpublic継承している全てのクラスのデストラクタは暗黙にvirtual指定が付きます。

C++では基底クラスでvirtualで定義されたメソッドは、派生先でも、もれなくvirtualになります。

class Super{
public:
    Super(){}
    virtual ~Super(){}

public:
    virtual void func1() {}
    virtual void func2() {};
    virtual void func3() = 0;
};

class Sub : public Super {
public:
    Sub() {}
    ~Sub(){}  // これは暗黙にvirtual
public:
    void func1() {}; // これも暗黙にvirtual
    void func2() {}; // これも暗黙にvirtual
    void func3() {}; // これも暗黙にvirtual
};

class Super{

public:

Super(){}

virtual ~Super(){}

public:

virtual void func1() {}

virtual void func2() {};

virtual void func3() = 0;

};

class Sub : public Super {

public:

Sub() {}

~Sub(){} // これは暗黙にvirtual

public:

void func1() {}; // これも暗黙にvirtual

void func2() {}; // これも暗黙にvirtual

void func3() {}; // これも暗黙にvirtual

};

一昔前は派生先のメソッドにvirtualをつけることで、継承元のメソッドをオーバーライドしてますよ的なことを匂わせるアプローチもありましたが今はc++11から追加されたoverrideキーワードがあるのでそちらを使いましょう。

class Super{
public:
    Super(){}
    virtual ~Super(){}

public:
    virtual void func1() {}
    virtual void func2() {};
    virtual void func3() = 0;
};

class Sub : public Super {
public:
    Sub() {}
    ~Sub(){}
public:
    void func1() override {} // オーバーライドしたことが明快
    void func2() override {} // オーバーライドしたことが明快
    void func3() override {} // オーバーライドしたことが明快
    void func4() override {} // エラー！基底クラスにないメソッド名！
};

class Super{

public:

Super(){}

virtual ~Super(){}

public:

virtual void func1() {}

virtual void func2() {};

virtual void func3() = 0;

};

class Sub : public Super {

public:

Sub() {}

~Sub(){}

public:

void func1() override {} // オーバーライドしたことが明快

void func2() override {} // オーバーライドしたことが明快

void func3() override {} // オーバーライドしたことが明快

void func4() override {} // エラー！基底クラスにないメソッド名！

};

オーバーライドしている意思が明確になり、より可読性の高いコードとなります。また、メソッド名を間違えたりしても、今までは間違った名前で新しいメソッドが作られるだけで不具合の温床になっていましたが、overrideキーワードの恩恵で、基底クラスに無いメソッド名を指定した場合はエラーにしてくれます。素敵ですね！

まとめ

基底クラスでvirtualだったものは派生先では勝手にvirtualになる
オーバーライドを明示するためにc++11から追加されたoverrideキーワードを使おう