私は実行時の型情報に関連するものについて考えています。私よりもはるかに大きなプロジェクトで作業するプログラマーからのフィードバックがほしいです。 1つのプロジェクトに65536（2^16）以上のユーザー定義型（クラスと構造体）を持つプログラムがあると期待するのは妥当ですか？これはではなく、の平均65536インスタンスを意味し、65536 タイプを意味します。コンパイラがどのプロジェクトでも65536個のクラス/構造体に制限されていたとしても、実際には全く問題になりませんか？大きなプロジェクトで65536を超えるユーザー定義型を持つことは妥当ですか？
いいえ、その時点でプロジェクトを強く分離する必要があるためです。 「公共に直面する」タイプだけがプロジェクト全体で相互に作用する必要があります。その場合、制限は次のようになります。プロジェクトごとに最大2^16種類、すべてのプロジェクトで最大2^16の公開向きの種類があります。
誰がタイプ情報== 16ビット番号と言っていますか？
私はこれを環境の制約と考えています。システムによっては、自動的にタイプが生成されます。これらの機会には、多数のタイプが作成されます。これらが65536の近くにない場合でも、なぜそのような制限を課したいと思いますか？
最近のアプリケーション/システムでは、すべてのオブジェクトの数はシステムメモリによってのみ制限されています。これは、他の制限がある場合は後退します。
優先順位の問題です。プロジェクトの現在のスコープで正当な種類の「無限」を実装するのに費やす時間（およびコードの量）はありますか？
また、プロジェクト/コンパイラが大きくなるにつれて保守性を考慮する必要があります。
私は、肥満の種類のような特殊なケースでは、これを具体的にターゲティングしていない場合には考慮しないと言っています。あなたのターゲットオーディエンスは誰ですか？
はUPDATE：あなたが実際にそれが明確に文書化されている限り（メモリなど、実行速度、のような）他のいくつかの局面では、より効率的になるために自分自身を制限したい場合がありますいくつかのケースで 私は、あなたがすべきだと思いますあなたの特定のニーズに合ったものを選んでください。
これは私が検討しているスキームのための仮説です。 – dsimcha
さて、それを32ビットの数値にして、クラスあたり2バイト追加すると、多くの問題を引き起こすことはありません。 –
ガベージコレクタによって格納されたRTTIへのポインタと関係しているので、* instance *あたり2バイト余分になります。 – dsimcha