server 发表于 2022-9-12 22:10:39

我发现一个问题。

本帖最后由 server 于 2022-9-12 22:12 编辑

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

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

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

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

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

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

call（&被调用方法）

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


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

小蜗牛 发表于 2022-9-12 22:24:37

本帖最后由 小蜗牛 于 2022-9-12 22:25 编辑

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

创世魂 发表于 2022-9-13 07:03:14

二楼正解。
&并不是每个语言都有的，去符号化更容易适配多种语言。减少编译器开发成本。
页: [1]
查看完整版本: 我发现一个问题。