相当于C ++的BigInteger值long long

时间:2022-05-05 17:14:15

I am migrating some code base from C++ to Java where I encountered a long long value in the C++ code which i need to migrate.

我正在将一些代码库从C ++迁移到Java,在那里我遇到了需要迁移的C ++代码中的长值。

On some research i found out I should be using BigInteger to represent the long long of C++.

在一些研究中,我发现我应该使用BigInteger来表示长期的C ++。

I looked at couple of examples and found out the syntax to be :

我看了几个例子,发现了语法:

static BigInteger flag1 = BigInteger.valueOf(0x00000001); 

Here i noticed the value used in the argument for BigInteger.valueOf is not the same as original long long value which was 0x0000000000000001LL

在这里我注意到BigInteger.valueOf参数中使用的值与原始long long值不同,即0x0000000000000001LL

Original value had 16 digits and this one had 8 digits and does not include LL suffix at the end. Can someone explain what is going on ?

原始值有16位数字,这个数字有8位数字,最后不包括LL后缀。有人可以解释发生了什么吗?

Also If they can suggest the value of 0x0000000000000200LL in similar terms.

另外,如果他们可以用类似的术语建议0x0000000000000200LL的值。

3 个解决方案

#1


3  

Please note: all those zeros ... don't matter. There is no difference between 0x1; and 0x001, and so on. As long as we are talking about numbers.

请注意:所有这些零...无所谓。 0x1之间没有区别;和0x001,依此类推。只要我们谈论数字。

It would be a different thing if those were represented as strings; then of coursre "0x1" is not the same string as "0x01". But well, they aren't.

如果那些被表示为字符串,那将是另一回事;然后coursre“0x1”与“0x01”不是同一个字符串。但是,他们不是。

All of your values are number literals; and they are all in a range that would even fit into ordinary long values in Java.

你的所有价值观都是数字文字;它们都在一个甚至适合Java中普通long值的范围内。

In other words: leading zero digits do not matter for numbers (except for an example like 010, which is something else than 10; as starting 0 indicate octal numbers).

换句话说:前导零位数对于数字无关紧要(除了像010之类的例子,这不是10;因为起始0表示八进制数)。

The more interesting question would actually would be: what literal value the compiler puts into the java bytecode for that.

实际上更有趣的问题是:编译器将哪些文字值放入java字节码中。

#2


2  

0x0000000000000001LL == 0x00000001 == 0x1 == 1 (dec)

0x0000000000000001LL == 0x00000001 == 0x1 == 1(dec)

0x0000000000000200LL == 0x00000200 == 0x200 = 512 (dec)

0x0000000000000200LL == 0x00000200 == 0x200 = 512(dec)

Those are small values and can be represented as a regular int.

这些是小值,可以表示为常规int。

You can also use BigInteger is you need.

你也可以使用BigInteger。

#3


1  

There are a number of things to learn here:

