Java 与 c++类型
我最近有一个关于 coledatetime java 实现的问题，以及Chris 说，问题可能在于类型转换：cpp-float 与 java-float （或者可能是 cpp-date 与 java-date。不是类型，但..）。现在我对此有几个问题：
- 是否有 java 与 c++ 类型的比较表？
- 如果类型转换是问题，在我的情况下（我有一个包含 OLEDate 记录的数据库，已经使用某些 C++ 程序创建了。我需要读取和写入该数据库，以便保持 OLEDate 字段兼容性：我的java代码读取正确的日期，而c++程序不受java程序写入数据库的影响。），你会做什么：
- 使用 COleDateTime 通过 JNI 检索日期？
- 不惜一切代价创建自己的实现（使用更广泛的类型或其他任何东西）？
- 我这里缺少什么吗？
I've recently had a question about coledatetime java implementation, and Chris said, that the problem might lay in type conversions: cpp-float vs java-float (Or maybe cpp-date vs java-date. Not types, but..). Now I have several questions on this:
- Is there a table of comparison for java vs c++ types?
- If type conversions is the problem, in my situation (I have a db with OLEDate records, already created with some c++ program. I need to read and write to that db, so that the OLEDate field compatibility remained: my java code reads proper dates, and c++ program is not affected with what the java program wrote to the db.), what would you do:
- Use COleDateTime to retrieve the date with JNI?
- Create your own implementation at all costs (using broader types, or anything else)?
- Is there anything, I'm missing here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 C++ 中，一种实现（编译器/体系结构）与另一种实现（编译器/体系结构）之间的类型范围确实不同，因此不存在标准的 Java-C++ 类型比较，因为不存在标准的 C++ 类型大小。
但在大多数当前体系结构中，C++ 双精度数是标准 IEEE 754 双精度数，就像 Java 中的双精度数一样。因此，虽然代码不能严格移植到某些罕见的体系结构，但它通常可以在任何 x86/x86_64 体系结构中工作。
上一个答案的评论中有一个问题您没有解决：在您的实现中不起作用的是什么？
In c++ type ranges can and do differ from one implementation (compiler/architecture) to another, so there is no standard Java-C++ type comparisons as there is no standard C++ type sizes.
But in most current architectures C++ doubles are standard IEEE 754 doubles, as it is in Java. So while the code will not be strictly portable to some rare architecture, it will more often than not work in any x86/x86_64 architectures.
There was a question in the comments of the previous answer that you did not address: what is it that does not work in the implementation you have?