标准库类型的赋值运算符的ref限定词 [英] ref-qualifiers for the assignment operator of standard library types

查看:107
本文介绍了标准库类型的赋值运算符的ref限定词的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想知道,是否有原因导致标准类型的赋值运算符不符合左值引用的条件?他们都不是.

I was wondering, is there a reason the assignment operator of standard types is not lvalue ref-qualified? None of them are.

因此,我们可以编写如下代码:

Because of that, we can write things such as this:

std::string{} = "42";
std::string s = "hello " + std::string{"world"} = "oops!";

std::vector<int> v = { 1,2,3 };
std::move(v) = { 4,5,6 };

如果赋值运算符是左值ref限定的,那么所有这些示例将无法编译.

If the assignment operator was lvalue ref-qualified all of these examples would not compile.

是因为有很多要修改的东西(但是后来就没例外了),没有人写提案吗?我不认为人们会像这样编写代码,但是图书馆的设计不应该不允许它吗?

Is it because there's a lot of things to modify (but then so it was for noexcept) and nobody wrote a proposal for? I don't think people write code like this but shouldn't the library be designed so that it doesn't even allow it?

推荐答案

您的建议是.

Your suggestion was proposed in 2009, and ultimately rejected in Frankfurt that year over "concerns about backwards compatibility".

这将是一个巨大的变化,我们不喜欢这些.

It would have been a breaking change, and we don't like those.

无论如何,现有禁止分配内置类型右值的禁令仅具有有限的实际价值,因此可能破坏现有代码的成本为.

The existing prohibition against assigning to rvalues of built-in types is only of limited real value anyway, so the cost of potentially breaking existing code was almost certainly deemed to be "not worth it".

如果我们的表盘整洁,是否会以这种方式设计图书馆?也许.

Would the library be designed in this manner if we had a clean slate? Perhaps.

这篇关于标准库类型的赋值运算符的ref限定词的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