为什么std :: string不使用空指针? [英] Why doesn't std::string take a null pointer?

问题描述

我最近将空指针传递给std::string构造函数，并得到未定义的行为.我敢肯定，这是成千上万的程序员在我之前所做的事情，并且同样的错误无疑已经使数量不计其数的程序崩溃了.从使用char*的代码转换为使用std::string的代码时，它会产生很多问题，这种情况在编译时无法捕获，并且很容易在运行时单元测试中遗漏.

I recently passed a null pointer to a std::string constructor and got undefined behavior. I'm certain this is something that thousands or tens of thousands of programmers have done before me, and this same bug has no doubt crashed untold numbers of programs. It comes up a lot when converting from code using char* to code using std::string, and it's the kind of thing that is not catchable at compile time and can easily be missed in run time unit tests.

我很困惑的是这样指定std::string的原因.

What I'm confused about is the reason for specifying std::string this way.

为什么不仅仅定义std::string(NULL)==""?

效率损失可以忽略不计，我怀疑它在实际程序中是否可以衡量.

The efficiency loss would be negligible, I doubt it's even measurable in a real program.

有人知道使std::string(NULL)不确定的可能原因是什么?

Does anyone know what the possible reason for making std::string(NULL) undefined is?

推荐答案

据我所知，没有充分的理由.

No good reason as far as I know.

有人刚刚在一个月前提议对此进行更改.我鼓励您支持它.

Someone just proposed a change to this a month ago. I encourage you to support it.

std::string不是做得好的标准化的最好例子.最初标准化的版本无法实施；在彼此不一致的地方提出的要求.

std::string is not the best example of well done standardization. The version initially standardized was impossible to implement; the requirements placed on it where not consistent with each other.

在某些时候，不一致已得到解决.

At some point that inconsistency was fixed.

在c ++ 11 更改了阻止COW(写入时复制)实施的规则，这破坏了现有的合理合规的std::string的ABI.我不记得这种变化可能是解决不一致问题的地方.

In c++11 the rules where changed that prevent COW (copy on write) implementations, which broke the ABI of existing reasonably compliant std::strings. This change may have been the point where the inconsistency was fixed, I do not recall.

其API与std容器的其余部分不同，因为它不是来自同一std之前的STL.

Its API is different than the rest of std's container because it didn't come from the same pre-std STL.

对待std::string的这种传统行为作为某种考虑了性能成本的合理决策是不现实的.如果进行了任何这样的测试，那是20年前的不符合标准的std::string(因为可能不存在，因此标准不一致).

Treating this legacy behavior of std::string as some kind of reasoned decision that takes into account performance costs is not realistic. If any such testing was done, it was 20+ years ago on a non-standard compliant std::string (because none could exist, the standard was inconsistent).

由于惯性，在通过(char const*)0和nullptr时，它仍然是UB，并且将继续这样做，直到有人提出建议并证明成本很小，而收益却是不是.

It continues to be UB on passing (char const*)0 and nullptr due to inertia, and will continue to do so until someone makes a proposal and demonstrates that the cost is tiny while the benefit is not.

从文字char const[N]构造std::string已经是一种低性能的解决方案.您已经在编译时拥有了字符串的大小，并将其放在地面上，然后在运行时遍历缓冲区以找到'\0'字符(除非进行了优化；如果这样，则null检查同样可以优化).高性能解决方案包括知道长度并告诉std::string长度，而不是从'\0'终止的缓冲区进行复制.

Constructing a std::string from a literal char const[N] is already a low performance solution; you already have the size of the string at compile time and you drop it on the ground and then at runtime walk the buffer to find the '\0' character (unless optimized around; and if so, the null check is equally optimizable). The high performance solution involves knowing the length and telling std::string about it instead of copying from a '\0' terminated buffer.

这篇关于为什么std :: string不使用空指针?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！