CLI 和 GUI 之间的 NSInteger 区别？
我一直在构建框架并在 GHUnit 中编写单元测试。我的框架的访问器方法之一返回一个 NSInteger。
我在测试中断言预期值如下：
GHAssertEquals(1320, request.port, @"Port number should be 1320");
当使用基于 AppKit UI 的前端运行我的测试时，此断言通过。
但是，当我在命令行上运行测试时，除非我将硬编码的 1320 类型转换为 (NSInteger)，否则它会因类型不匹配而失败。是什么导致编译器解释整数的方式存在差异？ xcodebuild 在命令行上是否对硬编码整数使用不同的数据类型？
I've been building a framework and writing unit tests in GHUnit. One of my Framework's accessor methods returns an NSInteger.
I assert the expected value in the tests like this:
GHAssertEquals(1320, request.port, @"Port number should be 1320");
When running my tests with an AppKit UI based frontend this assertion passes.
However, when I run my tests on the command line, it fails with a type-mismatch unless I type-cast my hard-coded 1320 as (NSInteger). What's causing the difference in the way the integer is being interpreted by the compiler? Is xcodebuild on the command line using a different data-type for hard coded integers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您是否正在为不同的架构构建应用程序（可能是因为一种是通用的，一种是针对一种架构的）？ NSInteger 根据目标架构构建为 32 位或 64 位（src)，这可能与编译器为小常量选择的不同。演员阵容肯定会明确你的意图。
Are you building your applications for different architectures (perhaps because one is building universal and one is building for one architecture)? NSInteger builds as 32-bit or 64-bit depending on the target architecture (src), which may differ from what the compiler chooses for a small constant. The cast certainly makes your intentions clear.