VS2019单解决方案内C++跨项目LNK2019链接错误求助

Hey there! Let's tackle your two main issues: the unresolved external symbol errors with your Lexer tests, and whether your current test-app coupling approach is appropriate.

一、排查LNK2019链接错误 #

Your Lexer is a template class, and this is the root cause of your LNK2019 errors. Template code has a unique compilation rule: the compiler needs access to the full template implementation (not just declarations) at the point of instantiation. Here's why your setup is failing and how to fix it:

1. Why the error happens #

You've split the Lexer template's declaration in lexer.h and implementation in lexer.cpp. When your test project uses Lexer<std::stringstream>, the compiler can't see the template function definitions in lexer.cpp during instantiation, so it doesn't generate the corresponding machine code. The linker then can't find those symbols when building the test executable.

2. Fix options #

Option 1: Move template implementations to the header file

This is the most common approach for template classes. Cut all the template function definitions from lexer.cpp and paste them directly into lexer.h, right after the Lexer struct declaration. For example:

// lexer.h
#pragma once
// ... existing declarations ...

// Add template implementations here
template <typename InputStream>
bool Lexer<InputStream>::LexerIteratorEnd::operator!=(LexerIteratorEnd ignored) {
 return false;
}

template <typename InputStream>
Lexer<InputStream>::LexerIterator::LexerIterator(LexerIterator& other) : lexer_{ other.lexer_ } {}
// ... rest of the template functions ...

This way, any code that includes lexer.h will have full access to the template implementation, allowing the compiler to instantiate the exact version you need (like Lexer<std::stringstream>).

Option 2: Explicitly instantiate the template in lexer.cpp

If you want to keep the declaration/implementation split, add an explicit instantiation for the template types you use at the end of lexer.cpp:

// lexer.cpp
// ... existing template implementations ...

// Explicitly instantiate Lexer for std::stringstream (the type used in your test)
template struct Lexer<std::stringstream>;

This tells the compiler to generate the machine code for Lexer<std::stringstream> when compiling lexer.cpp, so the linker can find it later.

3. Bonus: Fix small code issues in Lexer #

While you're at it, fix these minor bugs that might cause unexpected behavior:

• In LexerIterator::operator++(), you call lexer_.next() but your Lexer class only has an advance() method. Change this to lexer_.advance();.
• The constructor LexerIterator(Lexer<InputStream> lexer) takes a Lexer by value, which creates a copy. Since lexer_ is a reference, it will bind to this temporary copy, leading to a dangling reference. Change it to take a reference:

  LexerIterator(Lexer<InputStream>& lexer) : lexer_{ lexer } {}
  

二、测试与应用的耦合方式建议 #

Current approach (adding all app source files to test project) #

• Pros: Simple to set up, works well for small projects like yours right now. No need to deal with library linking or export macros.
• Cons: High coupling. As your project grows, the test project will have to recompile all app code every time you make a change, even if only a small part of the app is modified. It also makes it harder to enforce separate build configurations for the app and tests.

Recommended规范 approach #

For long-term maintainability, switch to a static library + test project setup:

1. Convert your luacalls app project to a static library:
   • In Visual Studio, right-click the luacalls project → Properties → General → Set "Configuration Type" to "Static Library (.lib)".
   • Remove any main() function from the library project (since libraries don't have entry points).
2. Update the luacalls-tests project:
   • Add a reference to the luacalls static library project.
   • Ensure the test project includes the necessary header files from luacalls.
   • Link against the static library (Visual Studio will handle this automatically if you add the project reference).

Benefits of this setup #

• Lower coupling: The test project only depends on the library's public headers and compiled .lib file, not the individual source files.
• Faster builds: Only modified parts of the library are recompiled, and the test project only links against the pre-built library.
• Cleaner structure: Separates application logic from test code, making it easier to scale the project later (e.g., adding a dynamic library version or multiple test suites).

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