A10 ロードバランサを運用する前に覚えておきたいポイント

A10のAXシリーズを運用するうえで必要な最低限の知識をまとめておく。

※同様の機能を提供する機器としてはBIG-IPが有名だろう。

◆ コマンド

※enableモードへの移行は省略している

【機器情報】

● バージョン、その他機器情報の確認

# show version

【作業、障害時操作】

● ActiveかStandbyかの確認

# show ha

● Active/Standby切り替え

ActiveかStandbyかはプロンプトにも表示される。

コマンドはactive側で実施する。

# configure

(config)# ha force-self-standby

● Active/Standbyの切り戻し

切り戻しはStandby側で先の設定を無効にし、

(config)# no ha force-self-standby

切り替わった新active側で再度下のコマンドをを実施する。
(config)# ha force-self-standby

● リアルサーバの組み込み

# configure

(config)# slb server $リアルサーバ名

(config-real server)# enable

● リアルサーバの切り離し

# configure
(config)# slb server $リアルサーバ名
(config-real server)# disable

● コネクション数変更

# configure

(config)# slb server $リアルサーバ名

(config-real server)# conn-limit XXXX

【リソース】

●  各DataCPUコア毎に利用率を表示

# show cpu

●  メモリ利用率を表示

# show memory system

【トラフィック】

● バーチャルサーバ単位での負荷分散ステータスを表示

# show slb virtual-server

※extended-stats キーを入れておかないと過去の統計(最大のトラフィックetc)は見れない

ヘルスチェックのステータス確認にはbindオプションをつけた方が分かりやすい

# show slb virtual-server bind

● サービスグループ単位での負荷分散ステータスを表示

# show slb service-group

● サーバ単位での負荷分散ステータスを表示

# show slb server

● サーバヘルスチェックステータス表示

# show health stat

● インターフェイスのステータスと各種カウンタの表示

# show statistics interface

● SLBセッションのサマリ表示

# show session brief

● パーシステンステーブルの表示

# show session persist src-ip / dst-ip

パーシステンステーブルを削除することもできる。
テーブルを初期化することでトラフィックの偏りなども均質にできる可能性がある。
# clear session persist src-ip / dst-ip

● Arpテーブル表示

# show arp

● MACテーブル表示

# show mac

● IP FIBテーブルを表示

# show ip fib

● IP Rougingテーブル(RIB)を表示

# show ip route

● L2/3 パケット処理のステータス表示

# show slb switch

【コンフィグ】

● コンフィグレーション確認

# show startup-config

# show running-config

● 保存

# write memory

● コンフィグレーション同期

active側で実施する。
(config)# ha sync all to-running-config

(config)# ha sync all to-startup-config

【デバッグ】

● AXのディスク上の保存されたシステムログの表示

# show log

● その時点のシステム、プロセス関連のステータス情報のスナップショットを出力

# show techsupport

● 本体温度、FAN、電源の状態を確認

# show environment

● ログ情報の保存

# backup log ftp://*.*.*.*/ax_backup.tgz

User name []? ****

Password []? ****

※アップロードを行うプルトコルはtftp, ftp, scp, rcp が可能

● パケットキャプチャ

モードを変更する。

# axdebug

キャプチャｓするfilterを定義する(絞り込みたい)場合の設定

(axdebug)# filter 1

(axdebug-filter:1)# ip 1.2.3.4 /32

キャプチャするパケット数の定義

ax(axdebug)# count <0-65535>

※デフォルトは3000 パケットまで。0 で設定上の上限なし

キャプチャ時間の定義

(axdebug)# timeout <0-65535>

※分単位で設定。デフォルト5分。0 で設定上の上限なし

キャプチャの開始

(axdebug)# capture non-dispaly save <file name>

キャプチャの状態確認

(axdebug)# show axdebug status

キャプチャファイルの確認

(axdebug)#show axdebug file

キャプチャの停止

(axdebug)# no axdebug

キャプチャファイルのエクスポート

(axdebug)# export axdebug file_name ?

use-mgmt-port Use management port as source port

