问题标签 [unsigned-long-long-int]

以下代码段能否成功转换为 Java？

我正在尝试使用以下算法检查 c++ 中 unsigned long long 的设置位，该算法仅检查该位是否已设置。但我的问题是我得到的答案是错误的。请帮助我了解 unsigned long long 是如何以二进制形式存储。

代码：

输入 ：

输出：

预期输出：

同样对于另一个输入：

输出 ：

预期输出：

在第二个示例中（实际上对于任何小数字），二进制模式只是在 32 位之后重复自身。

我在 PIC24 上用 C 定义了一个变量

假设变量的名称（在 C 文件中）是The_Number_Of_Bytes

在 PIC24 C 代码中，它是这样定义的......

当一个名为的字节数组DATABUF01包含The_Number_Of_Bytes字节（抱歉隐含的冗余）时，我将被调用，我需要确保我准确地执行了那么多字节，然后停止。

我非常有信心这个数字会小于 65535，所以为什么它是一个 unsigned long 是为了其他讨论。现在，我想知道；哪个是高位词，哪个是低位词？（就此而言，longPIC24 C 中是 32 位数字吗？）

有人能告诉我这个例子中W2会发生什么吗？W3

有人可以确认或纠正我对 unsigned long int 的 Hi/Low 顺序的想法吗？

编辑评论者要求这样做。可以回答问题（评论是我的）

请求评论，大小似乎是 4 个字节，来自这个......

我想将 ip-port 对作为搜索键，所以我有以下功能

实际上，我想将 u_int64_t 转换为 int64_t 因为无符号整数比较值不方便。但是恐怕从 u_int64_t 到 int64_t 的转换不是一对一的映射，然后会出现一些冲突或搜索错误。

所以我想问一下从 u_int64_t 到 int64_t 的转换是否不是一对一的映射？谢谢！

我的机器是64位的。我的代码如下：

mBuffer 是无符号字符*。我想获取 5 个字节的数据并将数据转换为主机字节顺序。我怎样才能避免这个警告？

你知道如何stoull在 Visual Studio 2008 上使用吗？我想将字符串转换为 unsigned long long。谢谢！

在下面的代码中，我0xffffffff将（32 位）乘以 2unsigned int并将其存储在unsigned long long（64 位）中。为什么我没有得到实际的输出是8589934588. 相反，我得到4294967294. 提前致谢。输出：sizeof i=4 Sizeof J=8 2xi=4294967292

我正在查看另一个问题（此处），有人正在寻找一种方法来获取 x86 程序集中的 64 位整数的平方根。

事实证明这很简单。解决方案是转换为浮点数，计算 sqrt，然后再转换回来。

我需要在 C 中做一些非常相似的事情，但是当我研究等价物时，我有点卡住了。我只能找到一个接受双打的 sqrt 函数。双精度数不具备存储大型 64 位整数而不引入显着舍入误差的精度。

是否有一个我可以使用的具有long doublesqrt 函数的通用数学库？

我有一个大型代码库，其中包含使用 uint_fast64_t 作为索引类型的矩阵相关代码。为了使用GMM作为求解器后端，我需要从以下位置转换（转换！）向量：

转 GMM 内部格式

在 MSVC2012 下，uint_fast64_t 的类型定义为 unsigned long long，因此两个表达式“相同”。

我很清楚它们实际上不是同一类型，因为 unsigned long long 可能正好是 64 位长（长）（因为它是实现定义的），而 uint_fast64_t 至少是 64 位长。( --no-haters ;) )

可悲的是，GCC4.7 和 Clang 3.4 将 uint_fast64_t 称为内部类型，因此无法进行任何类型的强制转换。

此外，似乎在某些时候，clang 将 uint_fast64_t 解释为 unsigned long - 使其与 unsigned long long 定义更加不兼容。

你从我的痛苦中看到了哪些方面？

我唯一的选择是手动替换 GMMs 代码中的 unsigned long long 吗？

我想就以下问题寻求一些帮助。我需要创建一个函数，它将两个整数相乘并提取这个乘法的余数除以某个数字（简而言之，(x*y)%A）。

我使用 unsigned long long int 来解决这个问题，但是 A = 15！在这种情况下，x 和 y 之前都是以 A 为模计算的。因此，x*y 可以大于 2^64 - 1，因此会溢出。

我不想使用外部库。谁能帮我设计一个简短的算法来解决这个问题？

提前致谢。