德尔福/C++ DLL 问题 - unsigned long 与 unsigned int？
（已解决：请参阅自我回复。感谢那些回答的人）。
我在将 C++ DLL 动态加载到 Delphi 6 Pro 程序中时遇到了一个奇怪的问题。 DLL 中的函数调用之一是：
__declspec(dllexport) int foo(unsigned int A, unsigned long bitsetVector);
我在 Delphi 函数中将函数指针转换为：
foo : function(A: LongWord; bitsetVector: LongWord): integer;标准调用；
几乎所有其他我映射到 DLL 的调用都工作正常，但这个调用返回“无效的位集字段”错误，表明它不喜欢 bitsetVector 值。 bitsetVector 参数是通过使用 OR 运算符设置位来构建的。当然，所有用于设置位的枚举常量都是 2 的幂。我很确定这是一个强制转换错误，所以我想知道“unsigned int”与“unsigned long”之间是否存在一些我不知道的细微差别。 MSDN C++ 文档显示它们都是 4 个字节，范围为 0 到 4,294,967,295，所以它们对我来说看起来是一样的。
奇怪的笔记。我尝试运行一个范围为 0 到 100 的 for 循环，其中我只是将 for 迭代器变量 (i) 作为位集向量传递。 所有奇数值都失败，而所有偶数值都成功。这就是为什么我觉得这是一个转换错误。请注意，我没有损坏或内存错误。我对 FastMM4 进行了全面检查，没有出现堆栈崩溃或堆损坏，尽管事实上有几个 DLL 调用接收 LongWord 参数，并且通常“输出”参数通常首先遭受 DLL 集成不匹配的影响。另外，我从 C++ DLL 返回的值看起来是正确的。
如果有人对此有任何想法或想法，或者如果这不是选角问题，也许有一些可能揭示真正问题的切线知识，我想知道。
谢谢。
(SOLVED: See self-reply. Thanks to those that answered).
I'm having a weird problem with a C++ DLL I am loading dynamically into my Delphi 6 Pro program. One of the function calls in the DLL is:
__declspec(dllexport) int foo(unsigned int A, unsigned long bitsetVector);
I have the function pointer cast in my Delphi function as:
foo : function(A: LongWord; bitsetVector: LongWord): integer; stdcall;
Almost all the other calls I have mapped out to the DLL work fine but this one, which returns an "invalid bitset field" error, indicating it doesn't like the bitsetVector value. The bitsetVector parameter is built by using the OR operator to set bits. All the enumeration constants used to set the bits are powers of 2 of course. I'm pretty sure it's a cast error somehow, so I'm wondering if there's some nuance about "unsigned int" vs. "unsigned long" that I don't know about. The MSDN C++ documentation shows them both as being 4 bytes each with a range of 0 to 4,294,967,295, so they look identical to me.
Bizarro note. I tried running a for loop, range 0 to 100, where I just passed the for iterator variable (i) as the bitset vector. All the odd number values failed while all the even numbers succeeded. This is why I feel like it's a casting error. Note, I have no corruption or memory errors. I did full checks with FastMM4 and there have been no stack crashes or heap corruptions despite the fact that several of the DLL calls receive LongWord parameters and usually "out" parameters usually suffer first in DLL integrations mismatches. Also, the values I get back from the C++ DLL look right.
If anyone out there has any ideas or thoughts about this, or perhaps some tangential knowledge that might reveal the real problem if it's not a casting problem, I'd like to know.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
感谢那些回复的人。事实证明，这是症状真正具有误导性的案例之一。真正的问题是用于设置位的第一个枚举常量（当然其值为 1）在调用上下文中是非法的。这就是为什么只有“偶数”位集值成功的原因。这仅仅是因为不存在非法枚举值。事实证明 DLL 链接是正确的。
Thanks to those that responded. This turned out to be one of those cases where the symptoms were truly misleading. The real problem was that the first enumeration constant used to set bits, which had of course a value of 1, was illegal in the context of the call. That's why only "even numbered" bitset values succeeded. It was solely because the illegal enumeration value was not present. It turns out the DLL linkage was sound.