递归火山软件开发平台

标题: 我发现一个问题。 [打印本页]

作者: server 时间: 2022-9-12 22:10
标题: 我发现一个问题。
本帖最后由 server 于 2022-9-12 22:12 编辑

当下也有不少有识之士，共同完善野库。我想表达的意思是：嵌入式参数 @匹配方法完全是多余，反而增加不便。

同时
取变量地址（）、【@ (INT_P)&@<变量数据> 】
取静态方法地址（）【@ (INT_P)&@<所欲处理的方法>】

你会发现他都是使用了一个取址符 & 跟易语言那边一样。
同时他也的确是C++基础语法。

反正也是翻译编译。何不一步到底，完全没必要分叉走到底。

明明封装一个call（）方法，就可以了。
结果还得封城成2个。一个参数要求方法，一个参数要求变整数。

为什么不能直接封城城一个了呢？
call（被调用方法）
call（取静态方法地址（被调用方法））

call（&被调用方法）

高下立判么。
而且，同志们都在日思夜盼  【参考】也同时解决。
方法（&变量）

话说到这里，再多句嘴。易语言那种参考，千万不要在火山这边实现。一个导入DLL API，搞几十个版本。烦死。

作者: 小蜗牛 时间: 2022-9-12 22:24
本帖最后由小蜗牛于 2022-9-12 22:25 编辑

为了减少语法差异,c++有 & 如果别的语言没有...就不好办了

作者: 创世魂 时间: 2022-9-13 07:03
二楼正解。
&并不是每个语言都有的，去符号化更容易适配多种语言。减少编译器开发成本。

欢迎光临递归火山软件开发平台 (https://bbs.voldp.com/)