递归火山软件开发平台

标题: 憋不住讲讲那些愤青在想的事情。 [打印本页]

作者: urenai 时间: 2022-7-19 00:43
标题: 憋不住讲讲那些愤青在想的事情。
愤青们大致就恨铁不成钢。
所谓重口难调，说这话也不对，因为大家的诉求是一致的。
这编程呢，就好比我们的学业：
1年级、2年级、3年级、、、、初中、高中、大学、考博考研、、、、
你看哦，学校也没规定你如果上学就必须学到死吧。
就算你只上个幼儿园就辍学了，难道学校就不运转了？

再说：
象棋等级1/2/3/4/5/6/7/8/9/10级
我只用3成功力，影响【象棋本身所存在所具备的实力、技术含量吗？】

再说：
先有的C++还是先有的Java？
先有的C++还是先有的QT？
先有的C++还是先有的phyton？
先有的C++还是先有的Delphi？
先有的C++还是先有的、、、、
我就想知道这些个编程语言怎么就有人用了，好好的C++不用，去用什么Java、phyton、、、、

再说：个人学识的止步阻止不了世界的进步。这点你得认同。

火山最大的优势(不是优点)本土中文用语化。
你比喻说，只要不是傻子，脑子不犯抽，我告诉你：无符号整数、整数；这2个用语，
你在脑子里的第一构想[无符号整数]就是一个数字如123前面没有-号，是一个正数。正数前面不需要+号，2年级的知识。
剩下的就是专业知识，4字节正数约42E+；

再说：
你在火山、易语言、C++
代码：A=A+1 在编译器最终结果EXE内存执行代码都是一样的，C++ 的变量++ 也一样，不信的可以自己看。

再给一个我自认为结构体最终完善结果，可借鉴嵌入式方法的替换方法；

(, 下载次数: 69)

保留现有的结构定义类前提下，如果结构体存在 @输出名，那么参数就必须附带 @输出类型和 @输出名，这样在编译的时候，直接拷贝定义成C++ 类型，
完美解决自定义数据类型过度。
@吴老板啊，你嵌入式方法这种替换都这么六了，结构体给替换下应该没问题吧。

作者: zhqyong 时间: 2022-7-19 05:05
如果接纳你的建议，功劳怎么算？你的还是谁的？

作者: 创世魂 时间: 2022-7-19 07:09
本帖最后由创世魂于 2022-7-19 07:13 编辑

结构体是个复杂的问题，后面估计会专门花时间来解决……暂时也顾不上处理。
如果类型要这么搞那就没必要了。。直接上自定义基本类型就行了……

作者: urenai 时间: 2022-7-19 11:14

zhqyong 发表于 2022-7-19 05:05
如果接纳你的建议，功劳怎么算？你的还是谁的？

你不要瞎闹，提意见的多了，给TX提意见的也有，没见马化腾分股份出去。你歇着。

作者: urenai 时间: 2022-7-19 11:33

创世魂发表于 2022-7-19 07:09
结构体是个复杂的问题，后面估计会专门花时间来解决……暂时也顾不上处理。
如果类型要这么搞那就没必要了 ...

我认为吴老板不直接使用自定义类型，极有可能是数据原始结构结构类型匹配问题。
你比喻说：NtQuerySystemInformation这个NT函数，他支持多个结构体，不同成员结构，每个成员数据类型又极有可能不同。

这就导致自定义类型不好匹配原始结构体。故不能直接使用自定义。

作者: zhqyong 时间: 2022-7-19 12:40

urenai 发表于 2022-7-19 11:33
我认为吴老板不直接使用自定义类型，极有可能是数据原始结构结构类型匹配问题。
你比喻说：NtQuerySystem ...

言之有理，意思就是太复杂，不好掌控。

作者: 飞扬工作室 时间: 2022-7-19 13:29
现在所有火山类都必须以"对象类"作为最终基础类,以保证所有类都有最基本的同一特征,就像java的"Object"一样,所以c++的结构真不好处理,要直接支持它系统复杂度将上升几个指数级. 目前还没有想到万全之策,但是充分利用火山的嵌入代码机制也能基本解决问题,譬如基本类库里面提供的"结构基础类",不知道你仔细研究过没有,我个人认为是可以很便捷地解决大多数结构体问题的.

作者: 350246356 时间: 2022-7-19 13:48

飞扬工作室发表于 2022-7-19 13:29
现在所有火山类都必须以"对象类"作为最终基础类,以保证所有类都有最基本的同一特征,就像java的"Object"一样 ...

他的 @输出类型可以考虑下或者火山完善下数据类型将[无符号][有符号]的基础数值类型完善下吧~

还有一个就是火山的变量和参数的 [参考] 希望也能设计一下。

现如今都在封库阶段，但封库固然重要如果能先完善火山的功能这样封库人员就省时省力了，后续如果支持的话代码也不再需要过多的变动！

作者: 一代码农 时间: 2022-7-19 13:56
本帖最后由一代码农于 2022-7-19 17:37 编辑

飞扬工作室发表于 2022-7-19 13:29
现在所有火山类都必须以"对象类"作为最终基础类,以保证所有类都有最基本的同一特征,就像java的"Object"一样 ...

那个是大色的产物吧
每个结构体都那么封装那不麻烦死了，而且并不适用于所有场景，另外不支持数组吧，示例上没见着
要是按结构基础类那样写，还不如直接对结构体赋值来的方便。基础的可以直接按下面的写法
RECT rect;
rect.left=@<左边>；
类似于这种。

作者: 1185907650 时间: 2022-7-19 14:07
确实有待优化

作者: jiaozhu 时间: 2022-7-19 21:56
确实，结构体一直是我用火山最头疼的,要是能解决掉就好了

作者: qaz2428119 时间: 2022-7-20 09:56
用火山编程太多地方用到结构体了,尤其是自定义结构体,
还有个痛点就是类回调,也是让大多数火山编程者头疼

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