3

ほとんどの C++ クラス メソッド シグネチャは、通常はヘッダー ファイル内の宣言と、私が読んだコードのソース ファイル内の定義との間で重複しています。この繰り返しは望ましくなく、このように記述されたコードは参照の局所性が低いことに悩まされています。たとえば、ソース ファイルのメソッドは、ヘッダー ファイルで宣言されたインスタンス変数を参照することがよくあります。コードを読むときに、ヘッダー ファイルとソース ファイルを常に切り替える必要があります。

そうしないようにする方法を誰かが推奨しますか？それとも、通常の方法で物事を行わないことで、主に経験豊富な C++ プログラマーを混乱させるつもりですか?

質問 538255 ヘッダー ファイル内の C++ コードも参照してください。

4

5 に答える 5

9

別の方法がありますが、治療法は病気よりも悪いです — すべての関数本体をヘッダーで定義するか、C# のようにクラスでインライン化することさえできます。欠点は、これによりコンパイル時間が大幅に増大し、ベテランの C++ プログラマーを悩ませることです。また、循環依存という厄介な状況に陥る可能性もあります。これは解決可能ですが、対処するのが面倒です。

個人的には、IDE を縦に分割するように設定し、ヘッダー ファイルを右側に、ソース ファイルを左側に配置しました。

于 2009-10-30T11:26:43.067 に答える
6

I assume you're talking about member function declarations in a header file and definitions in source files?

If you're used to the Java/Python/etc. model, it may well seem redundant. In fact, if you were so inclined, you could define all functions inline in the class definition (in the header file). But, you'd definitely be breaking with convention and paying the price of additional coupling and compilation time every time you changed anything minor in the implementation.

C++, Ada, and other languages originally designed for large scale systems kept definitions hidden for a reason--there's no good reason that the users of a class should have to be concerned with its implementation, nor any reason they should have to repeatedly pay to compile it. Less of an issue nowadays with faster systems, but still relevant for really large systems. Additionally, TDD, stubbing and other testing strategies are facilitated by the isolation and quicker compilation.

于 2009-10-30T11:29:34.950 に答える
4

慣習を破らないでください。最終的には、あまりうまく機能しないワームのボールを作成します。さらに、コンパイラはあなたを嫌うでしょう。C/C++ は、何らかの理由でそのように設定されています。

于 2009-10-30T11:18:29.493 に答える
3

C++ 言語は関数のオーバーロードをサポートしています。これは、関数シグネチャ全体が基本的に特定の関数を識別する方法であることを意味します。このため、関数を個別に宣言および定義する限り、パラメーターを再度リストする必要があるという冗長性は実際にはありません。より正確には、パラメーターの型をリストする必要があることは冗長ではありません。一方、パラメーター名はこのプロセスでは何の役割も果たさず、宣言 (ヘッダー ファイルなど) で自由に省略できますが、これにより読みやすさが制限されると思います。

于 2009-10-30T14:10:22.217 に答える
0

You "can" get around the problem. You define an abstract interface class that only contains the pure virtual functions that an outside application will call. Then in the CPP file you provide the actual class that derives from the interface and contains all the class variables. You implement as normal now. The only thing this requires is a way to instantiate the derived implementation class from the interface class. You could do that by providing a static "Create" function that has its implementation in the CPP file.

ie

InterfaceClass* InterfaceClass::Create()
{
     return new ImplementationClass;
}

This way you effectively hide the implementation from any outside user. You can't, however, create the class on the stack only on the heap ... but it does solve your problem AND provides a better layer of abstraction. In the end though if you aren't prepared to do this you need to stick with what you are doing.

于 2009-10-30T11:33:27.887 に答える