<iostream> vs. <iostream.h> vs. "iostream.h"
C++にヘッダーファイルを含める場合、の違いは何ですか...
1）<>記号で囲むときに.hを含めるか、.hを含めないか？
#include <iostream> vs. #include <iostream.h>
2）ヘッダー名を二重引用符で囲むのではなく、<>記号で囲むのですか？
#include <iostream.h> vs. #include "iostream.h"
前もって感謝します！
要するに：
iostream.hは非推奨です-これは元のStroustrupバージョンであり、iostreamは標準化委員会からのバージョンです。通常、コンパイラは両方を同じものに向けますが、一部の古いコンパイラには古いコンパイラがありません。いくつかの奇妙なケースでは、それらは両方とも存在し、（レガシーコードをサポートするために）異なっているため、具体的にする必要があります。
「」対<>は、ライブラリに移動する前に、ヘッダーのローカルディレクトリを確認することを意味します（ほとんどのコンパイラで）。
-アダム
ここにまともなリンクがあります 記事。
要約すると、与えられた理由：
標準委員会が作成したiostreamライブラリのバージョンは、CFrontの実装とはかなり異なっていました。 {をちょきちょきと切る}
移行を容易にするために、C++標準委員会は、標準のC++ヘッダーを含むコードが拡張子のないincludeディレクティブを使用することを宣言しました。これにより、コンパイラベンダーは、拡張子が.hの古いスタイルのC++ライブラリヘッダーと、拡張子のない新しいスタイルのヘッダーを出荷できました。
.hバージョンを使用しないことの利点：
.hフォームの代わりに拡張子のないバージョンのヘッダーファイルを使用して新しいコードを作成する必要がある理由はいくつかあります。 1つ目は、最新のコンパイラでコンパイルした場合のそのようなコードの予測不可能性です。前述のように、.hヘッダーを使用した結果は実装固有です。そして時間が経つにつれて、特定のコンパイラが古いスタイルのライブラリを利用できるようになる可能性は低くなります。
.hを省略することを提案した標準委員会（X3J16）の人として、私の当初の意図は、.h、.H、.hpp、.hxx、または.h ++ファイル拡張子に関する議論を解決することでした。または、IDEがプリコンパイル済みヘッダー情報を内部のような場所からプルできるようにするために、これがディスク上のファイルの名前であるという意味が標準にないことを望む人もいます。リソースファイル、あるいはコンパイラの根性さえも。
Unixはファイル名を単一の文字列と見なし、実際には拡張子の概念を認識しませんでしたが、DECオペレーティングシステムには、名前を拡張子から分離し、特定のコンテキストで省略された場合は「デフォルトの拡張子」を提供するという伝統がありました。そこで、実装が使用したい拡張機能を使用するように実装に任せるというアイデアを思いつきました。これにより、実装はこのファイルをディスク上に置くことさえできなくなりました。 （当時、私は委員会のDECの代表でした。）
標準ヘッダーと事前標準ヘッダーを区別することは、追加の利点でした。
標準的な方法（および動作が保証されている唯一の方法）は<iostream>です。 gccでは、<iostream.h>（<backward/iostream.h>として含める必要がある場合があります）は、関連する宣言をグローバル名前空間にプルします（したがって、std ::名前空間プレフィックスは必要ありません）。
「iostream.h」は、ソースコードのあるディレクトリから最初に試行します。これは、「」がプロジェクトのヘッダーを対象としているためです。 <>は常にシステムヘッダーに使用し、 ""は独自のヘッダーに使用する必要があります。
これらは実際には2つの異なる質問です。
同じ名前の.hヘッダーと拡張子のないヘッダーの違いは歴史的です。拡張子が.hのものは、名前空間やテンプレートなどの最新機能を備えていない元のC++標準のものです。新しい標準では、同じ機能を新しいヘッダーファイルに入れて、これらの新しい機能を使用し、レガシーコードの下位互換性のために古い（.h）ファイルを保持できるようにする方が簡単でした。
#include <...>形式と#include "..."形式の違いは、コンパイラがファイルを検索する順序です。これは一般に実装に依存しますが、<>形式は最初にシステムインクルードディレクトリを検索し、 ""は最初にそれをインクルードしたソースファイルと同じディレクトリを検索するという考え方です。
通常、<>はシステムまたは標準ライブラリファイルに使用されますが、 ""はプロジェクトファイルに使用されます。コンパイラがローカルで検索し、見つからない場合は、デフォルトで標準ライブラリバージョンに設定されていても驚かないでしょう。
.hについては、Cを使用しても実際には問題ないと思います。C++では、新しいバージョンと古いバージョンがあり、hがないと新しいバージョンになるはずだったことを漠然と覚えています。しかし、古いバージョンがまだ存在するかどうかさえわかりません。
最初の答えに対する簡単な答えは、少なくともGCCの実装ではiostream.hが存在しないということです。 * nixを使用している場合は、次のように入力します
％iostream.hを見つけます
/usr/include/c ++/3.4.3/backward/iostream.h
そして
％iostreamを検索
/usr/include/c ++/3.4.3/iostream
/usr/include/c ++/3.4.3/backward/iostream.h
Zeeの記事にあるように、iostream.hは下位互換性のためのものです。
標準のC++ヘッダーファイルの名前に関しては、X3J16の初期（最初の2年間）に、標準のC++ヘッダーファイルの拡張子をどうするかについての議論に直面しました。当時、さまざまなベンダーによって使用されていました（そして、一部のオペレーティングシステムがファイル名に課した制約の影響を受けました）。h、.H、.h ++ 、. hpp、.HXX、およびおそらく他のものがあったと思います。ライブラリグループミーティングで、拡張子をオフのままにし、実装に任せて、インクルード行に何もない場合は選択したデフォルトのファイル拡張子を提供するか、名前をデータベースのキーとして使用することを提案しました。必要に応じて、プリコンパイル済みヘッダーファイル。 [Unixライクなシステムはファイル名と「拡張子」を単一の文字列として扱いますが、私は委員会でDECを代表し、多くのDECオペレーティングシステムは名前とは別のフィールドとして拡張子をディレクトリに保存しました。そのため、DECオペレーティングシステムには、どのプログラムがどの目的でファイルにアクセスしているかに基づいて、デフォルトの拡張子を適用するという強い伝統がありました。アセンブラに「X、Y = Z」と指示すると、入力ファイルZ.MAC（マクロ）が読み取られ、出力ファイルX.OBJとY.LSTが書き込まれる可能性があります。]とにかく、長い、勝てない議論を避けたので、グループそれに伴い、Andy Koenigは、これに関するグループの結論を（とりわけ）それを受け入れた委員会全体に提示しました。実装が選択したデフォルトの拡張子（エディターや他のツールに役立つと思う）を適用できるという全体的なポイントを見逃し、ファイル名から拡張子を省略したのは少し面白いと思います。