primitive

问题 Consider the following two classes: public interface Foo<T> { public T moo(); } public class IntFoo implements Foo<Integer> { public int moo() { return 0; } } This code will produce an error at public int moo , saying that int is incompatible with the overridden method's return type Integer . Strictly speaking, this is true, since int does not directly equal Integer . However, we all know that they can be implicitly converted to each other using auto(un)boxing. What is less know is the fact

问题 In C++ we can make primitives unsigned . But they are always positive. Is there also a way to make unsigned negative variables? I know the word unsigned means "without sign", so also not a minus (-) sign. But I think C++ must provide it. 回答1: No. unsigned can only contain nonnegative numbers. If you need a type that only represent negative numbers, you need to write a class yourself, or just interpret the value as negative in your program. (But why do you need such a type?) 回答2: unsigned

问题 If I have this in my .h file: int index; And then in the .m file I have: if (index == nil) and I haven't assigned a value to index , will that come up true? EDIT I guess nil is only used for objects. So what is the state of an int that hasn't been assigned a value? 回答1: There is no such thing as "nil" for ints. That's an object value. As for what variables are initialized to by default: Non-static local variables are not initialized to any defined value (in practice, they will usually have

问题 In one of my Java projects I am plagued by code repetition due to the way Java handles (not) primitives. After having to manually copy the same change to four different locations ( int , long , float , double ) again , for the third time, again and again I came really close (?) to snapping. In various forms, this issue has been brought up now and then on StackOverflow: Managing highly repetitive code and documentation in Java How to avoid repetition when working with primitive types? Passing

问题 I was curious to what the performance differences between Java's class and primitive type for double were. So I created a little benchmark and found the class type to be 3x-7x slower than the primitive type. (3x on local machine OSX, 7x on ideone) Here is the test: class Main { public static void main(String args[]) { long bigDTime, littleDTime; { long start = System.nanoTime(); Double d = 0.0; for (Double i = 0.0; i < 1432143.341; i += 0.1) { d += i; } long end = System.nanoTime(); bigDTime

问题 What is the hashcode of a primitive type, such as int? for example, let's say num was an interger. int hasCode = 0; if (num != 0) { hasCode = hasCode + num.hashCode(); } 回答1: For the hashCode of an int the most natural choice is to use the int itself. A better question is what to use for the hashCode of a long since it doesn't fit into the int -sized hashcode. Your best source for that—and all hashCode -related questions—would be Effective Java. 回答2: Taken from the Integer.class source code:

问题 What is the hashcode of a primitive type, such as int? for example, let's say num was an interger. int hasCode = 0; if (num != 0) { hasCode = hasCode + num.hashCode(); } 回答1: For the hashCode of an int the most natural choice is to use the int itself. A better question is what to use for the hashCode of a long since it doesn't fit into the int -sized hashcode. Your best source for that—and all hashCode -related questions—would be Effective Java. 回答2: Taken from the Integer.class source code:

问题 Given that byte,short and int are signed, why do byte and short in Java not get the usual signed two's complement treatment ? For instance 0xff is illegal for byte. This has been discussed before here but I couldn't find a reason for why this is the case. 回答1: If you look at the actual memory used to store -1 in signed byte, then you will see that it is 0xff . However, in the language itself, rather than the binary representation, 0xff is simply out of range for a byte. The binary

问题 Given that byte,short and int are signed, why do byte and short in Java not get the usual signed two's complement treatment ? For instance 0xff is illegal for byte. This has been discussed before here but I couldn't find a reason for why this is the case. 回答1: If you look at the actual memory used to store -1 in signed byte, then you will see that it is 0xff . However, in the language itself, rather than the binary representation, 0xff is simply out of range for a byte. The binary

问题 I just recently started learning Basics in Java, and was testing around initializing a string variable by concatenating primitive variables. public class Main{ public static void main(String[] args){ byte lbyte = 3; short lshort = 1; int lint = 1; long llong = 0; float lfloat = 2.0f; double ldouble = lfloat; char lchar = 'H'; boolean lbool = true; String lstring = " w0r1d "; String lOutput = lchar+lbyte+lshort+lint+llong+lstring+ldouble+' '+lbool; System.out.println(lOutput); } } In this code