3

checkpatch.plスクリプト「extern宣言は.cファイルの外にあります」（パッチがコーディングスタイルに準拠しているかどうかを調べるために使用）注：これはコンパイル警告なしで完全に正常に機能します。この問題は、extern宣言を.hファイルに配置することで解決されます。

a.c
-----
int x;
...

b.c 
----
extern int x;

==>checkpatchが文句を言う

a.h
-----
extern int x;

a.c
----
int x;

b.c
---- 
#include "a.h"

==>文句を言わない

なぜこれが良いのか理解したい

私の憶測。理想的には、コードをモジュール化するためにコードをファイルに分割します（各ファイルはモジュールです）。モジュールによってエクスポートされたインターフェイスは、他のモジュール（または.cファイル）にインクルードできるようにヘッダーファイルに配置されます。したがって、モジュールがいくつかの変数を外部に公開したい場合は、モジュールに対応するヘッダーファイルにextern宣言を追加する必要があります。

繰り返しになりますが、各モジュールに対応するヘッダーファイル（.cファイル）を持つことは、多くのヘッダーファイルにあるように思われます。

4

6 に答える 6

3

acファイルにもahを含めるとさらに良いでしょう。このようにして、コンパイラーは宣言と定義が互いに一致することを確認できます。

a.h
-----
extern int x;

a.c
----
#include "a.h"  <<--- add this
int x;

b.c
---- 
#include "a.h"

このルールの理由は、ご想像のとおり、コンパイラを使用して実行内容を確認する必要があるためです。細部が細かいので、はるかに優れています。

xあらゆる場所でextern宣言を許可すると、他のタイプに変更したい場合に問題が発生します。すべてを見つけるためにスキャンする必要がある.cファイルの数はいくつextern int xですか？たくさん。そうすると、いくつかのextern char xバグも見つかる可能性があります。おっと！

ヘッダーファイルに宣言を1つだけ含め、必要な場所にインクルードするだけで、多くの問題を回避できます。実際のプロジェクトでxは、とにかくヘッダーファイルの要素はだけではないため、ファイル数を節約することはできません。

于 2013-02-08T12:13:28.437 に答える
1

2つの理由があります。

  1. 変数を共有する場合、それは自分のファイルにないためです。そのため、ヘッダーファイルにを追加して、共有されていることを明確にする必要があります。そうすれば、宣言externを検索する場所は[インクルードディレクトリ]が1つだけになります。extern。
  2. externこれにより、誰かが宣言を行い、次に他の誰かが同じものに対して異なる（異なるタイプまたは属性を使用する場合のように）extern宣言を行うことを回避します。少なくとも[関連する]ヘッダーファイルにある場合は、すべてのファイルが同じ宣言を使用します。
  3. タイプを変更することにした場合、変更する場所は2つだけです。同じ変数を使用する「cc」ファイルを追加し、それではint不十分であると判断した場合はlong、必要です。2つではなく、3つすべてを変更する必要があります。 「ac」、「bc」、「cc」のそれぞれに含まれるヘッダーファイル。

モジュールのヘッダーファイルを用意することは、間違いなく悪い考えではありません。ただし、状況によっては、extern既存のヘッダーファイルにを入れることはもちろん許容できます。

externを使用するよりも多くの場合、より良い選択である代替手段は、getter function変数をフェッチする、を使用することです。そうすれば、変数はそれ自体のソースファイルで静的になり[「名前空間の汚染」はなく、変数の型もはるかに明確に定義されます。コンパイラは、変数を誤って使用しようとしているかどうかを検出できます。

編集：Linuxのコーディングスタイルは「良い」理由であるということを指摘する必要がありますが、Linuxソースコードの一部ではないコードがさまざまな方法でそれらのルールを破ることができないという意味ではありません。私は確かにLinuxのフォーマットを使用して独自のコードを書くことはありません-私{ }は単一のステートメントの周りに余分なものが好きです、そして私は（ほぼ）常に{新しい行を、中括弧が属するものと一致して、そして}同じ列に再び入れます。

于 2013-02-08T12:06:14.677 に答える
0

私が常にextern宣言を.hに配置する理由の1つは、コードの重複を防ぐためです。特に、「ac」コードを使用し、「x」にアクセスする必要のあるコードがさらにある場合、または存在する可能性がある場合はそうです。その場合、すべてのファイルにextern宣言が必要になります。

もう1つの理由は、extern宣言がモジュールのインターフェイスの一部であるため、ヘッダーファイル内の他のインターフェイス情報と一緒に保持することです。

于 2013-02-08T11:49:03.793 に答える
0

あなたの推測は正しいです：コードの再利用と一貫性を最大限にするには、（パブリック）宣言をヘッダーファイルに入れる必要があります。

繰り返しになりますが、各モジュールに対応するヘッダーファイル（.cファイル）を持つことは、多くのヘッダーファイルにあるように思われます。

その後、それに慣れます。それは論理的な概念であり、適応するための良い習慣です

于 2013-02-08T11:56:04.763 に答える
0

extern宣言をヘッダーファイルに配置する必要がある理由については、正しい理由があります。そのため、さまざまな翻訳ユニット間で簡単にアクセスできます。

また、各.cファイルに対応する.hファイルが含まれている必要はありません。モジュール分離の設計によっては、1つの.hファイルが適切な数の.cファイルに対応する場合があります。

于 2013-02-08T11:57:08.600 に答える
0

繰り返しになりますが、各モジュールに対応するヘッダーファイル（.cファイル）を持つことは、多くのヘッダーファイルを持つように思われます。

あなたが言ったように、ヘッダーファイルのアイデアは単純です。これらには、モジュールが他のモジュール（他の.cファイルに含まれている）にエクスポート（利用可能）するパブリックインターフェイスが含まれています。これには、構造体と型、および関数宣言を含めることができます。これで、モジュールが他のモジュールで使用できるようにする変数を定義する場合、ヘッダーファイル内の他のパブリック部分にインクルードすることは理にかなっています。これが、externがヘッダーファイルに含まれる理由です。これらは、モジュールが公開したいものの一部にすぎません。そうすれば、ヘッダーファイルをインクルードするだけで、誰でもこのパブリックインターフェイスをインクルードできます。

.cファイルごとに.hファイルを作成することは多くのように思えるかもしれませんが、それは正しいことかもしれません。ただし、モジュールがそのコードを複数の.cファイルに実装し、その集約パブリックインターフェイスを単一の.hファイルにエクスポートすることを選択する場合があることに注意してください。ですから、それは実際には厳密な1対1のことではありません。本当の抽象化は、モジュールによって提供されるパブリックインターフェイスの抽象化です。

于 2013-02-08T15:21:21.660 に答える