这里有很多东西需要学习:

  1. You probably don't need to use BigInteger here at all. The C++ long long type is a signed 64 bit integer on most systems (see http://en.cppreference.com/w/cpp/language/types). But Java has a 64 bit signed integer type - long. So unless you are porting C++ code that was designed for an architecture where long long is greater than 64 bits (!), a Java long is what you need to use.

    你可能根本不需要在这里使用BigInteger。在大多数系统上,C ++ long long类型是带符号的64位整数(请参阅http://en.cppreference.com/w/cpp/language/types)。但Java有一个64位有符号整数类型 - 长。因此,除非您正在移植专为长long大于64位(!)的体系结构而设计的C ++代码,否则需要使用Java long。

  2. Leading zeros don't matter in hexadecimal literals (i.e. 0x...) in Java.

    在Java中,前导零与十六进制文字(即0x ...)无关。

    (They matter for decimal literals though, because a leading zero turns a "decimal" literal into an octal literal ... which alters its value. For instance, the literal 010 represents the number eight!)

    (但它们对于十进制文字很重要,因为前导零将“十进制”文字转换为八进制文字...这会改变它的值。例如,文字010表示数字8!)

  3. If you actually do need 64 bit integer literal in Java, then put an L on the right hand end. Integer literals are assumed to be 32 bit.

    如果你确实需要Java中的64位整数文字,那么在右端放一个L。整数文字假定为32位。

  4. In a context like this where you are trying to use BigInteger(long), a 32 bit integer literal would be widened to 64 bits anyway.

    在这样的上下文中,您尝试使用BigInteger(long),无论如何,32位整数文字将被扩展为64位。


So in your case:

所以在你的情况下:

static BigInteger flag1 = BigInteger.valueOf(0x00000001); 
static BigInteger flag1 = BigInteger.valueOf(0x0000000000000001); 
static BigInteger flag1 = BigInteger.valueOf(0x1);
static BigInteger flag1 = BigInteger.valueOf(1);
static BigInteger flag1 = BigInteger.valueOf(1L);

are all saying the same thing. This is saying the same thing too ...

都在说同样的话。这也是说同样的事情......

static BigInteger flag1 = BigInteger.valueOf(01);

... but it is a bad idea. It only works because "1" octal and "1" decimal are the same number.

......但这是一个坏主意。它只能起作用,因为“1”八进制和“1”小数是相同的数字。


Someone asked:

The more interesting question would actually would be: what literal value the compiler puts into the java bytecode for that.

实际上更有趣的问题是:编译器将哪些文字值放入java字节码中。

I don't think that the JLS specifies this, but it would use a long literal because that is what the JVM spec requires.

我不认为JLS指定了这个,但它会使用长文字,因为这是JVM规范所要求的。

#1


3  

Please note: all those zeros ... don't matter. There is no difference between 0x1; and 0x001, and so on. As long as we are talking about numbers.

请注意:所有这些零...无所谓。 0x1之间没有区别;和0x001,依此类推。只要我们谈论数字。

It would be a different thing if those were represented as strings; then of coursre "0x1" is not the same string as "0x01". But well, they aren't.

如果那些被表示为字符串,那将是另一回事;然后coursre“0x1”与“0x01”不是同一个字符串。但是,他们不是。

All of your values are number literals; and they are all in a range that would even fit into ordinary long values in Java.

你的所有价值观都是数字文字;它们都在一个甚至适合Java中普通long值的范围内。

In other words: leading zero digits do not matter for numbers (except for an example like 010, which is something else than 10; as starting 0 indicate octal numbers).

换句话说:前导零位数对于数字无关紧要(除了像010之类的例子,这不是10;因为起始0表示八进制数)。

The more interesting question would actually would be: what literal value the compiler puts into the java bytecode for that.

实际上更有趣的问题是:编译器将哪些文字值放入java字节码中。

#2


2  

0x0000000000000001LL == 0x00000001 == 0x1 == 1 (dec)

0x0000000000000001LL == 0x00000001 == 0x1 == 1(dec)

0x0000000000000200LL == 0x00000200 == 0x200 = 512 (dec)

0x0000000000000200LL == 0x00000200 == 0x200 = 512(dec)

Those are small values and can be represented as a regular int.

这些是小值,可以表示为常规int。

You can also use BigInteger is you need.

你也可以使用BigInteger。

#3


1  

There are a number of things to learn here:

这里有很多东西需要学习:

  1. You probably don't need to use BigInteger here at all. The C++ long long type is a signed 64 bit integer on most systems (see http://en.cppreference.com/w/cpp/language/types). But Java has a 64 bit signed integer type - long. So unless you are porting C++ code that was designed for an architecture where long long is greater than 64 bits (!), a Java long is what you need to use.

    你可能根本不需要在这里使用BigInteger。在大多数系统上,C ++ long long类型是带符号的64位整数(请参阅http://en.cppreference.com/w/cpp/language/types)。但Java有一个64位有符号整数类型 - 长。因此,除非您正在移植专为长long大于64位(!)的体系结构而设计的C ++代码,否则需要使用Java long。

  2. Leading zeros don't matter in hexadecimal literals (i.e. 0x...) in Java.

    在Java中,前导零与十六进制文字(即0x ...)无关。

    (They matter for decimal literals though, because a leading zero turns a "decimal" literal into an octal literal ... which alters its value. For instance, the literal 010 represents the number eight!)

    (但它们对于十进制文字很重要,因为前导零将“十进制”文字转换为八进制文字...这会改变它的值。例如,文字010表示数字8!)

  3. If you actually do need 64 bit integer literal in Java, then put an L on the right hand end. Integer literals are assumed to be 32 bit.

    如果你确实需要Java中的64位整数文字,那么在右端放一个L。整数文字假定为32位。

  4. In a context like this where you are trying to use BigInteger(long), a 32 bit integer literal would be widened to 64 bits anyway.

    在这样的上下文中,您尝试使用BigInteger(long),无论如何,32位整数文字将被扩展为64位。


So in your case:

所以在你的情况下:

static BigInteger flag1 = BigInteger.valueOf(0x00000001); 
static BigInteger flag1 = BigInteger.valueOf(0x0000000000000001); 
static BigInteger flag1 = BigInteger.valueOf(0x1);
static BigInteger flag1 = BigInteger.valueOf(1);
static BigInteger flag1 = BigInteger.valueOf(1L);

are all saying the same thing. This is saying the same thing too ...

都在说同样的话。这也是说同样的事情......

static BigInteger flag1 = BigInteger.valueOf(01);

... but it is a bad idea. It only works because "1" octal and "1" decimal are the same number.

......但这是一个坏主意。它只能起作用,因为“1”八进制和“1”小数是相同的数字。


Someone asked:

The more interesting question would actually would be: what literal value the compiler puts into the java bytecode for that.

实际上更有趣的问题是:编译器将哪些文字值放入java字节码中。

I don't think that the JLS specifies this, but it would use a long literal because that is what the JVM spec requires.

我不认为JLS指定了这个,但它会使用长文字,因为这是JVM规范所要求的。