对象数组 自定义排序
本帖最后由 小蜗牛 于 2026-1-15 09:04 编辑由于火山没有把对象数组的获取指针函数公开,所以需要修改火山的头文件.
文件位于:
\plugins\vprj_win\classlib\sys\base\libs\win_base\include\vol_array.h
在 648 行后面添加: inline_ CVolObject** GetData() { return m_arypObjects.GetData(); }
缺点是每次更新都要修改..
优点是排序要方便一点..如果要文本排序 就是 比较结果 = 文本比较 (成员A.姓名,成员B.姓名) < 0
火山要好用,就要深度封装,而要封装的时候,很多因为火山的各种原因.实现不了..
从而导致有些功能用C++比火山写起来还更方便N倍..
<火山程序 类型 = "通常" 版本 = 1 />
方法 w_数组_排序 <公开 静态
@嵌入式方法 = "has_body = true\r\nbody_header = \"@none\"\r\nbody_tail=\"\r\n return 排序_比较结果;\r\n });\r\n}\"">
参数 要排序的数组 <@需求类型 = 可写入变量 @匹配类型 = 通用型>
参数 成员A <编辑时信息 = "8BFF7, 0, 0, 0" @需求类型 = 可写入变量 @匹配类型 = 所有类型>
参数 成员B <编辑时信息 = "8BFF7, 0, 0, 0" @需求类型 = 可写入变量 @匹配类型 = 等于前参数值类型>
参数 返回比较结果 <类型 = 逻辑型 注释 = "不需要注释.但是必须被赋值." 注释 = " > 从大到小" 注释 = " < 从小到大" @需求类型 = 可写入变量>
{
@ {
@ BOOL& 排序_比较结果 = @<返回比较结果>; //这里写固定名称是因为,火山不能在编辑器里写后面的代码,只能在嵌入式方法属性里写,但它又不支持@sn<rand_namexxxxxx>
@ @pdt<要排序的数组>& @sn<rand_name0> = @<要排序的数组>; // @sn<rand_name0> 好看还是 @xx<自定义名称好看>
// 把 要排序的数组指针 强转为 数据类型*
// 由于火山没有把对象数组的获取函数公开,所以需要修改火山的头文件.
// \plugins\vprj_win\classlib\sys\base\libs\win_base\include\vol_array.h
// 在 648 行后面添加: inline_ CVolObject** GetData() { return m_arypObjects.GetData(); }
@ INT_P* start = (INT_P*)@sn<rand_name0>.GetData ();
@ INT_P* end = start + @sn<rand_name0>.GetCount (); // 计算结束指针
@ std::sort(start, end, [&](INT_P @sn<rand_name1>, INT_P @sn<rand_name2>){
// 把指针转为引用对象.
@ @pdt<成员A>& @<成员A> = *(@pdt<成员A>*)@sn<rand_name1>;
@ @pdt<成员B>& @<成员B> = *(@pdt<成员B>*)@sn<rand_name2>;
}
看出来了，为了绕过火山限制，整了不少活 小小小小鸟 发表于 2026-1-15 09:33
看出来了，为了绕过火山限制，整了不少活
我没理解的一点就是..C++那么优秀的标准库..火山为啥要自己重复造轮子,自己实现一套..比如文本型.数组..等等...从而导致很多C++生态不能直接用.而且性能也没有标准库的高.虽然说可以用别名类. 这种场景我觉得使用标准数组类+三方库比较好，在火山里也能写接近原生C++的代码。我之前发的这个帖子，能在火山C++17标准下使用C++20的投影算法：火山标准数组扩展类, 一行代码排序结构体数组 小蜗牛 发表于 2026-1-15 09:42
我没理解的一点就是..C++那么优秀的标准库..火山为啥要自己重复造轮子,自己实现一套..比如文本型.数组.. ...
我是这么猜的，火山有自己的基类，有自己的内存池，在基类内部实现了内存分配等的重载，从而在跨dll或部件时传递对象不会引发内存错误，但如果在这个基础上用标准库就会很麻烦了，当初设计就是这么设计好了，后期再改就很难，基本要重构，所以在大改和打补丁之间选择了打补丁，新增本地类，之前的代码能用就用着 龙纹 发表于 2026-1-15 09:44
这种场景我觉得使用标准数组类+三方库比较好，在火山里也能写接近原生C++的代码。我之前发的这个帖子，能在 ...
:噜阿噜 确实很优秀..唯一缺点就是要写输出名..如果能捕获到输出名就好很多. 小小小小鸟 发表于 2026-1-15 09:52
我是这么猜的，火山有自己的基类，有自己的内存池，在基类内部实现了内存分配等的重载，从而在跨dll或部 ...
嗯,这就造成,很多资源不能直接使用,需要自己写一套转换.
估计是为了实现定义事件/标记值..内部需要记录...估计对象类 就是干这个事情的...
小蜗牛 发表于 2026-1-15 10:02
嗯,这就造成,很多资源不能直接使用,需要自己写一套转换.
估计是为了实现定义事件/标记值..内部需要记录.. ...
是啊，除非有大佬重新撸一套基础库，而且还得兼容火山语法，撸出来还得配套封库，太难了太难了。。 小蜗牛 发表于 2026-1-15 09:42
我没理解的一点就是..C++那么优秀的标准库..火山为啥要自己重复造轮子,自己实现一套..比如文本型.数组.. ...
:噜阿噜谁叫老吴最开始开发的是安卓的JAVA呢 小蜗牛 发表于 2026-1-15 09:55
:噜阿噜 确实很优秀..唯一缺点就是要写输出名..如果能捕获到输出名就好很多. ...
火山的语法不能直接写 类::成员名，如果能写就简单多了
页:
[1]
2