📖 Intoduction

This page describes an overview of the capacities and limitations of this project.

---

✨ Features

• ✅ Single source of truth for string literals
• ✅ Zero runtime cost
• ✅ No heap allocation
• ✅ No UTF transcoding at runtime
• ✅ Full support for \uXXXX and \UXXXXXXXX
• ✅ Works with custom character typedefs
• ✅ Header-only
• ✅ C++20 compliant
• ✅ C++17 compliant (not all features)
• ✅ C++14 compliant (not all features, uses custom wrapper to replace std::basic_string_view)
• ✅ C++11 compliant (not all features, uses custom wrapper to replace std::basic_string_view)

---

❓ Motivation

C++ does not allow templating string literal prefixes:

make_str<char16_t>("hello"); // ❌ impossible

This leads to duplicated literals like:

"hello"
u"hello"
U"hello"

utf42 solves this by:

1. Letting the compiler generate all encoded variants of a literal
2. Selecting the correct one at compile time based on the requested character type

---

📦 Requirements

• C++11
  • Uses SFINAE to implement the templates
  • Some features of the custom string view wrapper can not be made constexpr
• C++14
  • Uses SFINAE to implement the templates
• C++17 or later
  • if constexpr
• C++20 or later (if available defines extra features):
  • char8_t
  • consteval
  • Concepts
• Recommended UTF-8 encoded source files
• A compiler with proper Unicode literal support (GCC, Clang, MSVC)

---

⚠️ Important limitations

The macro make_poly_enc(CharacterType, lit) must be used with string literals only. Any other input will result in undefined behavior.

• No runtime strings
• No dynamic encoding conversion
• No grapheme-cluster or text-shaping logic
• This library operates strictly at the code-unit level.

Such as:

make_poly_enc(char16_t, "OK");     // ✅ valid
make_poly_enc(char16_t, someVar);  // ❌ undefined behavior

---

🧠 Design philosophy

• Header only library
• Let the compiler handle Unicode parsing
• Prefer compile-time work over runtime work
• Avoid unnecessary abstraction or dependencies
• Keep the API minimal, explicit, and fast

Ideal use cases include:

• Logging systems
• Localization keys
• Cross-platform APIs
• Performance-critical code
• Compile-time configuration strings