37

C++ でヘッダー ファイルをインクルードする場合の違いは何ですか...

1) .h を < > 記号で囲むときに .h を含めるのと含めないのでは?

#include <iostream> vs. #include <iostream.h>

2) ヘッダー名を二重引用符で囲むのではなく、< > 記号で囲むのですか?

#include <iostream.h> vs. #include "iostream.h"

前もって感謝します！

4

8 に答える 8

52

要するに：

iostream.hは非推奨です — オリジナルの Stroustrup バージョンです。iostream標準化委員会からのバージョンです。通常、コンパイラは両方を同じものに向けますが、一部の古いコンパイラには古いコンパイラがありません。いくつかの奇妙なケースでは、それらの両方が存在し、(レガシー コードをサポートするために) 異なる場合があり、その場合は具体的に指定する必要があります。

""vs<>は単に、ライブラリに移動する前にヘッダーのローカル ディレクトリをチェックすることを意味します (ほとんどのコンパイラで)。

于 2008-10-18T00:16:14.500 に答える
7

ここにまともなリンク記事があります。

要約すると、与えられた理由：

標準委員会が作成した iostream ライブラリのバージョンは、CFront 実装とはかなり異なっていました。{をちょきちょきと切る}

移行を容易にするために、C++ 標準委員会は、標準 C++ ヘッダーを含むコードは、拡張子のない include ディレクティブを使用すると宣言しました。これにより、コンパイラ ベンダーは古いスタイルの C++ ライブラリ ヘッダーを .h 拡張子付きで出荷し、新しいスタイルのヘッダーを.h なしで出荷することができました。

.h バージョンを使用しない利点:

.h 形式ではなく拡張子のないバージョンのヘッダー ファイルを使用して新しいコードを記述する必要がある理由はいくつかあります。1 つ目は、最新のコンパイラでコンパイルした場合のそのようなコードの予測不可能性です。前述のように、.h ヘッダーを使用した結果は実装によって異なります。そして時間が経つにつれて、特定のコンパイラが古いスタイル ライブラリを利用できる可能性は減少します。

于 2008-10-18T00:11:41.420 に答える
6

.h を除外することを提案した標準委員会 (X3J16) のメンバーとして、私の当初の意図は、.h、.H、.hpp、.hxx、または .h++ ファイル拡張子に関する議論を解決することでした。または、IDE がプリコンパイル済みのヘッダー情報をリソース ファイルなどの内部のどこかから、または内部の内部から引き出すことを可能にするために、これがディスク上のファイルの名前であるという標準に含意がないことを望む人もいます。コンパイラ。

Unix はファイル名を単一の文字列と見なし、拡張子の概念を実際には認識しませんでしたが、DEC オペレーティング システムには、名前を拡張子から分離し、特定のコンテキストで省略された場合に「デフォルトの拡張子」を提供するという伝統がありました。ここで、実装が使用したい拡張機能を使用することを実装に任せるというアイデアを思いつきました。これにより、実装はディスク上にファイルを持たなくても済みました。（当時、私は委員会のDECの代表でした。）

標準ヘッダーと標準化前のヘッダーを区別することは、追加の利点でした。

于 2013-11-01T02:02:02.363 に答える
2

標準的な方法 (そして動作が保証されている唯一の方法) は <iostream> です。gcc では、<iostream.h> (<backward/iostream.h> として含める必要がある場合があります) は、関連する宣言をグローバル名前空間にプルします (したがって、std:: 名前空間プレフィックスは必要ありません)。

「iostream.h」は、「」がプロジェクトのヘッダー用であるため、ソース コードを含むディレクトリから最初に試行します。<> は常にシステム ヘッダーに使用し、"" は独自のヘッダーに使用する必要があります。

于 2008-10-18T00:17:38.927 に答える
1

最初の答えに対する簡単な答えは、少なくとも 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 は後方互換性のためのものです。

于 2008-10-18T00:39:01.800 に答える
1

