Visual C++中Additional Include与#using Directories的区别、用法及构建影响

Alright, let’s clear up the confusion between these two Visual C++ project settings—they’re easy to mix up, but they serve totally different roles. I’ll break down their core differences, when to use each, and how they affect your build process.

These two settings target distinct file types and operate at different stages of the compilation pipeline:

Additional Include Directories (/I[path]) #

• Purpose: This tells the C++ preprocessor where to locate header files (.h, .hpp, .inl, etc.) referenced via #include directives. It’s all about resolving textual code inclusion during preprocessing.
• Behavior: When the preprocessor hits an #include that isn’t in the current source directory or system default paths, it scans the directories listed here to find the file. The content of the header is directly inserted into your source code before compilation.

Additional #using Directories (/AI[path]) #

• Purpose: This is exclusive to managed C++ (C++/CLI) and Windows Runtime development. It directs the compiler to find .NET assemblies (.dll, .exe) or Windows Metadata files (.winmd) referenced with the #using directive.
• Behavior: Instead of textual inclusion, the compiler loads these assemblies to read their metadata—resolving managed types, methods, and dependencies needed for interop with .NET or WinRT code. This isn’t about inserting code; it’s about linking against managed metadata.

Knowing when to use each setting will save you from frustrating build errors:

• Additional Include Directories:

  • For native C++ projects: When you need to include third-party library headers (e.g., opencv2/core.hpp from an OpenCV install) or project-specific headers that aren’t in the current directory.
  • When you get a compiler error like fatal error C1083: Cannot open include file: 'myheader.h': No such file or directory.
  • For system headers that aren’t in VS’s default include paths (though VS usually handles system libraries automatically).

• Additional #using Directories:

  • When writing C++/CLI code that interacts with .NET frameworks or custom managed assemblies (e.g., referencing System.Data.dll for database operations).
  • For UWP/WinUI development: To reference Windows Runtime components packaged as .winmd files.
  • When you see errors like error C2871: 'System' is not a namespace or fatal error C1083: Cannot open type library file: 'mymanagedassembly.dll'.

These settings affect different parts of the build process, so their performance and linker implications vary:

Linker Impact #

• Additional Include Directories: No direct effect on the linker. The preprocessor’s job is to include header content into source files, which are then compiled into object files. The linker only cares about object files and explicit library references set in other settings (like Additional Dependencies).
• Additional #using Directories: Directly impacts the managed linker stage. When you reference an assembly via #using, the compiler adds a dependency on that assembly to your output (e.g., a C++/CLI DLL will list the managed assembly in its dependencies). If the assembly can’t be found during linking, you’ll get a linker error about missing metadata or unresolved managed references.

Build Time Impact #

• Additional Include Directories: More paths mean the preprocessor has to scan more locations to find headers. A long list of unnecessary include directories can slow down preprocessing, especially if the directories are deeply nested or on slow storage. Optimize by only adding paths you actually need, and use relative paths where possible.
• Additional #using Directories: Loading and parsing assembly metadata adds small overhead, but it’s generally minimal unless you reference dozens of large assemblies. The compiler caches metadata for unchanged assemblies, so subsequent builds will be faster. Avoid adding unused paths here—they force the compiler to check directories for assemblies you don’t use, wasting time.

内容的提问来源于stack exchange，提问作者Buddhika