Bjarne Stroustrupとのインタビュー - 抽象化と手作りのコード

Question

私はinterviewをBjarne StroustrupとC++とそのデザインで読みました。私は彼がそこで使用した用語で混乱していたので、私はそのような瞬間のいくつかを明確にすることを望んでいました。

私は私の本、「C++の設計と実装」に、私の2つの歴史プログラミング言語の会議論文で私の設計目標と設計上の制約を文書化しますが、簡単に、私は

を目指します
• 抽象化を使用するときに手作りのコードと比較ゼロオーバーヘッド、
• Cのものと非常に類似した機械モデル、
• 抽象化機構の極めて柔軟セット、及び
• 静的TY安全です。

1. 「手作りのコードは、」このような場合には何を意味するのでしょうか... Stroustrup氏 はプログラマ を作成することができる抽象概念のためのいくつかの手作り道具を意味するのでしょうか？
2. この場合、「マシンモデル」とは何ですか？言語がハードウェアとやりとりする方法？

私は彼が言及した本に見ていた（実際には「デザインとC++の進化」で、私は信じている）が、私はまだ本当にわかりません。これらの2つの用語もグーグルグーグルではありません。

Answer 1

「マシンモデル」とは、コンピュータがその言語で明らかにする方法を意味します。たとえば、CやC++では、バイト、メモリの場所、ポインタ、整数の型を多かれ少なかれ同じ方法で扱います。

ここで「手作り」とは、C++で提供される抽象化を使用せず、Cまたはアセンブリ（またはその抽象化を除いてC++）で効率的に記述される同等のコードを意味します。これは "狙い"であり、 "制約"ではありません.C++はすべての場合において正確に達成できません。そのコードは（当然です）、必要なときにストレージのサイズを変更するreallocを使用する可能性があるため

はそうちょうど例として、vector<int>は常に、mallocとfreeを使って書かれた同様のサイズ変更可能な配列とまったく同じ性能を達成しません。 reallocは非常に頻繁にあなたを救うことはありませんが、それは塊を保存します。 vectorは、アロケータインターフェイスがreallocに相当する何も持っていないため、小さなオーバーヘッドが導入されているため、これを行うことはできません。しかし、vectorは、ほとんどすべての時間においてほぼ同じ性能を持ち、ゼロオーバヘッドの目的はほぼ満たされています。

もう1つの例：リリースモードでまともなC++コンパイラを使用している場合、myvector_of_int[3]を書くと、my_int_pointer[3]と比べてゼロオーバーヘッドが本当にあります。ローカル変数（myvector_of_intに格納されているデータポインタ）のデータメンバにアクセスするのにポインタ型のローカル変数（my_int_pointer）にアクセスする場合に比べてオーバーヘッドがないのはなぜか分かりませんが、余分な費用はかかりません。

Answer 2

「手作りの」コードでは、Stroustrupは手書きの抽象化の実装を意味します。例えば、手作業のforループは、ループ本体のN個のコピーである。 （単純な実装では、Duff's Deviceを参照してください。）

"マシンモデル"によって、Stroustrupはマシンのコンパイラのビューを意味します。たとえば、CおよびC++では、バイト、メモリの場所、メモリアクセスの順序付けなど、およそ同等のビューが提供されます。対照的に、Fortranは "バイト"という概念を持っておらず、メモリ位置（または配列アクセス）はC/C++ビューには全く対応していません。