Typed callables vs Cppia MemReference
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
先阅读 issue #1321 和 pull request #1324，然后跟踪此 issue 中描述的 cppia mem-reference 更改。复现跨越 cppia 边界、涉及 Int、Float 和 Dynamic 的 typed-callable 情况；当兼容的 callable 情况不再需要禁用 object mem references 且通过相关测试时，即表示完成。
由索引模型根据 Issue 内容生成。
描述
As part of the typed callables work I had to disable cppia mem references in two places to get all the tests passing, this was due to an unfortunate edge case involving haxe functions.
E.g. Haxe is perfectly happy to treat the following signatures as compatible without any user casting or manual wrapping.
Int->Void = Dynamic->Void
Float->Void = Int->Void
Without cppia this is all fine as the new callable types constructor deals with all this mangling, but with cppia there are a few annoying edge cases. Cppia erases all objects to hx::Object*, so when you pass an object like hx::ObjectPtr<hx::Callable<Int->Void>> from haxe into cppia it gets erased to just a object pointer. But this also means if you pass in a Haxe compatible hx::ObjectPtr<hx::Callable<Dynamic->Void>> it will also be erased to hx::Object* and the mem reference setter will just replace the pointer. The problems then start to occur when we try and pull that function object out of cppia and back into cpp. The pointer will be blindly reinterpreted to the original hx::ObjectPtr<hx::Callable<Int->Void>> (or whatever haxe deems the expression to be) which will cause a memory access violation if that pointer holds the one where Dynamic is the argument as they're incompatible types. Previously this would "just work" as all function closures invoked dynamically.
The other edge case surrounding passing these odd compatible callables over the cppia boundary is that you can end up with a callable object pointer in cpp holding a pointer to a hx::CppiaClosure which does not inherit a callable type, again this is due to pointers being reinterpreted by mem reference instead of going through the required callable constructor.
I still have a screenshot of this second one since it was fixed in a follow up merge.
https://github.com/HaxeFoundation/hxcpp/issues/1321
https://github.com/HaxeFoundation/hxcpp/pull/1324
Hopefully this makes sense, I'm not massively familiar with cppia so I found the easiest fix was to disable mem references for objects which is obviously not great. I'll try and remember to dig out some concrete examples of both of these.
Pinging @hughsando since he asked about it in a commit message.
- 主要语言
- C++
- 星标
- 330
- 派生
- 232
- 平均合并
- 3 天 5 小时
- 30 天内合并 PR
- 3
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
HaxeFoundation/hxcpp 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
HaxeFoundation/hxcpp#1217 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
HaxeFoundation/hxcpp#1432 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
HaxeFoundation/hxcpp#1431 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 42/100
HaxeFoundation/hxcpp#1430 ·
维护者通常 1 天内回复
-
Null<UInt> compared with null gives wrong results (null is cast to 0 by UInt's == / != overloads)未关闭
难度 4/5 1-2 天 新手友好度 57/100
HaxeFoundation/hxcpp#1427 · 1 条评论 ·
维护者通常 1 天内回复
查看 HaxeFoundation/hxcpp 的全部 Issue
相似的 Issue
-
bug intrinsic medium priority rt_lib
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
sumatrapdfreader/sumatrapdf#6417 · 3 条评论 ·
-
[BUG] Cython cache evicts most recent instead of oldest entry on cleanup可能已有人在做 @scoder 今天认领。 未关闭Build System defect
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 72/100
NVIDIA-Omniverse/PhysX#590 · 1 条评论 ·
维护者通常 1 天内回复