tftp: Remote file path of tftp: file system(Format: tftp://host/file)

ftp: Remote file path of ftp: file system(Format: ftp://[user@]host[:port]/file)

scp: Remote file path of scp: file system(Format: scp://[user@]host/file)

rcp: Remote file path of rcp: file system(Format: rcp://[user@]host/file)

※キャプチャファイルはpcap形式でZIP圧縮された状態でエクスポート

キャプチャファイルの削除

(axdebug)# delete <file_name>

◆ 設定変更

【white, blackリストの更新】

接続元のIPアドレスを元に振り分けるサーバを
制御している場合もあるだろう。
そのIPリスト更新する手順を残しておく。

ここではslb template policy内で以下のように定義しているとする。

ip_list(名前はip_list_oldとする)であるのIPアドレス群を管理し、
接続元IPアドレスがそのリスト内でマッチしたら、
http_matchグループへ飛ばす。

slb template policy bwlist_http
   bw-list name ip_list_old
   bw-list id 1 service-group http_match
  (略)

このIPリストを以下のように更新する。
変更前：ip_list_old
変更前：ip_list_new


1. IPリストのインポート
事前に任意のサーバにIPリストは配置しておくこと。

IPリスト例
network x.x.x.0/24 1
network y.y.y.0/24 1
network z.z.z.0/24 1
※最後の数字はtemplateのpolicy内で指定したbw-listのidである。

# import bw-list ip-list_new scp://<ID>@<サーバアドレス>/<パス>/<リスト名>


2. IPリストの確認
# show bw-list
適用しているi-listが表示される

# show bw-list ip-list_new detail
※GUIでは仕様上、全行が表示されない為、CLIから確認すること


3. IPリストの更新
ip_list_newに入れ替える。
コマンド実行直後から新しいIPリストが適用される。
# conf terminal
(config)# slb template policy bwlist_http
bw-list name ip_list_new


4.不要なIPリストの削除
# conf terminal
(config)# no bw-list ip_list_old

実際は切り戻しのため最低1世代前は残し、2世代前のものを削除する、
などの方針のほうがよいだろう。


5.コンフィグ保存


6．コンフィグ同期
同期をとる前に2点注意がある。
・peer機器でも上記手順1(IPリストのインポート)を実施しておくこと
・また、IPリスト名は両機器で揃えておくこと

◆ 障害発生時TRAP内容

● trap内容

発報メッセージ OID

レベル CRITICAL
axSystemShutdown                .1.3.6.1.4.1.22610.2.4.3.12.2.1.2
axFan1Failure                   .1.3.6.1.4.1.22610.2.4.3.12.2.1.4
axFan2Failure                   .1.3.6.1.4.1.22610.2.4.3.12.2.1.5
axFan3Failure                   .1.3.6.1.4.1.22610.2.4.3.12.2.1.6
axUpperPowerSupplyFailure       .1.3.6.1.4.1.22610.2.4.3.12.2.1.9
axLowerPowerSupplyFailure       .1.3.6.1.4.1.22610.2.4.3.12.2.1.10
axPrimaryHardDiskFailure        .1.3.6.1.4.1.22610.2.4.3.12.2.1.11
axSecondaryHardDiskFailure      .1.3.6.1.4.1.22610.2.4.3.12.2.1.12
axSystemRestart                 .1.3.6.1.4.1.22610.2.4.3.12.2.1.15
axHAStandby                     .1.3.6.1.4.1.22610.2.4.3.12.2.2.1
axServerDown                    .1.3.6.1.4.1.22610.2.4.3.12.2.2.6
axServiceDown                   .1.3.6.1.4.1.22610.2.4.3.12.2.2.4
axVirtualServerPortDown         .1.3.6.1.4.1.22610.2.4.3.12.2.2.12

レベル NOTICE
axSystemTempHigh                .1.3.6.1.4.1.22610.2.4.3.12.2.1.3
axHardDiskUsageHigh             .1.3.6.1.4.1.22610.2.4.3.12.2.1.13
axMemoryUsageHigh               .1.3.6.1.4.1.22610.2.4.3.12.2.1.14
axSystemDropPacketEvent         .1.3.6.1.4.1.22610.2.4.3.12.2.1.16
axSystemControlCpuHigh          .1.3.6.1.4.1.22610.2.4.3.12.2.1.18
axSystemDataCpuHigh             .1.3.6.1.4.1.22610.2.4.3.12.2.1.19
axHAActive                      .1.3.6.1.4.1.22610.2.4.3.12.2.2.2
axHAActiveActive                .1.3.6.1.4.1.22610.2.4.3.12.2.2.3
axServerConnLimit               .1.3.6.1.4.1.22610.2.4.3.12.2.2.8
axServiceConnLimit              .1.3.6.1.4.1.22610.2.4.3.12.2.2.10
axServerConnRateLimit           .1.3.6.1.4.1.22610.2.4.3.12.2.2.19
axServiceConnRateLimit          .1.3.6.1.4.1.22610.2.4.3.12.2.2.20
axNetworkTrunkPortsThreshold    .1.3.6.1.4.1.22610.2.4.3.12.2.3.1
axApplicationBufferReachLimit   .1.3.6.1.4.1.22610.2.4.3.12.2.2.14
axVirtualServerReachConnLimit   .1.3.6.1.4.1.22610.2.4.3.12.2.2.17
axVirtualServerPortReachConnLimit       .1.3.6.1.4.1.22610.2.4.3.12.2.2.15
axVirtualServerPortReachConnRateLimit   .1.3.6.1.4.1.22610.2.4.3.12.2.2.16
axVirtualServerReachConnRateLimit       .1.3.6.1.4.1.22610.2.4.3.12.2.2.18

レベル INFO
axSystemStart                   .1.3.6.1.4.1.22610.2.4.3.12.2.1.1
axSystemRelieveDropPacketEvent  .1.3.6.1.4.1.22610.2.4.3.12.2.1.17
axServiceUp                     .1.3.6.1.4.1.22610.2.4.3.12.2.2.5
axServerUp                      .1.3.6.1.4.1.22610.2.4.3.12.2.2.7
axServerConnResume              .1.3.6.1.4.1.22610.2.4.3.12.2.2.9
axServiceConnResume             .1.3.6.1.4.1.22610.2.4.3.12.2.2.11
axVirtualServerPortUp           .1.3.6.1.4.1.22610.2.4.3.12.2.2.13

◆ 統計情報取得用mib

【トラフィック】

● axVirtualServerStatTable

Get the virtual server statistics table.

axVirtualServerStatName

.1.3.6.1.4.1.22610.2.4.3.4.2.1.1.2

axVirtualServerStatCurConns

.1.3.6.1.4.1.22610.2.4.3.4.2.1.1.9

● axServiceGroupStatTable

Get the service group statistics table. This table shows statistics for service groups.

axServiceGroupStatName

.1.3.6.1.4.1.22610.2.4.3.3.2.1.1.1

axServiceGroupStatCurConns

.1.3.6.1.4.1.22610.2.4.3.3.2.1.1.7

● axServiceGroupMemberStatTable

Get the service group member statistics table.

axServiceGroupMemberStatName

.1.3.6.1.4.1.22610.2.4.3.3.4.1.1.1

axServiceGroupMemberStatCurConns

.1.3.6.1.4.1.22610.2.4.3.3.4.1.1.11

【ディスク】

● axSysDiskTotalSpace

Get the total amount of space on the AX hard disk. The space is measured in Megabytes (MB).

.1.3.6.1.4.1.22610.2.4.1.4.1

● axSysDiskFreeSpace

Get the amount of hard disk space that is currently free (unused). The space is measured in MB.

.1.3.6.1.4.1.22610.2.4.1.4.2

【プロセッサ】

● axSysAverageControlCpuUsage

Description Gets the average control CPU utilization over the last 5 seconds.

.1.3.6.1.4.1.22610.2.4.1.3.4

● axSysAverageDataCpuUsage

Description Gets the average data CPU utilization over the last 5 seconds.

.1.3.6.1.4.1.22610.2.4.1.3.5

【メモリ】

● axSysMemoryTotal

Get the total amount of memory on the system. Memory is measured in Kilobytes(Kb).

.1.3.6.1.4.1.22610.2.4.1.2.1

● axSysMemoryUsage

Get the amount of memory that is currently in use. Memory is measured in Kb.

.1.3.6.1.4.1.22610.2.4.1.2.2

C++利用時のコーディング規約

C++を利用する時には自分なりのコーディング規約、ルールを決めておくべきである。
統一したポリシーを決めておかないと一人で書いていても、
コードの修正もリーディングも後々困難になる。
Google C++スタイルガイド 日本語訳も大変参考になる。
ここでは上記に含まれていない点を中心にまとめる。


◆◆◆ 命名規則
コード内の命名規則を決めておく。

● クラス名
最初の一文字目は大文字。

名詞を使う傾向がある。
ただし、抽象クラスは形容詞をつける傾向がある。
(例) Observable


● メソッド、関数名
動詞を当てはめる傾向がある。

Yes/Noのクエリの回答を行う場合は、
Is、Are、Hasといった接頭辞をつける。
(例) IsEnabled()、HssChildren()
否定系は使わない。
(例) IsUnabled()

メソッドではなく自由関数の場合は、
アクションを適用する対象のオブジェクト名を含める。
(例) FileOpen()


● クラス内のメンバ(フィールド)名
"m" + 頭だけ大文字の一文字
(例) mVar


● 配列変数名
配列名は複数形にする。

【例】
book → books
child → children

newした場合にdeleteなのか、delete[]なのかで間違いが起こりにくい。


● ヘッダで利用するインクルードガード名
大文字で記す
#include HOGE_EXAMPLE

名前異空間を使っている場合とそうではない場合には気をつけること。
Hoge::Example
HogeExample

それぞれを区別できるようにしておく。
#include HOGE_EXAMPLE
#include HOGEEXAMPLE
とする。



◆◆◆ 用意しておきたいマクロ
● 0ポインタ
deleteする場合は必ず0を代入する。
目的は、deleteしたポインタを間違って利用しないためである。
0にしておけばアクセスした瞬間に落ちる。
他の値では無効な値でも動き続ける可能性がある。
デストラクタ内であれば変数は後処理され見えなくなるため不要ではと反論もあるだろう。
delete後もnewによって再利用され、new時点での値が残っている可能性はある。

#define SAFE_DELETE(x) { delete (x); (x) = 0; }

改行を入れるならこうだ。
# define SAFE_DELETE(x) {\
  delete(x);\
  (x) = 0;\
}

配列版も用意する。
#define SAFE_DELETE_ARRAY(x) { delete[] (x); (x) = 0; }

上記を適当なヘッダファイルに記載しておき、
利用するccファイルでincludeしてやればいいだろう。

利用例

T** array = new T*[n];
for (int i=0; i<n; ++i) {
  array[i] = new T();
}

for (int i=0; i<n; ++i) {
  SAFE_DELETE(array[i]);
}

SAFE_DELETE_ARRAY(array);



◆◆◆ new/deleteポリシー
newされた変数はそのクラスが責任を持って
デストラクタ時にdeleteする。

T::~T() {
  SAFE_DELETE(mHoge1);
}

newしたものを渡すときは例外とし、
渡された側がdeleteする。またその旨をコメントしておく。



◆◆◆ メンバ初期化
コンストラクタ時にはメンバをすべて初期化(メンバイニシャライザ)する。
メンバイニシャライザの方が、普通に代入によって初期値を与えるよりも効率的であるためである。
すべての変数の初期化が手間であっても最低限、ポインタ変数は必ず実施し、初期化されていないことによる不可解なバグを回避する。

T::T():
  mX(0),
  mY(0),
  mZ(0) {
  ～
};


例えば下でinitを呼ぶ前にset()を呼んだらどうなるか。
mXは不定である。

class T {
  T() {}
  void init() {
    mX = new int();
  }
  void set(int a) {
    *mX = a;
  }
};

初期値を()で囲むのは、各メンバのコンストラクタを呼んでいるためである。
つまり()の中の値は、コンストラクタに引数を与えていることになる。
int型などの言語に標準で用意されている型(プリミティブ型・基本型などと呼ぶ)であっても、
コンストラクタが存在しているということが推測できる。



◆◆◆ 継承を使う場合の基本設計
● どこで使うか
以下のメリットがある場合に限る。
① 共通部分のくくりだしにより抽象化された全体の性質を見せる時。
　例えば、人というスーパークラス(基底)があれば、
　男や女のサブクラス(派生)の性差の違いは別にして男や女が
　ある程度イメージできる。

②　サブクラス(派生)とスーパークラス(基底)がis-aの関係になる時。
　共通部分のくくりだしだけに注目して継承関係を結んではならない。
　
　ただし、is-aの関係にあっても、
　リスコフの置換原則(LSP:Liskov Substitution Principle)には
　従はなければならない。
　LSPとは、SがTの派生型であれば、つまりこう、
　　T(スーパークラス)
　　S(サブクラス)
　T型のオブジェクトが使われている箇所は全て
　S型のオブジェクトで置換可能。

　以下のような継承関係はis-aであってもLSPに反する。
　　T(スーパークラス): Ellipse
　　S(サブクラス): Circle
　こういった場合は、合成を利用すべきである(holds-aの関係である)。
　合成では相手クラスのパブリックメンバのみに結合するだけである。

③ スーパークラスだけしか知らなくてもいい人に、サブクラスを隠せる時。
　人の機能を使いたい場合に男か女かどうかは知る必要はない、ということである。

④ 繰り返しを避けられる時。


● 継承時のトラブル対策
やってしまいがちなトラブルを防ぐためのポリシーを決める。
【概要】
① スパークラス(基底クラス)をnewさせない

② 継承時のdelete忘れ


【詳細】
①
Parentをスパークラス、Childがサブクラスとする

Parent *parent = new Child;
これはあっても、

Parent *parent = new Parent;
このような使い方はしない。
スーパークラスのポインタを通してサブクラスの関数を呼ぶために、
継承させているのである。

ただ、親側をnewすることを機械的に防ぎたい。

親側の関数を子側で再定義し使用する(オーバライドする)ことを
前提として仮想関数として利用する際に、
仮想化させるvirtual付の関数に=0をつけることもできる。
=0をつけた仮想関数は純粋仮想関数というのだが、クラスはnewできなくなる。
これでうっかりミスは防止できる。
1個でもこれがあるクラスを抽象クラスという。

class Parent {
  public:
  virtual void play() = 0; //中身は持たせない
};


②
スーパークラスのデストラクタにvirtualを付与して仮想関数にして、
継承時のdelete忘れを防止する。
ただし、デストラクタは=0をつけない(純仮想関数にはしない)。

失敗例
Parent* parent = new Child;
delete parent;

Parentのデストラクタしか呼ばれない。
Child内でnewしていた場合は、
Childのデストラクタも呼ばなければならない。

そこで、デストラクタも仮想関数にしてやる。
class Parent {
  public:
  virtual void play() = 0;
  virtual ~Parent() = default;
};
デストラクタに0をつけないのは、親側のデストラクタは中身を持つからである。
スーパークラスのデストラクタにvirtualは必須とすればよい。
子側のデストラクタを呼ぶと親側のデストラクタも呼ばれる。



◆◆◆ 内部でnewするクラスの基本設計
内部でnewするクラスの実体のコピーを防止するために、
コピーコンストラクタと代入演算子は禁止する。
実体を引数にする場合、STLコンテナに入れる場合(これに関しては別観点で後述する)はどうすればよいか。
その時はポインタを使う。

class T {
  private:
  T(const T&); // コピーコンストラクタの禁止
  void operator=(const T&); // 代入演算子の禁止

  public:
  T() {mX = new int();}
  ~T() {delete mX;}
};

しかしながらクラスごとに記載するのは手間がかかる。
以下のようなマクロをprivate内で使うと便利である。

#define DISALLOW_COPY_AND_ASSIGN(TypeName) \
  TypeName(const TypeName&);               \
  void operator=(const TypeName&)

class T {
 public:
  T(int f);
  ~T();

 private:
  DISALLOW_COPY_AND_ASSIGN(T);
};



◆◆◆ ポインタ配列と実体配列の使い分け
【どちらを使うべきか】
① ポインタを入れる場合(普通はこうだろう)
T** array = new T*[n];


② 実体を入れる場合
T* array = new T[n];


【性能面からの比較】
①では1個ずつnewしなくてはならない。
毎回newし、その数だけdeleteも必要になってくる。
T** array = new T*[n];
for (int i=0; i<n; ++i) {
  array[i] = new T();
}

for (int i=0; i<n; ++i) {
  SAFE_DELETE(array[i]);
}

SAFE_DELETE_ARRAY(array);


②ではnewは一度だけでよい。
T* array = new T[n];
for(int i=0; i<n; ++i) {
  array[i].initialize();
}

SAFE_DELETE_ARRAY();

ディフォルトのコンストラクタしか呼び出せないため、
initialize()というような(名前はなんでもよい)初期化用の
メソッドを作り読みこませる必要はある。
コンストラクタとは別に初期化関数を呼ぶ手間がかかるが、
newの回数も減り破棄するコードも短くなる。


性能面だけを考えるなら、②を使うべきだろうか。


【安全面からの比較】
ただし下のようなコードを書く懸念があることに留意が必要である。
STLの変数として実体を使うコードである。

class T {
  A() {mX = new int();}
  ~A() {delete mX;}
};

vector<T> gT;

void add() {
  T t;
  gT.push_back(t);
}

int main() {
  add();
  return 0;
}

問題
add関数内でのローカル変数としてt作成時にクラスTのコンストラクタが走る。
push_backはコピーコンストラクタが走る。
クラスTのコピーが走る。
明示的にコピーコンストラクタを宣言しなかった場合はコンパイラが暗黙のうちに
コピーコンストラクタを生成している。これをデフォルトコピーコンストラクタと呼ぶのだが、
単にクラスのメンバをそのままコピーするだけである。
つまりメンバ変数mXもコピーされる。このポインタ変数がコピーされてしまうと
同じ場所を指すポインタが、コピー元とコピー先とで２つ存在することになる。
add終了時にローカル変数として作ったtのdeleteが走り、コピー元が消え、
コピー先でもあるmXも使えなくなる。

簡単なコードでもこういったトラブルは起きる。
性能を犠牲にしても安全面を優先するという選択も判断材料にしてほしい。

ちなみにこの対策としてすぐに２つ思いつく。
・中でnewする型はSTLコンテナへはポインタを入れる

・内部でnewするクラスはコピーコンストラクタと代入演算子は禁止
　◆◆◆ 内部でnewするクラスの基本設計で実施した通りである。



◆◆◆ 関数のパラメータは値かポインタか参照か
値渡しの場合はいいだろう。
パフォーマンスの懸念がなく書きかえもしないようなデータを渡す時である。

考慮が必要なのはポインタか参照かということになる。
実質両者は同じものであるが、
参照にメリットがあるとすれば、
構文がシンプルになる、
NULLにならない、よってNULL値チェックがいらない、
といったメリットがあるだろうか。

以下を見てみる。どの変数が書き換えられるか分かるだろうか。
func(a, b, c, d, e, f);

書き換えない変数はconstの付与を徹底すればいいのではと思うだろう。
func(型* a, 型* b, 型* c, const 型& d, const 型& e, const 型& f)

しかし、それでは関数内で利用する関数で分からなくなる。
func1(型* a, 型* b, 型* c, const 型& d, const 型& e, const 型& f) {
 func2(a, c, e);
 func3(b, d, f);
}

ヘッダを見ればよいだろうが、それではヘッダを見る手間がかかる。

そこで、書き換えないなら参照(もちろんconstをつければなおよし)、
書き換える場合はポインタ渡し、
というルールにしてもいいかもしれない。
func(&a, &b, &c, d, e, f);
dとeとfは入力であり、aとbとcが出力であることが一目瞭然である。

ただしこれでは管理工数がかかると思うかもしれない。
関数の引数は書き換えられる可能性があると常に頭に入れておく、
ぐらいの緩いポリシーの方がいい場合もあるだろう。



◆◆◆ 関数、メソッドからの戻り値に関して
関数、メソッドからの戻り値にポインタか参照、どちらを使うべきだろうか。

まずはポインタ返しと参照返しの例を見てもらう。

① ポインタを使う場合
class T {
  public:
    A* getA() const { return &a; }
  private
    A a;
};

A *a = t.getA();


② 参照を使う場合
class T {
  public:
    A& getA() const { return a; }
  private
    A a;
};

A& a = t.getA();
もしくは
A a = t.getA();

ただし、後者は代入時に値のコピーが走る。
Aが大きなクラスならそのコストがかかる。
知らないうちに遅いコードを書いていたということが起きるかもしれない。

①の場合にコピーが発生する場合は、こういったコードを書いたときだろう。
A a = *t.getA();
関節参照演算子である*を使うことで
その指している先が利用されることが明示的にわかる。

結論だが、どちらでもいい気がするが、
*をつける手間はあるが、何をしているのかはっきりする
①の方針をとることが多い。



◆◆◆ ヘッダのポリシ
【概要】
① インクルードガードの付与

② using namespaceの不宣言

③ パブリックなヘッダとプライベートなヘッダの使い分け

④ すべてのヘッダは自分が依存している他のヘッダファイルをインクルード

⑤ ccファイルからのインクルードは必要なものだけをインクルード

⑥ ヘッダのパス名のルール


【詳細】
① インクルードガードの付与
インクルードガードは基本だろう。

// example.h
#ifndef EXAMPLE_H
#define EXAMPLE_H

class Example {
　　　・
　　　・
　　　・
};

#endif


② using namespaceの不宣言
usingキーワードを使うことで名前空間内でシンボルを簡単に使うことが可能となる。
using namespace std;
stdライブラリであれば、std::coutをcoutと略して使える。
Hogeというnamespaceにいれば、
Hoge::cout
そうではければグローバルな名前空間として
::cout
と区別をつけることはできる。

ただし、ヘッダ中でusing namespace宣言を多用すると、
これを参照したファイルもグローバル名前空間に見えてしまい、
名前空間の意味がなくなってしまう。
特にAPIとして提供するようなパブリックヘッダでは厳禁とする。

プレーンなCでよくやるように、一意な接頭辞を使う方法もあるだろう。


③ パブリックなヘッダとプライベートなヘッダの使い分け
パブリックなヘッダはクラスの顔であるべきであり、内部事情をさらさない。
コンパイラにとって優しいだけではなく、人にとってもその方がいいからである。


④ すべてのヘッダは自分が依存している他のヘッダファイルをインクルード
b.hで定義されている型をa.hで使っていた場合、a.hの冒頭で下を書く。
#include "b.h"
そうしないと、a.hをインクルードする側に、b.hのインクルードも強要することになり、
管理が煩雑になる。

a.hを使うccファイル側に下のようなことはしたくない。
#include "a.h"
#include "b.h"


そもそもインクルードが不要で前方宣言だけでいい場合がある。
クラスAがクラスBのヘッダのインクルードが不要となる例を見てみる。
まず、クラスBを前方宣言。
class B;

・変数がポインタ
class A {
  B* b;
};

・変数の実体を関数の引数に使う
class A {
  void setB(B);
};

・変数の実体を返り値に使う
class A {
  B getB();
};

・テンプレートを使う場合
class A {
  Hoge<B> b;
};

クラスAがクラスBのヘッダを必要とするのは、
そのクラスのオブジェクトをデータメンバとして利用する場合、
そのクラスから継承する場合のみである、ということである。

⑤ ccファイルからのインクルードは必要なものだけをインクルード
④を徹底していれば特に気にすることはない。必要なものをインクルードすればよい。


⑥ ヘッダのパス名のルール
ディレクトリを掘った場所にあるヘッダをccファイルから読み込む場合は
インクルードパスからのパス名も記載する。
#include "hoge/piyo/example.h"

ccと同じディレクトリにあれば当然パスは不要である
しかし規則を統一させたいためこうする

また同じ名前のヘッダ名があった場合に間違いを防げる



◆◆◆ キャスト
型変換するキャスト時にはC++で用意されている型変換方法をとる。
つまり、下のようにはしないということである。
float a = (int)b;

どういうキャストなのか明示させる目的と、
検索しやすくするためである。

【概要】
① static_cast
　intやfloatなどの相互変換。

② reinterpret_cast
　ポインタ型同士の変換や、int型の変数をポインタ型に変換する場合など。
　利用するのはバイナリを読み書きする時ぐらいだろうか。

③ dynamic_cast
　ダウンキャスト時。

④ const_cast
　constを外すような設定はしない。
　忘れてよい。


【例】
①
int num;
double f = 12.3;
num = static_cast<int>(f);

②
クラスTがあったとして、intの数字をポインタに変換する。

int num = 12345;
T* p = reinterpret_cast<T*>( num );

当然だが、どこを指すか分からない値をアドレスとして使うことはできない。

このキャストはバイナリの読み書きぐらい時にしか使わない。

いい例を見かけたのでそれを用いて説明する。
ある画像データには12バイト目から4バイトに画像の高さ情報が格納されている。
この画像フォーマットでは高さを表す型はunsignedと決まっている。
unsigned *height;

画像データを1バイトずつ読みたいためchar型のimageData変数に取り込む。
char* imageData;

この画像データから高さ情報を抜き出してみる。
height = reinterpret_cast<unsigned*>(&imageData[12]);

しかしこれではまずい点が2つある。
heightのunsigned型が4で割り切れるアドレスを持っている保障はない。
ある変数を最初からunsigned型とした作った場合はコンパイラが4で割れる場所に置いてくれる。
char型はその限りではない。仮に偶然char型が4で割れる場所に格納されても、
例えば勝手に7文字分目からを読んでunsignedに変換したらそれは4では割り切れないだろう。

10進数で言えば、1234という数字はそのままでは解釈できないため、
1と2と3と4に分けて読んで合成することになる。
4 + 3*10 + 2*100 + 1*4000 = 1234 // リトルエンディアン例
1 + 2*10 + 3*100 + 4*4000 = 4321 // ビッグエンディアン例

２つの例を書いたのは、合成するにあたって
エンディアンがリトルエンディアンなのかビッグエンディアンなのか
考慮しなければならないためである。


ここでの例として使った画像データがリトルエンディアンの場合は
下のように書き換えるべきである。

コンピュータは8ビットをまとめたバイト単位でしか読み書きできない。
ただ、実際は4バイト単位で操作する。
2の8乗である256進数の数字が4つ並んでいるイメージである。

unsigned height = getUnsigned(&imageData[12]);

unsigned getUnsigned(const char+ p) {
  const unsigned char* up;
  up = reinterpret_cast<const unsigned char*>(p)
  unsigned ret;
  ret =  up[0]
  ret |= (up[1] << 8);
  ret |= (up[2] << 16);
  ret |= (up[3] << 24);
  return ret;
}

②の説明が長くなった。
③、④は割愛。



◆◆◆ unsignedの使いどころ
正の整数であればunsignedでいいのだろうか。
その変数が正であっても減算処理内で計算結果が机上で負数にならないことを
考慮できればよいがそれを考慮するのも手間である。

そこで次の指針を立てる。

① ビット演算をする場合

② intでは足りない範囲で必ず正になる計算処理をする場合
　上を考えたくなければすべてintでいい。
　または富豪的プログラミングをするのであればdoubleを使う。



◆◆◆ インライン化の方針
コンパイル時に関数の呼び出し側に関数をコピーし、
呼び出しのコストを抑えるというメリットがあるが基本使わない。

理由はインライン化するには関数の中身が見えなければならず、
同一ccファイルでしか使えないため利用用途が限られる。
ccファイルから別のccファイルをインクルードなどしない。
コンパイルはccファイル頃にバラバラに行うのが普通だ。


ヘッダに関数の中身を書く方法はどうだろうか。
ヘッダに書かれた関数は自動でインライン化される。
しかし、ヘッダ内に関数の中身は書くことも推奨し難い。
利用者に不要な中身を見せない、という方針に反する。
またその関数を変更した場合、このヘッダを読み込む全ccファイルのコンパイルが走る。

また、virtualがつく仮想関数では使えない。
実行するまで分からないので仮想なのだから当然だ。

上記デメリットを上回るなら利用してもいいだろうが、
人が考えるよりコンパイラの最適化に任せた方が楽だろう。



◆◆◆ グローバル変数を利用しない
例えば、あるクラスのインスタンスをグローバル変数に代入して
使いたくはないが、引数に延々と渡していくようなこともしたくない。
そこでシングルトンを使う。
あるクラスのインスタンスがプログラム全体で
１つしか存在しないことも保証できる。

※シングルトンをモノステートと誤解ないように。
 シングルトン：1つしかインスタンスを作成させないことによる単一構造の強制
 モノステート：複数のインスタンスで同じデータを強要する単一動作の強制


class T {
public:
  // 唯一のアクセス経路
  // static関数として定義する
  static T* getInstance() {
    return msInstance;
  }

  // create()内でコンストラクト
  static void create() {
    if( msInstance == 0 ) {
      msInstance = new T();
    }
  }

  // destroy()内でデストラクト
  static void destroy() {
      delete msInstance;
    }

  void example() {
    ～
  }

private:
  // コンストラクタを隠す
  // 勝手にnewさせない
  // create()を通すことを強制する
  T() {}

  // デストラクタを隠す
  // destroyすればdeleteできるが、
  // 意図せずdeleteされない備えにはなる
  ~T() {}

  // コピーコンストラクタを隠す
  T( const T& );

  // 代入を隠す
  T& operator=( const T& );

private:
    static T* msInstance;
};


使い方もまとめておく。

クラスポインタであるmInstance変数を作る。
static指定子をつけた静的メンバ変数なので、
メモリ上にただ１つしか存在しない。
T::create();

メソッドを呼び出してみる。
T::getInstance()->example()

少し長く感じるなら別名をつければよい。
T *t = T::getInstance()
t->example();

破棄する場合はdeleteではない。
t->destroy();


余談だが、グローバル変数をファイル間で使っている場合、
その変数をexternして実体は別にいることを宣言することがある。
extern指定子をグローバル変数以外に使うことはない。
つまりシングルトンを利用すればexternは不要である。



◆◆◆ 煩雑なif文の忌避
C++のコードに限らないが、煩雑なif文は避ける。
【変更前】

if ((A == ～ && B == ～) || (B == ～ && C == ～) {
～
}


【変更後】
book isA = (A == ～);
book isB = (B == ～);
book isC = (C == ～);
bool condtion0 = (isA && isB);
bool condtion1 = (isB && isC);

if (condition0 || condition1) {
～
}



◆◆◆ 配置new(placement new)の利用
大量にnewしなければならず、速度も求められる場合には
メモリプールを使ってもいいだろう。

T* memoryPool = operator new(sizeof(T) * n);

for (int i=0; i<n; ++i){
  new( &memoryPool[i] ) T; // 配置new
}

for(int i=0; i<n; ++i) {
  array[i].~T(); // デストラクタの呼び出し(ここではメモリ解放は不要)
}

operator delete(memoryPool)

例えば、newはclass内にも定義できるので、
そこから配置newを使う場合は、グローバルスコープの配置newが確実に
呼ばれるように、スコープ解決演算子を付与してもいいかもしれない。
::new( &memoryPool[i] ) T;



◆◆◆ シングル引数を取るコンストラクタの宣言時のexplicitキーワード
C obj = 10;
は
C obj(10);
に変換される。

C::operator=(int)
が呼び出されるのではない。operator=()が定義してあっても同様である。

非明示的な振る舞いは混乱を招く。
非直感的な自動変換を禁止するため、
explicit C(int)
と宣言する。