コンパイラを横断して多くのコードを移植した結果として生まれたものです。機能を追加>できないのはヘボコンパイラだ」と叫びたくなるかもしれません。これが移植性の高いコードの現実です。プラットフォーム上でシームレスに動作し、新しいマシンへの移植も容易となるでしょう。私たちは情報を最新に保つよう努力しています(例えば、ときどきコンパイラの改定で制約が取り除かれるかもしれません)。して登録してください。これらのルールのどれ一つとして絶対的なものではありません。やりたいことが私たちのサポートするすべてのコンパイラで正しく動作するということをパッチの製作者が示せるならば、自由にこれらのルールを破って、改訂してもいいです。これにはたくさんの作業が必要で、それを行いたいと思う非常に良い理由がなければ推奨されません。テンプレートを使わないでください。コンストラクタは確実な動作が期待できません。呼び出される直前)にインスタンス化されるオブジェクトです。これらのオブジェクトには2つの部品があります。一つ目は、プログラムのグローバルなデータ部分へ読み込まれる静的なデータであるデータ部分です。呼び出される前にローダによって呼び出される初期化関数です。今までに、多くのコンパイラが初期化関数について信頼できる実装をしていないのを目にしてきました。そのとき、オブジェクトのデータを得るとき、それは決して初期化されないものなのです。移植性を低下させます。例外を使ってはいけません。運悪く、同じような機能をもったよい代替案はありません。この規則の例外が一つあり(ここではそれについて言わないが)、それは多分大丈夫でしょう。いくつかのマシンに限定されたコードでだけ例外を使う必要性があるでしょう。特定のマシン限定のコードの中で例外を使うなら、すべての例外をそこでキャッチしなくてはなりません。XP(クロスプラットフォーム)なコードにまたがって例外を飛ばすことは許されないからです。機能で、多くのコンパイラではサポートされていません。メンバ関数の追加と、それぞれのサブクラスのメンバ関数をオーバーライドすることによって類似の結果を作り上げることができます。階層のそれぞれのクラスについて固有の値を返すなら、実行時の型比較をすることが出来るでしょう。標準ライブラリの機能を使うことで移植性に関する重大な問題を引き起こします。使おうとしている人たちが使うのが難しくなります。使うことは受け入れられています。インクルードしてください。機能で、多くのコンパイラではサポートされていません。コンパイラにとってのとても気の利いたプリプロセッサでした。コードを生成しました。ためには呼ばれなくてはならない)。追加することによって実装しています。関数を見る必要があります。ファイルの中になければなりません。特有の初期化実行をリンカ(Linker)の問題として扱っています。ベースに出荷されています。このため、代替案はきわめて単純です。ファイルの中に入れることに注意してください。ファイルを加えるという形でこれを行っています。コンパイラの実装はまったく異なっています。できないことがときどきあるということです。コンパイラはその一つでした。コンパイラはサポートしていません。これは移植上の障害になりえます。ファイルで共有されるヘッダファイルに出てくるからです。それに対する唯一の対策は、両方のコンパイラでサポートしている共通要素だけを使うことです。long型が利用できないために、64ビットの整数型をサポートするためのマクロのセットを開発しました。64ビットの型をサポートしない場合にこれらのマクロを使います。C++式コメント(//コメント)を入れることです。Cコンパイラの上では動くでしょう。コンパイラではサポートされていません。そんなことはやめなさい。これらのヘッダにも同じルールを適用するのは良い考えだと思います。C++式コメントを入れないでください。スタイルのコメントを使ってもよいと考えるかもしれません。それがいつでもうまくいくとは確信できません(いくつかのコンパイラはコメント抽出とプリプロセッシングの間で奇妙な挙動をします)し、そこまでするに見合う価値があるとはとても思えません。/**/式コメントを貫いてください。コンパイラだけ以上の問題に見えます。