Introduction

This error usually means the compiler sees a declaration related to std::basic_string, but not its full definition at the point where it must instantiate or lay out the type. In ordinary C++ code, the most common cause is simple: std::string is used in a header, but the header forgot to include <string>. The error looks template-heavy, but the fix is often just about incomplete types and include boundaries.

Why The Error Happens

std::string is a type alias built on std::basic_string<char, ...>. The compiler can sometimes see a forward declaration path for the template, but that is not enough when it needs the full class definition.

For example, this header is broken:

1// person.h
2#pragma once
3
4class Person {
5public:
6    std::string name;
7};

The problem is not the member itself. The problem is that <string> was never included, so the compiler does not know the full definition of std::string.

The Most Common Fix: Include <string>

The direct fix is to include the correct standard header in the file that uses the type.

1// person.h
2#pragma once
3#include <string>
4
5class Person {
6public:
7    std::string name;
8};

That is usually enough. A source file including person.h should not be expected to “happen” to include <string> first. Each header should include what it needs for its own declarations.

Why Forward Declarations Do Not Help Here

You can forward-declare your own classes in some situations, but std::string as a data member requires a complete type because the compiler must know layout, constructors, destructors, and more.

This is why a forward declaration or indirect declaration is not a substitute for <string> when:

• 'std::string is a member field,'
• 'std::string is used by value,'
• templates need the full type definition.

The incomplete-type trick only works in narrower cases, such as pointers or references to a forward-declared user-defined class.

A Minimal Reproduction

Here is a tiny example that triggers the general class of issue.

1// bad.h
2#pragma once
3
4struct User {
5    std::string username;
6};

1// main.cpp
2#include "bad.h"
3
4int main() {
5    User u;
6    return 0;
7}

The compiler complains because std::string is used before its full definition is made available.

Corrected version:

1// good.h
2#pragma once
3#include <string>
4
5struct User {
6    std::string username;
7};

This Often Shows Up In Objective-C++ Too

The error is common in .mm files or mixed-language Apple projects because developers include some C++ types indirectly and assume standard library types are already defined. They are not. If the header uses std::string, include <string> there explicitly.

The same rule applies in ordinary CMake, Make, or IDE-managed C++ builds. Build system complexity does not change the include requirement.

Header Hygiene Matters

A reliable rule in C++ is:

• if a header uses a type by value, include the defining header,
• if a header only uses a pointer or reference to a user-defined type, a forward declaration may be enough.

Applying that consistently prevents many “undefined template” or incomplete-type diagnostics.

When It Is Not Just <string>

Less commonly, the error can also come from:

• circular include structure that hides the needed definition,
• namespace mistakes,
• using std::string in templates before required headers are included,
• nonstandard precompiled-header assumptions.

But even in those cases, the debugging question stays the same: does the compiler see the full definition of the type at the point it needs it?

Common Pitfalls

• Using std::string in a header without including <string> there.
• Assuming another source file or precompiled header will always include the right standard header first.
• Treating standard library types as if they can be safely forward-declared for by-value use.
• Debugging the template wording instead of checking for an incomplete type problem.
• Hiding include dependencies behind fragile build-order assumptions.

Summary

• This error usually means std::string was used where its full definition was required but not included.
• The usual fix is to include <string> in the header or source file that uses std::string.
• Forward declarations are not enough for by-value std::string members.
• The diagnostic sounds template-related, but the real issue is often incomplete type visibility.
• Good header hygiene prevents this error far more reliably than build-order luck.