C++头文件内实现SHA256是否合规？何时应采用该方式？

Great question! Let's break this down clearly—putting implementation code in C++ headers is 100% compliant with the standard. The "header for interfaces, cpp for implementations" rule you learned is a common engineering best practice, not a hard requirement from the language itself.

Why do most of us split interface and implementation? #

• Faster compilation: If you change a .cpp file, only that file needs recompiling. Change a header, and every .cpp that includes it has to recompile—this makes a huge difference in large projects.
• Avoid linker errors: Non-inline, non-template functions defined in headers will cause multiple definition errors when linked, since every translation unit that includes the header gets its own copy of the function.
• Hide implementation details: Keeping code in .cpp files lets users work with just the header (the "public interface") without needing to dig into how things work under the hood.

When is header-only implementation the right call? #

1. Templates (classes or functions) #

C++ templates are instantiated at compile time, which means the compiler needs the full definition of the template to generate code for specific types. That's why you'll never see a standard library template like std::vector split into a .h and .cpp—all the code lives in the header.

2. inline functions (including class members) #

Marking a function inline tells the linker to allow multiple copies of the definition across translation units (as long as all copies are identical). This makes them safe to put in headers. Also, any member function defined directly inside a class declaration is implicitly inline, like this:

class StringUtils {
public:
    bool isEmpty(const std::string& s) { return s.empty(); } // Implicitly inline
};

3. Header-only libraries #

The SHA256 project you found is a perfect example of this. Header-only libraries are incredibly popular for their simplicity—users just need to #include the header and start using the code, no linking against external libraries required. To avoid issues, these libraries almost always use:

• Header guards (#pragma once or #ifndef ... #define ... #endif) to prevent duplicate inclusion
• inline for non-template functions, or wrap code in namespaces to avoid conflicts

4. Small, self-contained utilities #

If you have a tiny function or class (say, a 5-line helper to calculate a hash or format a string) putting it in a header makes sense. It saves users from having to link an extra .cpp file, and the compilation overhead is negligible.

Key things to watch out for #

• Always use header guards: This prevents the same header from being included multiple times in a single translation unit, which would cause compile errors.
• Don't put non-inline, non-template functions in headers: This is the #1 cause of linker errors with header-only code.
• Avoid global variables in headers: If you absolutely need one, use static (limits it to the translation unit) or inline variables (C++17 and later, allows shared definitions across units).

To circle back to your SHA256 project: that header-only approach is totally valid and practical. It's designed to be easy to drop into any project without extra setup, which is a huge plus for utility code like hashing algorithms.

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