- 主题:居然不能做std::string + std::string_view的操作
string_view这个坑踩吐了，废了好大劲把传进函数的const std::string&换成了std::string_view，结果发现在很大一批函数里要用传进去的字符串拼接其他的std::string，原来干干净净的连+一下刷error刷疯。
原来const std::string&还不用重建一个std::string，现在反而std::string_view需要再复制一个std::string出来。得不偿失啊...
--
FROM 115.193.190.*
std::string a = x1 + x2 + x3 + x4
原来都是const std::string&，只有x1+x2的时候return一个右值
现在是
std::string a = std::string(x1) + std::string(x2) + std::string(x3) + std::string(x4)
一下4个右值
翻了一下stackoverflow,说要么自己重载一个，要么改用
std::string a
a.append(x1).append(x2)....
【 在 here080 的大作中提到: 】
: 另外，就算你比较懒，直接写：
: a + string(b)
: 这里string(b)产生的string在传给operator+时是右值，结果会移动而不会再次复制。
: ...................
--
FROM 115.193.190.*
另外发现return string_view也挺坑啊
原来getter回传const std::string&，直接就可以用
现在回传string_view以后，如果要转换成const char*，不能保证null结尾，如果要转换成std::string还得显示构造一个临时变量，关键是很多标准库的函数都还不接受std::string_view的传入，比如<regex>里面的那些。
【 在 ziqin 的大作中提到: 】
: string_view这个坑踩吐了，废了好大劲把传进函数的const std::string&换成了std::string_view，结果发现在很大一批函数里要用传进去的字符串拼接其他的std::string，原来干干净净的连+一下刷error刷疯。
: 原来const std::string&还不用重建一个std::string，现在反而std::string_view需要再复制一个std::string出来。得不偿失啊...
--
FROM 115.192.187.*
你们不是说传string_view比const string& 效率高嘛？
按这么说的话，其实就不存在在传入的时候统一用string_view了，还得区分参数会不会被move，用string&&或者string_view，这样的话，那岂不是参数就很混乱了。
【 在 here080 的大作中提到: 】
: const char*不传size，靠null结尾，这是C的搞法。
: 这种API本来就不太快。
: 另外，getter完全可以返回const string&
: ...................
--
FROM 115.192.187.*