標準 C++ ヘッダー ファイルの名前に関しては、X3J16 の初期 (最初の 2 年間) に、標準 C++ ヘッダー ファイルの拡張子をどうするかという議論に直面しました。当時、さまざまなベンダーによって使用されていました (また、一部のオペレーティング システムがファイル名に課した制約の影響を受けていました) .h、.H、.h++、.hpp、.HXX、およびおそらくその他の名前があったと思います。ライブラリ グループの会議で、私は拡張子をオフのままにし、インクルード行に何もない場合に選択したデフォルトのファイル拡張子を提供するか、またはその名前をデータベースのキーとして使用するかを実装に任せることを提案しました。必要に応じて、プリコンパイル済みヘッダー ファイル。[Unix ライクなシステムはファイル名と「拡張子」を 1 つの文字列として扱いますが、私は委員会で DEC を代表していました。また、多くの DEC オペレーティング システムでは、拡張子が名前とは別のフィールドとしてディレクトリに格納されていました。そのため、DEC オペレーティング システムには、どのプログラムがどのような目的でファイルにアクセスしているかに基づいてデフォルトの拡張子を適用するという強い伝統がありました。アセンブラに「X,Y=Z」と伝えると、入力ファイル Z.MAC (マクロ) が読み取られ、出力ファイル X.OBJ および Y.LST が書き込まれる可能性があります。それに沿って進み、Andy Koenig はこれに関するグループの結論を (とりわけ) 委員会全体に提示し、委員会はそれを受け入れました。実装が、選択したデフォルトの拡張子を適用できるという点全体を見逃して (エディターやその他のツールに役立つと思います)、拡張子をファイル名から除外しただけなのは、少しおかしいと思います。そのため、DEC オペレーティング システムには、どのプログラムがどのような目的でファイルにアクセスしているかに基づいてデフォルトの拡張子を適用するという強い伝統がありました。アセンブラに「X,Y=Z」と伝えると、入力ファイル Z.MAC (マクロ) が読み取られ、出力ファイル X.OBJ および Y.LST が書き込まれる可能性があります。それに沿って進み、Andy Koenig はこれに関するグループの結論を (とりわけ) 委員会全体に提示し、委員会はそれを受け入れました。実装が、選択したデフォルトの拡張子を適用できるという点全体を見逃して (エディターやその他のツールに役立つと思います)、拡張子をファイル名から除外しただけなのは、少しおかしいと思います。そのため、DEC オペレーティング システムには、どのプログラムがどのような目的でファイルにアクセスしているかに基づいてデフォルトの拡張子を適用するという強い伝統がありました。アセンブラに「X,Y=Z」と伝えると、入力ファイル Z.MAC (マクロ) が読み取られ、出力ファイル X.OBJ および Y.LST が書き込まれる可能性があります。それに沿って進み、Andy Koenig はこれに関するグループの結論を (とりわけ) 委員会全体に提示し、委員会はそれを受け入れました。実装が、選択したデフォルトの拡張子を適用できるという点全体を見逃して (エディターやその他のツールに役立つと思います)、拡張子をファイル名から除外しただけなのは、少しおかしいと思います。アセンブラに「X,Y=Z」と伝えると、入力ファイル Z.MAC (マクロ) が読み取られ、出力ファイル X.OBJ および Y.LST が書き込まれる可能性があります。それに沿って進み、Andy Koenig はこれに関するグループの結論を (とりわけ) 委員会全体に提示し、委員会はそれを受け入れました。実装が、選択したデフォルトの拡張子を適用できるという点全体を見逃して (エディターやその他のツールに役立つと思います)、拡張子をファイル名から除外しただけなのは、少しおかしいと思います。アセンブラに「X,Y=Z」と伝えると、入力ファイル Z.MAC (マクロ) が読み取られ、出力ファイル X.OBJ および Y.LST が書き込まれる可能性があります。それに沿って進み、Andy Koenig はこれに関するグループの結論を (とりわけ) 委員会全体に提示し、委員会はそれを受け入れました。実装が、選択したデフォルトの拡張子を適用できるという点全体を見逃して (エディターやその他のツールに役立つと思います)、拡張子をファイル名から除外しただけなのは、少しおかしいと思います。これに関する（とりわけ）結論を、それを受け入れた委員会全体に通知します。実装が、選択したデフォルトの拡張子を適用できるという点全体を見逃して (エディターやその他のツールに役立つと思います)、拡張子をファイル名から除外しただけなのは、少しおかしいと思います。これに関する（とりわけ）結論を、それを受け入れた委員会全体に通知します。実装が、選択したデフォルトの拡張子を適用できるという点全体を見逃して (エディターやその他のツールに役立つと思います)、拡張子をファイル名から除外しただけなのは、少しおかしいと思います。

于 2018-06-05T01:38:42.777 に答える
1

通常、<> はシステムまたは標準ライブラリ ファイルに使用され、"" はプロジェクト ファイルに使用されます。コンパイラがローカルで検索し、見つからない場合、デフォルトで標準ライブラリ バージョンが使用されても驚かないでしょう。

.h に関しては、C を使用するかどうかは実際には問題ではないと思います。C++ では、新しいバージョンと古いバージョンがあり、h がなければ新しいバージョンになるはずだったことを漠然と覚えています。しかし、古いバージョンがまだ存在するかどうかさえわかりません。

于 2008-10-18T00:14:21.010 に答える
1

これらは、実際には 2 つの異なる質問です。

  • 同じ名前の .h ヘッダーと拡張子のないヘッダーの違いは歴史的なものです。拡張子が .h のものは、名前空間やテンプレートなどの最新の機能を持たない元の C++ 標準のものです。新しい標準では、同じ機能を新しいヘッダー ファイルに配置して、これらの新しい機能を使用し、レガシー コードの下位互換性のために古い (.h) ファイルを保持できるようにする方が簡単でした。

  • #include <...> と #include "..." 形式の違いは、コンパイラがファイルを検索する順序です。これは一般に実装に依存しますが、 <> 形式は最初にシステム インクルード ディレクトリを検索し、"" は最初に #include されたソース ファイルと同じディレクトリを検索するという考え方です。

于 2008-10-18T02:37:42.077 に答える