4

この回答によると、ブーストヘッダーとSTLヘッダーは、プリコンパイル済みヘッダーファイル（stdafx.hMSVCの世界）に属しています。そこで、ダイナミックリンクライブラリプロジェクトのヘッダーを変更し、すべてのSTL/Boostヘッダーをプロジェクトのに移動しましたstdafx.h。

前

#include <boost/smart_ptr.hpp>

namespace XXX
{
  class CLASS_DECL_BK CExampleClass // CLASS_DECL_BK is just a standard dll import/export macro
  {
    private:
      boost::scoped_ptr<Replica> m_replica;
  }
}

後

namespace XXX
{
  class CLASS_DECL_BK CExampleClass
  {
    private:
      boost::scoped_ptr<Replica> m_replica;
  }
}

これで、コンパイル時間が短縮されるという利点がありますが、インクルードがないため（現在はmyに移動されています）、ライブラリのすべてのユーザーにビルドエラー（例：unknown boost :: scoped_ptr ...）が発生していstdafx.hます。

このジレンマの解決策は何でしょうか？

ヘッダーファイルをインクルードした後のコンパイル時間とコンパイルエラーを減らしたいのですが、dllのユーザーには受け入れられません。

これは役に立ちますか？

  • すべてのincludeディレクティブをそのままにしておきますが、それらを「stdafx.h」に複製しますか？stdafx.hは常に私のプロジェクトのcppファイル内に最初に含まれているので、問題はないはずです。ユーザーはエラーを受け取りません。または、同じヘッダーの複数のインクルードが1つの変換ユニットで発生した場合（ヘッダーガードを取得した場合）、速度の利点が失われますか？

ヒントをありがとう！

4

3 に答える 3

2

この目的のためにビルド構成を作成できます (Debug、Release、CheckDependencies)。これを変更する簡単な方法は、プリプロセッサを使用して、現在の構成に基づいてインクルードを含める/除外することです。これを使用すると、デバッグまたはリリース (より多くのインクルード セットを含む) を使用してテストおよびビルドし、配布前にすべての構成をビルドできます。

明確にするために、条件付きインクルードMON_LIBRARY_VALIDATE_DEPENDENCIESはライブラリヘッダーまたはソースでは使用されず、プリコンパイル済みヘッダーでのみ使用されます。

// my pch:
#include <file1.hpp>
#include <file2.hpp>
// ...

#if !defined(MON_LIBRARY_VALIDATE_DEPENDENCIES)
#include <boost/stuff.hpp>
// ...
#endif

次にMON_LIBRARY_VALIDATE_DEPENDENCIES、CheckDependencies 構成のプリプロセッサ定義のリストに追加します。

ガードに関して:通常の状況でガードを使用している場合は問題になりません。コンパイラは最適化を使用してこれらのケースを検出します。実際、この分野でコンパイラの裏をかこうとすると、実際には処理が遅くなる可能性があります。ライブラリ/依存関係が大きく、実際に顕著な問題がない限り、通常のままにしておくといいでしょう。

于 2011-09-02T07:58:12.230 に答える
2

header- includesをライブラリ ヘッダーにそのまま残して、追加でstdafx.h.

または、追加の定義を追加することもできます (一括外部インクルード ガード)

// stdafx.h
#define MY_LIB_STD_HEADERS_ALREADY_INCLUDED

// library_file.h
#ifndef MY_LIB_STD_HEADERS_ALREADY_INCLUDED
#include <boost/smart_ptr.hpp>
...
#endif

しかし、それが役立つと確信している場合にのみ、私はそれを行います. ストップウォッチを取り、いくつかの再コンパイルを実行してください。(リンクする必要はありません。) 次に、違いがあるかどうかを確認します。

さておき

プロジェクトのどこかに必要なすべてのブースト ヘッダーを追加することがそんなに良い考えかどうかはわかりません。私は友人、おそらくBoost.Format、...は良い考えだと思いますが、Boost.RegExpヘッダーについてはすでによく考えています。注:速度測定は行っていませんが、pch ファイルのサイズの問題とコンパイラの問題をぼんやりと覚えています。私は本当にいくつかのテストを行う必要があります。shared_ptrboost/foreach

また、問題の Boost ライブラリが転送ヘッダーを提供しているかどうか、および代わりにそれらを含める必要があるかどうかを確認してください。プリコンパイル済みヘッダー ファイルを肥大化させると、マイナス面が生じる可能性があります。

于 2011-09-02T08:01:46.740 に答える
1

コンパイル単位を自己完結型にする (使用するすべてのものを含める) ことは非常に望ましいことです。これにより、プリコンパイル済みヘッダーを使用しない他のユーザーからのコンパイル エラーが防止されます。また、ヘッダー ガードによって、これらの余分なインクルードのコストが最小限に抑えられます。

これには、ヘッダーを一目見ただけで、ユニットで使用されている他のヘッダーがユーザーにわかるという望ましい副作用と、ファジーなしで単一のユニットをコンパイルするオプションがあります。

于 2011-09-02T08:00:23.463 に答える