递归火山软件开发平台

 找回密码
 立即注册

QQ登录

只需一步,快速开始

搜索
热搜: 火山 源码 类库
查看: 3005|回复: 5
打印 上一主题 下一主题

[视窗] 火山PC的各种文本数组类的区别和使用场景

[复制链接]

8

主题

135

帖子

1110

积分

金牌会员

Rank: 6Rank: 6

积分
1110
跳转到指定楼层
楼主
发表于 2024-6-9 10:41:35 | 只看该作者 |只看大图 回帖奖励 |倒序浏览 |阅读模式
火山PC系统有 文本数组类文本标准数组类高性能文本数组类;
请教一下他们都有什么区别?
什么场景下使用它们比较好呢?
目前我用的较多的是文本数组类,因为常用到全局方法 分割文本() 方法,而这个方法只支持使用文本数组类来接收分割结果。


回复

使用道具 举报

75

主题

1113

帖子

4936

积分

核心用户

Rank: 9Rank: 9Rank: 9

积分
4936
沙发
发表于 2024-6-9 11:15:59 | 只看该作者
本帖最后由 hcwanz 于 2024-6-9 11:25 编辑

文本数组类//专门为火山文本类做的
文本标准数组类//封装的c++vector
回复

使用道具 举报

28

主题

2079

帖子

7589

积分

核心用户

Rank: 9Rank: 9Rank: 9

积分
7589
板凳
发表于 2024-6-9 11:29:37 | 只看该作者
文本数组类是吴总自己写的数组类,实际成员类型是文本指针,而不是文本型,所以每次取成员,都会将文本指针复制到一个新的文本型里。
文本标准数组类是基于STL标准库里的std::vector,成员类型是文本型,取成员后只要不赋值,就不会有额外的拷贝。
但以上两者效率相差不大,用哪个都可以。如果是传文本数组给C的函数,第一种会更好使。

高性能文本数组类备注上的那句「作用和"文本数组类"一致,但性能更高.」,你可以认为是胡说的。
这个类是用来配合大色封装的 MMKV,由于大色把 MMKV 改成了 dll,也没有提供源码,根据 MMKV 的源码,我猜它内部应该是 std::vector<std::string>。
火山的文本型是 UTF-16LE 编码,MMKV 里的 std::string 是 UTF-8 编码,所以这个高性能文本数组类加入成员和取成员都要做一次编码转换,谈不上啥性能。
除了配合高性能键值表之外,不应该单独使用。

评分

参与人数 1金钱 +5 收起 理由
Lruc + 5 很给力!

查看全部评分

回复

使用道具 举报

8

主题

135

帖子

1110

积分

金牌会员

Rank: 6Rank: 6

积分
1110
地板
 楼主| 发表于 2024-6-9 19:33:15 | 只看该作者
谢谢各位老师的解答!!
回复

使用道具 举报

16

主题

150

帖子

1719

积分

金牌会员

Rank: 6Rank: 6

积分
1719
5#
发表于 2025-1-27 00:39:20 | 只看该作者
Xelloss0618 发表于 2024-6-9 11:29
文本数组类是吴总自己写的数组类,实际成员类型是文本指针,而不是文本型,所以每次取成员,都会将文本指针 ...

似乎文本数组类.取成员()取出来的文本是一个副本,与数组里的没有关系了,如果是文本指针的话是不是应该像对象数组类的取成员()一样有一个返回参考的属性。

回复

使用道具 举报

28

主题

2079

帖子

7589

积分

核心用户

Rank: 9Rank: 9Rank: 9

积分
7589
6#
发表于 2025-1-27 12:48:35 | 只看该作者
zlk 发表于 2025-1-27 00:39
似乎文本数组类.取成员()取出来的文本是一个副本,与数组里的没有关系了,如果是文本指针的话是不是应该 ...

返回参考也没用,文本指针到文本型,必然会复制数据,产生副本。
当然,文本数组类其实也可以自己改一下,让它直接返回文本指针,但直接操作指针不安全,所以吴总没封装出来。
现在你可以用「文本标准数组类」,里面的成员就是文本型。

评分

参与人数 1金钱 +5 收起 理由
zlk + 5 很给力!

查看全部评分

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|小黑屋|递归火山软件开发平台 ( 鄂ICP备18029190号 )

GMT+8, 2025-3-4 01:35 , Processed in 0.098498 second(s), 21 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表