c++ - basic_string 文字在编译时速度更快还是处理得更好？

Question

在浏览 C++14/C++1y (n3690) 草案时，我注意到在第 21.7 节中引入了 basic_string 文字后缀:

inline namespace literals {
inline namespace string_literals {
  // 21.7, suffix for basic_string literals:
  string operator "" s(const char *str, size_t len);
  u16string operator "" s(const char16_t *str, size_t len);
  u32string operator "" s(const char32_t *str, size_t len);
  wstring operator "" s(const wchar_t *str, size_t len);
}
}

我的问题是:

• basic_string 文字是否有可能在运行时更快？
• 我的“幼稚”实现是否完全错误？
• basic_string 文字在 ROM 中的数据布局是否可以不同，或者编译时与运行时的任何其他差异？

背景

我知道这允许像这样直接使用字符串文字:

std::string s1 = "A fabulous string"s;

void sfunc(std::string arg);

int main() {
    sfunc("argument"s);
}

但是相对于依赖转换构造函数 string(const char*) 有什么优势呢？

“旧”代码如下:

std::string s1 = "A fabulous string";  // c'tor string(const char*)

void sfunc(std::string arg);

int main() {
    sfunc("argument");   // auto-conversion via same c'tor
}

据我所知，operator ""s() 的实现基本上是这样的:

std::string operator "" s(const char* lit, size_t sz) {
    return std::string(lit, sz);
}

因此，只需使用相同的 c'tor。我的猜测是，这必须在运行时完成，我错了吗？

编辑:正如Nicol Bolas在我的示例下方正确指出的那样，不使用相同的构造函数，但具有额外长度的构造函数 - - 显然，这对建筑非常有用。这给我留下了一个问题:对于编译器来说，将字符串文字放入 ROM 或在编译时进行类似操作是否更好？

Answer 1

• Is there a possibility to be faster at run-time with basic_string literals?

如前所述，字符串长度已知并自动传递给构造函数。

• Is my "naive" implementation totally wrong?

不，这是正确的。

• Can the layout of data in ROM be different with basic_string literals, or any other difference at compile-time versus run-time?

可能不是，因为相关的 basic_string 构造函数不是 constexpr 所以不符合静态初始化的条件，所以可能不能放在 ROM 中，必须在运行时完成。