たとえば、STL実装のほとんどのメンバーが_M_
または_
または__
プレフィックスを持っているのはなぜですか?なぜこれほど多くの定型コードがあるのですか?
ベクトル(たとえば)の実装を明確かつ簡潔にするためにC ++に欠けている機能は何ですか?
たとえば、STL実装のほとんどのメンバーが_M_
または_
または__
プレフィックスを持っているのはなぜですか?なぜこれほど多くの定型コードがあるのですか?
ベクトル(たとえば)の実装を明確かつ簡潔にするためにC ++に欠けている機能は何ですか?
実装では、アンダースコアで始まり、その後に大文字または 2 つのアンダースコアが続く名前を使用して、ユーザー定義のマクロとの競合を回避します。このような名前は C++ で予約されています。たとえば、Type
and thenというマクロを定義できます#include <vector>
。vector
実装がテンプレート パラメーター名として使用されている場合Type
、それは壊れます。ただし、_Type
(またはなど)と呼ばれるマクロを定義することはできません。したがって、そのような名前を安全に使用できます。__type
type__
vector
多くの STL 実装には、デバッグ ビルドのチェックも含まれます。たとえば、2 つの反復子を比較するときに同じコンテナーからのものであることを確認したり、反復子が範囲外に出ていないかどうかを監視したりします。これには、作成されたすべての反復子のコンテナーと有効性を追跡するためのかなり複雑なコードが含まれますが、バグを見つけるのに非常に役立ちます。このコードは、STL アルゴリズムであっても、#ifdefs を使用して標準のリリース コードとすべて織り交ぜられています。したがって、最も基本的な操作ほど明確になることはありません。このようなサイトは、STL アルゴリズムの最も基本的な機能を示しており、それらの機能はそれらが示すコードと「同等」であると述べています。ただし、ヘッダーファイルには表示されません。
robson と AshleysBrain が既に示した正当な理由に加えて、C++ 標準ライブラリの実装が簡潔な名前とコンパクトなコードを持つ 1 つの理由は、ほぼすべての C++ プログラム (実際にはコンパイル単位) に多数の標準ライブラリ ヘッダーが含まれていることです。したがって、それらは繰り返し再コンパイルされます (大部分がインライン化され、テンプレートベースであるのに対し、C 標準ライブラリのヘッダーにはほんの一握りの関数宣言しか含まれていないことに注意してください)。「業界標準」スタイルのガイドラインに従って作成された標準ライブラリは、コンパイルに時間がかかるため、特定のコンパイラが「遅い」という認識につながります。空白を最小限に抑え、短い識別子名を使用することで、レクサーとパーサーが行う作業が少なくなり、コンパイル プロセス全体が少し速く完了します。
言及する価値のあるもう 1 つの理由は、多くの標準ライブラリの実装 (たとえば、Dinkumware、Rogue Wave (旧) など) を、さまざまな標準への準拠と癖を持ついくつかの異なるコンパイラで使用できることです。サポートされている各プラットフォームを満たすことを目的としたマクロハッカーが頻繁に行われています。