2412d,d的7月语言会议
总结
位域
话题转向了Walter的位域提案.
当Timon举手发布评论时,这是第一个议程项目.
Walter和Rikki就跨保存单元边界而辩论,Rikki说这是必要的,而Walter说不是必要的.不过,我没有完整的背景信息.
就此后,我说很好奇需要多久与D的C位域交互.在我多年来一直维护绑定的流行C库中,只有一个使用位域.我只是忽略了他们,但他们正在使用uint,所以根据Walter的说法,即他们应该开箱即用.
即便如此,需要多久担心一次?
Walter说D编译器中需要它们.GDC和LDC是现在不能用位域的C++和D的混合程序.我说那很好.可以在编译器中做要做的.
我想知道,在野外,需要多久使用一次位域.如果不是很频繁,则对混合语言代码,要求extern(C)使用C编译器布局并定义自己的布局可能是值得的.
Walter说,更有趣的问题是位域必须多久符合外部施加的布局.他说那几乎从不.经典例子是硬件寄存器.
但是硬件寄存器在你的电脑上,C编译器在你的电脑上,所以它会做C编译器做的事情.
Rikki说,与对接C相比,他更频繁地在文件格式和网络中处理它.此时,这很正常.Walter问Rikki是否在文件格式中使用位域?
Rikki说是,它们很常见.Walter问C是如何与它交互的.Rikki说手动.沃尔特说:“没错!”
Timon说Walter基本上是在鼓励不使用位域.如果他不想让人们使用该功能,他就不应给它一个好的语法.那只是差的设计.
沃尔特说,他不同意.Timon问,创建一些不应使用的东西,但语法比应该用的更好,这是否是个好的设计.
Walter说他想可在D前端使用位域.Timon说应该允许他这样做,而且应该有很好的语法.他同意这些限制.
他不同意应该把C的东西复制到D中.他还认为,如果你在D端定义它,且你在C端同样定义了,则它们应该匹配.他不反对这样.
沃尔特说他同意,如果它在D和C中相同,但执行不同,那将是完全意外的,且可能是破坏内存错误.但是,有记录表明D的位域匹配相关C编译器的布局.
如果在同一平台上使用的另一个C编译器与关联的C编译器不匹配,则在C端无法保证布局会匹配.在POSIX和Mac上,从未见过与所有其他编译器在这些平台上不匹配的C编译器,因为那太疯狂了.
唯一有差异的地方是在窗口上.微软编译器以一种方式完成,而GCC移植以GCC方式完成.这是一个不幸的决定,但他对此没办法.
D的C编译器布局设计为与微软的布局匹配.微软的布局为了匹配过去在x86上工作的旧C编译器.
所以,唯一有问题的地方是在窗口上的微软和GCC间,他看到人们抱怨位域和它们之间的其他细微差异.
Rikki说他想到了另一个方法:属性.默认值仍会匹配C编译器,这很好,但是想要其他的人需要有个带UDA的.
Walter说UDA很好,但手动对齐更好.它很简单,可立即理解.不会有混淆,且它管用了.
只是在位域前对齐排好了.可更改布局来匹配期望布局.他用来避免正常的成员对齐问题.
他会添加或删除填充字段以使其正常工作,这样他就可避免折腾对齐属性.
沃尔特说很好视角.但即使没有位域,现在也可能这样.在C编译器之间,结构有对齐差异,你必须处理它.
沃尔特说,他一直都在遇见这个问题.
他说还有字节排序.是大头还是小头,现在没人在生产大头了,但那是一件大事.这就是bswap硬件指令的目的.
Rikki表示,仍在网络中使用大头,且不会很快消失.沃尔特同意.
史蒂夫说沃尔特说得对,如果必须处理它,则你只需要学习如何处理它.如果布局对你很重要,则你要了解它的工作原理.
沃尔特说,美妙在,如果它最终错位,你会立即发现.沃尔特说你会的.他以前遵守过外部布局,他先测试它是否有效.
Walter说,他很高兴在位域文档中添加如何手动对齐.然后,读的人都会看到,上面写着"如果需要符合外部布局,方法如下".
Walter说,如果你使用别人的代码,这些代码用对齐或手动添加填充来使其工作,则它也可在你的系统上工作.蒂蒙说他理解.
Walter说,即使你正在构建相同代码的系统不关心结构布局.如果你在-m32和-m64间切换,你的结构布局就会有所不同.
他试过的每一台编译器都是如此.
它有一点文档,但需要一个属性来改变枚举的布局的要求不高.即使是D新手也会明白位域是他们必须为其附加属性的特殊对象.
Rikki说Nim有三个位域模式.一个与C编译器匹配,一个是想要做的打包内容,第三个是可任意干活的.这对他们来说很有效.
他说Rust也有了位域.他们不会总是使用C布局.
Walter说,D的最初设计是编译器可按它想要的方式重排结构成员.他一直在考虑重排以清除填充等.
但很快就发现这不好.所以他按C方式实现了它,他完成了.他从不抱怨过D编译器中的字段对齐.一个也没有.该对齐确实改变了事情.
他放弃重排的另一个原因是,他发现人们有时会重排字段以缓存.想在缓存最热的部分放置最常用的字段.
你想把你常用的东西放在一起,其余的放在别的地方.此时,你不想编译器重排它.如果有人仔细地在C语言中布局了一个结构,然后D编译器来了,并重排了它,这不好.
和类型
Rikki说他正在开发一个覆盖了基本匹配类型的DIP.它已有了三周,并准备好拉请.
他说,支持静态如的方式有些问题,但它已准备好了.
其次,他谈到了他对"memberof"符号的提议.它有参数到参数匹配方面的问题,Walter过去反对.
这在DIPIdeas论坛中以推导类型再次出现.Rikki说他在这方面受阻,并想Walter决定前进的路径(如果有的话)这里.
Rikki说,参数/参数匹配的主要问题是它必须调用验证语义,因为只能这样.他需要知道是否必须覆盖它以避免调用语义.
Steve问是否有一篇文章或视频解释了和类型异常,这样可理解它们.Rikki说他写了一篇DIP.史蒂夫说他不需要DIP.
Walter问Rikki是否在谈论抛和类型值.Rikki说它是一个结构,而不是一个和类型.他是个和类型.
Walter说D没有抛结构.Rikki说,在新机制下,可以.它不会调用运行时异常机制.这一切都是通过函数的返回来实现的.
它会做得非常好,并勾挂try/catch和抛.
Walter说,他想降低try/catch和抛的复杂度,而不是给它添加值类型.Rikki说这是一个已讨论了很久的完全不同机制.
Dennis问,你的想法是否是返回传统的错误码,但此时,编译器覆盖抛和抓来检查错误码.
Rikki说,你可传递想要的任意用户数据.
Mathias问,如果在不使用异常ABI时这样做,这不会破坏在D和C++间使用异常的能力吗?Rikki说它不会.一个是使用现有机制的类,一个是使用现有机制的结构.
Walter说他已放弃了在窗口上抓D中的C++异常.且微软没有文档,而且太复杂了,所以他就丢弃了它.
可在32位窗口上运行,因为它有文档记录.微软说他们也记录了64位的异常文档,但他们没有.
这是一团糟.他不得不花费大量时间逆向,而他不想把时间花在上面.因此,D在64位窗口上用自己的处理异常机制.
从函数返回可变大小的栈分配
Aya说,她一直在想,该语言现在是否可以从函数返回可变大小的栈分配.沃尔特说不行.Aya认为应该为它准备一些可完成但很笨拙的语法糖.
Walter说,一般当你返回可变大小的东西时,你是通过引用来做的.Aya说,你必须在调用点分配,并向函数传递一个指向内存的指针,这样它填充.
这实际上是一个栈返回.
Walter说这会管用,但另一件事是不想离开CABI.他以前用D试过,那真是一场灾难.必须遵守CABI,因为不仅每个人都遵守它,而且调试器除了C标准的ABI外,不能工作.
即使文档说它会,但不是.显然,没人用非C调用约定测试过调试器.发明自己的也不行.
但是,CABI确实说过,如果你要传递一个大型结构,则要传递它的指针,然后代码生成器填充它.这只是返回引用的变种.
Aya说,她总体上正在考虑较小的分配.可调用返回分配大小的函数.然后,也许需要在需要分配的中间存储中保存分配内容.
因此,或需要分配两次,或调用两次来确定返回值大小的所有逻辑.想法是,不知道是否可以简化它.
沃尔特说,这都必须通过引用来完成.Aya同意.
Timon说,这只是对sizeof为动态值的类型的命名返回值优化.这是好事,但构造起来有点麻烦.
Aya说她也一直在考虑结构接口.我提到了Atila的库.马蒂亚斯说可以使用类.Walter把可变大小关联起来,说类是按引用传递的可变大小的对象.
也许Aya可考虑使用类来实现该想法.
Aya说,问题是,当有非常小的结构时,你想要一个接口和很多小结构.你只会有包含大量堆分配和片段的无缘无故实现相同接口的很多小类.
Walter建议使用COM类.它们更简单,更小.Aya问他们是否可移植的.沃尔特说他们是.它们就是为了匹配窗口中的COM接口.
编译器支持就在那里.最小的COM对象仅包含一个指针.他们非常聪明,是个不错的功能.
Aya说她会调查一下.
她问是否需要IUnknown才能使用COM接口.沃尔特说是.Aya说它在version(Windows)的后面.沃尔特说可以把它删掉.
Rikki说可在没有IUknown时使用它.它可与任意东西一起工作.
Adam说在窗口上,D中的一些内容有版本错误.他在ODBC支持中遇见了它,一直在Linux上使用.
这时,直接PR它应该是可以的.他可保证COM可在Linux和Mac上运行.这只是CABI的事情.
Walter说明,微软的COM接口依赖QueryInterface,Add和释放函数.如果没有从IUnknown继承,你就不会有这些.
亚当说这是对的.你可在没有这些时完成,但你必须重建功能.
Dennis说Vladimir曾想公开一些与窗口位图相关的结构,他回忆道,Walter和Jonathan曾反对这样做,因为在非窗口上导入窗口内容将是一个错误.
Adam说,此时,COM自身并不是窗口相关的.Walter在COM中提到了GUID内容,并认为这是相关窗口的.
亚当说这是真的.可以公开结构自身,因为其中没有相关窗口的内容.Walter说,你需要取GUID.Adam问是否可用UUID?并使用微软的方法.
沃尔特说是,但必须做点什么才能让它有效.
Adam说,他的一般要点是,COM只是一个CABI技巧.窗口大量支持它,而这在其他地方可能不可用.
如果想努力在自己环境中重建它,那可能会管用.不需要查询接口部分.
Walter的更新
沃尔特说他一直在做两件事.
首先,有两个主要请求,让移动构造器正常工作,因此这是个优先事项.他花时间在移动构造器和ARM生成代码.
Weka想要该功能已很久了.他们是主要用户,因此需要处理它.
其次,ARM后端的PR差异超过5000LOC,几乎无法审查.他已和Dennis讨论过合并它,即使它还不是个正常运行的后端.
他不断地重定基它,但别人很难跟踪他的进度,因为他一直在增加该巨大的PR.如果它是主线,则会更好.
沃尔特说丹尼斯提出测试它.通过测试包运行它不工作,因为测试包需要一个全功能的编译器.未来可能需要在测试包中添加ARM目标.
他不知道如何工作.他不知道测试包的设置.
Rikki说,只要没有暴露ARM后端,且没有调用路径,然后合并它.Walter说他已在一个开关后面放置它,他认为这不会影响别人的代码.
Rikki说他会记录这个开关,但除此外,合并似乎很好.
原文地址：https://blog.csdn.net/fqbqrr/article/details/144436340
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！