- 主题:一个简单的例子说明string_view的好处
C++98 就允许 basic_string 使用 COW,C++11 好不容易禁止了,又改回去?
再说 COW 也解决不了无 copy 引用字符串常量、无 copy 引用字符串的子串,这两个场景才是 string_view 的重点。
标准库没有 string_view 的时候,一大把 C++ 库都自己造了一个 StringRef/StringPiece/StringView,这个需求是真实存在的。
【 在 roy (天上掉大饼:学思行言) 的大作中提到: 】
: c++ 20为啥不直接把basic_string改成cow机制的,而是另外又整出一个类来?
: 然后啥时候该用string 啥时候用stringview,误用了会咋样,又增加了坑啊
--
FROM 183.60.88.*
cpp 多半不会搞 cow, 因为 cow 内部其实是个 shared_ptr<>,按 cpp 的传统艺能,应该弄个 unique_ptr<> 或者 std::move() 效率更高嘛。shared_ptr<> 弱爆了。
stringview 的用途是 split()
QVector<QStringRef> parts = s.splitRef(":");
for (QStringRef &part: parts) {
....
}
在上面这段代码里面,没有多次给临时字符串变量申请内存空间的开销。很适合用在编译器词法分析,XML 解析这类场合。
【 在 roy (天上掉大饼:学思行言) 的大作中提到: 】
: c++ 20为啥不直接把basic_string改成cow机制的,而是另外又整出一个类来?
: 然后啥时候该用string 啥时候用stringview,误用了会咋样,又增加了坑啊
--
FROM 124.72.118.*
errrr
COW是很早期的g++实现吧?
这个不是已经有共识是个非常不好的东西了呀?
【 在 roy 的大作中提到: 】
: c++ 20为啥不直接把basic_string改成cow机制的,而是另外又整出一个类来?
: 然后啥时候该用string 啥时候用stringview,误用了会咋样,又增加了坑啊
--
FROM 76.126.252.*
我觉得吧,要么像rust那样编译器保证ref不会跑出作用域;要么像大部分语言用gc。
两个都没有,那C++里最好ref从语法上一看就是ref,无论定义还是使用。从这个角度引用就不如指针。
从这个角度你可以string_view,但是如果它像iterator一样通过*,->访问的话,可能比现在这样用法特别像string好一些。
当然也有反方面意见:如果养成靠语法来识别ref的习惯,可能也挺危险的,不可靠。
【 在 vonNeumann 的大作中提到: 】
: C++98 就允许 basic_string 使用 COW,C++11 好不容易禁止了,又改回去?
: 再说 COW 也解决不了无 copy 引用字符串常量、无 copy 引用字符串的子串,这两个场景才是 string_view 的重点。
: 标准库没有 string_view 的时候,一大把 C++ 库都自己造了一个 StringRef/StringPiece/StringView,这个需求是真实存在的。
: ...................
--
修改:ilovecpp FROM 101.82.163.*
FROM 101.82.163.*
嗯,所以其实就是增加了一个immutable的string实现?
是早就该有了
【 在 vonNeumann 的大作中提到: 】
: C++98 就允许 basic_string 使用 COW,C++11 好不容易禁止了,又改回去?
: 再说 COW 也解决不了无 copy 引用字符串常量、无 copy 引用字符串的子串,这两个场景才是 string_view 的重点。
: 标准库没有 string_view 的时候,一大把 C++ 库都自己造了一个 StringRef/StringPiece/StringView,这个需求是真实存在的。
: ...................
--
FROM 219.143.13.*
“语法上一看就是ref”这解决不了C++的问题,因为你是个面向对象的语言,一个对象内部成员引用别的对象是面向对象中的常规且必要操作。这个只能靠明晰对象生存/合法周期来解决。
【 在 ilovecpp 的大作中提到: 】
: 我觉得吧,要么像rust那样编译器保证ref不会跑出作用域;要么像大部分语言用gc。
: 两个都没有,那C++里最好ref从语法上一看就是ref,无论定义还是使用。从这个角度引用就不如指针。
: 从这个角度你可以string_view,但是如果它像iterator一样通过*,->访问的话,可能比现在这样用法特别像string好一些。
: ...................
--
FROM 76.126.252.*
都生成QVector了,起码一次内存分配
真讲究效率,还是strchr函数走起吧
对于类似lex/yacc这类词法分析,在Lexer里保存一个std::vector<string*>队列
用的时候申请一个string*,clear就行,不用的时候返回
于是string数据只需要copy,无需频繁申请内存
【 在 hgoldfish (老鱼) 的大作中提到: 】
: cpp 多半不会搞 cow, 因为 cow 内部其实是个 shared_ptr<>,按 cpp 的传统艺能,应该弄个 unique_ptr<> 或者 std::move() 效率更高嘛。shared_ptr<> 弱爆了。
: stringview 的用途是 split()
: QVector<QStringRef> parts = s.splitRef(":");
: ...................
--
修改:jjfz FROM 111.197.238.250
FROM 111.197.238.250
你怎么不用string_view举例呢?
给一个absl的例子:
// Splits the given string on commas. Returns the results in a
// vector of strings. (Data is copied once.)
std::vector<std::string> v = absl::StrSplit("a,b,c", ','); // Can also use ","
// v[0] == "a", v[1] == "b", v[2] == "c"
// Splits the string as in the previous example, except that the results
// are returned as `absl::string_view` objects, avoiding copies. Note that
// because we are storing the results within `absl::string_view` objects, we
// have to ensure that the input string outlives any results.
std::vector<absl::string_view> v = absl::StrSplit("a,b,c", ',');
// v[0] == "a", v[1] == "b", v[2] == "c"
【 在 hgoldfish 的大作中提到: 】
: cpp 多半不会搞 cow, 因为 cow 内部其实是个 shared_ptr<>,按 cpp 的传统艺能,应该弄个 unique_ptr<> 或者 std::move() 效率更高嘛。shared_ptr<> 弱爆了。
: stringview 的用途是 split()
: QVector<QStringRef> parts = s.splitRef(":");
: ...................
--
FROM 76.126.252.*