<iostream> と<iostream.h> と「iostream.h」

StackOverflow https://stackoverflow.com/questions/214230

  •  03-07-2019
  •  | 
  •  

質問

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

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

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

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

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

前もって感謝します！

役に立ちましたか？

解決

要するに：

iostream.hは非推奨です。これは元のStroustrupバージョンであり、iostreamは標準化委員会のバージョンです。一般に、コンパイラは両方を同じものに向けますが、古いコンパイラの中には古いものを持たないものもあります。いくつかの奇妙なケースでは、それらは存在し、異なる（レガシーコードをサポートするため）ので、具体的にする必要があります。

＆quot;＆quot;対＆lt;＆gt;単にライブラリに移動する前にヘッダーのローカルディレクトリをチェックすることを意味します（ほとんどのコンパイラ）。

-アダム

他のヒント

適切なリンク記事

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

  

標準化委員会が作成したiostreamライブラリのバージョン   生成されたものは、CFront実装とはかなり異なっていました。   {snip}

     

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

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

  

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

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

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

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

標準的な方法（および唯一の動作が保証されている方法）は＆lt; iostream＆gt;です。 gccでは、＆lt; iostream.h＆gt; （これは＆lt; backward / iostream.h＆gt;として含める必要があります）は、関連する宣言をグローバル名前空間にプルします（したがって、std ::名前空間プレフィックスは不要です）。

＆quot; iostream.h＆quot; 「＆quot;＆quot;プロジェクトのヘッダー用です。 ＆lt;＆gt;システムヘッダーには常に使用する必要があり、＆quot;＆quot;独自のヘッダー用。

通常＆lt;＆gt; ＆quot;＆quot;はシステムまたは標準ライブラリファイルに使用されます。プロジェクトファイルに使用されます。コンパイラがローカルで検索し、見つからない場合はデフォルトの標準ライブラリバージョンが使用されても驚くことではありません。

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

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

  • .hと.hの違い 同じ拡張子のないヘッダー 名前は歴史的です。あるもの .h拡張子は しなかった元のC ++標準 などのいくつかの近代的な機能を持っています 名前空間とテンプレート。そうだった 新しい標準をよりシンプルに 新しい機能と同じ機能 これらを使用できるヘッダーファイル 新機能と古い（.h）を保持 の後方互換性のためのファイル レガシーコード。

  • #includeの違い ＆lt; ...＆gt;および#include＆quot; ...＆quot;形式は コンパイラの順序 ファイルを探します。これは一般的に 実装依存ですが、 考えは＆lt;＆gt;フォーマットは システムにはディレクトリが最初に含まれます。 while＆quot;＆quot;同じディレクトリを検索します #includeしたソースファイルとして 最初。

最初の答えに対する簡単な答えは、少なくともGCC実装にはiostream.hが存在しないということです。 * nixを使用している場合は、

と入力します

％Locate iostream.h
/ usr / include / c ++ / 3.4.3 / backward / iostream.h

and

％Locate 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 系システムはファイル名と「拡張子」を 1 つの文字列として扱いますが、私は委員会で DEC を代表していましたが、多くの DEC オペレーティング システムは拡張子を名前とは別のフィールドとしてディレクトリに保存していました。そのため、DEC オペレーティング システムには、どのプログラムがどのような目的でファイルにアクセスしているかに基づいて、デフォルトの拡張子を適用するという強い伝統がありました。アセンブラに 'X,Y=Z' を指示すると、入力ファイル Z.MAC (マクロ) が読み取られ、出力ファイル X.OBJ および Y.LST が書き込まれる可能性があります。] とにかく、長く勝ち目のない議論を避けることができたので、グループははこれに同意し、アンディ・ケーニッヒはこれに関するグループの結論を（とりわけ）委員会全体に提示し、委員会はそれを受け入れた。実装が、選択したデフォルトの拡張子 (これはエディターや他のツールにとって便利だと思います) を適用できるという点をまったく見逃して、ファイル名から拡張子を省略したままになっているのは、少々面白いと思います。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top