- 主题:不是很懂string_view的点
用第一个
string_view本身的拷贝开销小于解引用。
【 在 ziqin 的大作中提到: 】
: ok，那第二个问题是，我该用
: f( std::string_view s)
: 还是
: ...................
--
FROM 76.126.252.*
非常有必要
【 在 toutouqi 的大作中提到: 】
: 不太理解，这种有必要加一个晦涩的类吗，又不十分安全，在这上面浪费精力还不如把代码优化一下。
--
FROM 76.126.252.*
不太行。
理论上收到const int&的函数是可以记下这个地址慢慢使用的。如果该函数无法inline，那编译器是不能改函数签名的。
【 在 ble 的大作中提到: 】
: 我相信编译器会把const int&优化掉的
:
: #发自zSMTH@钛星
--
FROM 76.126.252.*
这种是程序设计问题。UB
【 在 stub 的大作中提到: 】
: 如果多线程呢，传入的虽是const，但另一个线程修改它
--
FROM 76.126.252.*
你说的这种行为，有可能编译器不需要保证它的正常运行。这就是UB的意思。
【 在 stub 的大作中提到: 】
: 所以编译器不会对这种进行优化
--
FROM 76.126.252.*
这需要你在此函数内加上sync相关的代码。
【 在 winterchill 的大作中提到: 】
: 未必啊。如果有另外一个atomic flag做synchronization是正常定义的行为。
--
FROM 76.126.252.*
加上了相关sync代码时编译器不优化和不加时编译器不优化是两个问题。不能用这个证明那个。
另外，这样写程序不管能不能跑，这个写法肯定是很有问题的。
【 在 winterchill 的大作中提到: 】
: 嗯。我的point是，这样写程序未必有问题。
--
FROM 76.126.252.*
我们讨论的是const int&啊
你这都改成atomic_bool了……
怎么不改成const shared_ptr<>& ?
【 在 winterchill 的大作中提到: 】
: 我其实不明白你为什么一直假定没有synchronization。传值就是传值，传引用就是传引用。和synchronization有什么关系吗？
: 咱们拿个例子讨论下吧。就讨论有synchronization的情况。以下spin有什么问题？
: void myprint(const std::string& str, std::atomic_bool &ready) {
: ...................
--
FROM 76.126.252.*
当然是说传进的参数就是一个const int&，函数内部也没有用到复杂类的情况。
【 在 winterchill 的大作中提到: 】
: 第一个参数。const string&。你要改成const int&也好。
--
FROM 76.126.252.*
你可以没有看完整的贴子？我们最初讨论的是优化问题。
【 在 winterchill 的大作中提到: 】
: 说实话我觉得“当然”这个词用的很不当然。你当时说“UB”的时候也没这么多限定。当然后面有什么样的后续讨论你也都可以用“当然”多加限定。我觉得说到这也没什么好争的了。
--
FROM 76.126.252.*