大部分参与讨论AI问题的看官都是扯，压根没讨论到点上。
火山对接AI最大的障碍就是火山有自己的定义。火山不能自己写各种main函数，因为自身需要各种初始化。
因为此，也导致了一小部分人在开发一些软件时候会产生兼容性问题。
例如，只需要导出一个ADD函数，使用C++编译出来的顶天了也就10+KB，
但是，火山编译出来就是 小几百kb。
多出来的冗余代码太多太多，
关键是多出的冗余代码可能会导致稳定性下降。
举例：我只需要导出ADD函数，不需要gdi+ 或者 user32 之类的 库，
如果这些库跟随初始化可能会导致问题，而他却跟随初始化了。
以下为只导出1个简单ADD函数：的导入表DLL
好了言归正传
对接AI，首先自身在数据类型上要匹配。
之前发过类似的建议，X大说类型写死了,实际上，放开或许会更好，就像 哈希表声明： @模板类型；
https://bbs.voldp.com/data/attachment/forum/202403/05/65e7361b879d7.png
typedef unsigned int MyUint32;反正火山不参与最后的编译，最后还是C++编译。
火山要做的就是具备自己的特色之外，某些不太需要限制的地方尽量开通。
你尽量对封库的人有好一些。
我有此想法是因为，我经常使用AI写代码，直接嵌入火山，有的时候各种类型反复转换，实在是烦。
还有就是，当前只能 嵌入代码 引用 火山变量，火山变量无法引用嵌入代码 声明的 变量，希望更正；
@ int S = 11;
A = @>S<
我只是提出一个思想，尽量不要让两者撇的太远。
越远，融合越不方便。
AI带来的问题，归根结底是封装问题。
目前虽然改善了一些，但是还不够。还需要持续挖掘便捷的封装，逐渐的减低封装成本。 创世魂 发表于 2024-5-20 22:39
AI带来的问题，归根结底是封装问题。
目前虽然改善了一些，但是还不够。还需要持续挖掘便捷的封装，逐渐的 ...
赞同,火山本身门槛就很高了,封装门槛更高. 说白了就是生态不够，导致很多功能找不到源码、有问题不知道怎么解决、目前ai也回答不了火山的代码问题，所以其实小白入门还是难，易用性和易语言完全没法比，要扩大生态目前的主力依旧是封库大佬，所以务必需要注重封库人员的意见，封库难、不便、存在的问题还很多。不跟上脚步，可能目前不会，或者看不出，但以后肯定会被ai淘汰。就像几年前q群里程序员的斗图，在ide里输入口语化需求自动生成代码一样，当时认为都是玩梗，难道现在不是慢慢在实现吗？ 正常，吴总又不是全能，对于底层的封装总会考虑不周全，只要能听取意见就可以了 支持对封装用户友好一点 https://bbs.voldp.com/data/attachment/forum/202405/20/664b56ac8ca6a.png
typedef unsigned int MyUint32;
@飞扬工作室
希望你认真考虑一下，开1放1自1由定义数据类型。 目前Ai 对我来说，就是帮忙 解释一下 其他IDE源码的作用 对于复制粘贴型的程序员一点都不友好，封装太难了。普通人想学难度太大，不利于产品推广。一个好的产品简单，易上手是首要的。 song13521 发表于 2024-5-24 20:17
对于复制粘贴型的程序员一点都不友好，封装太难了。普通人想学难度太大，不利于产品推广。一个好的产品简单 ...
鄙视你！
页:
[1]
2