z*y
发帖数: 1311 | 1 class testString
{
public static void main(String args[])
{
String s = "1234567";
System.out.println(s.charAt(0));
System.out.println(s.charAt(1));
System.out.println(s.length());
System.out.println(s.substring(0, s.length()-1));
}
}
输出：
1
2
7
123456
string index 如果是从0开始的，那么最后应该输出整个串，right? |
g*****g
发帖数: 34805 | 2 你看一下substring的api不就明白了。
【在 z*y 的大作中提到】
: class testString
: {
: public static void main(String args[])
: {
: String s = "1234567";
: System.out.println(s.charAt(0));
: System.out.println(s.charAt(1));
: System.out.println(s.length());
: System.out.println(s.substring(0, s.length()-1));
: }
|
M***0
发帖数: 1180 | 3 Java所有API含有“从a到b”的a都是inclusive b都是exclusive |
N***m
发帖数: 4460 | 4 这样做的目的或者是好处是什么？
是不是和c++的iterator类似的目的？
【在 M***0 的大作中提到】
: Java所有API含有“从a到b”的a都是inclusive b都是exclusive
|
j*a
发帖数: 14423 | 5 :~$ javac -version
javac 1.6.0_32
:~$ cat a.java
import java.lang.Integer;
class a {
public static void main(String args[]) {
int a=1000, b=1000;
System.out.println(a==b);
Integer c=1000, d=1000;
System.out.println(c==d);
Integer e=100, f=100;
System.out.println(e==f);
}
}
:~$ javac a.java
:~$ java -version
java version "1.6.0_32"
Java(TM) SE Runtime Environment (build 1.6.0_32-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.7-b02, mixed mode)
:~$ java a
true
false
true
:~$
【在 z*y 的大作中提到】
: class testString
: {
: public static void main(String args[])
: {
: String s = "1234567";
: System.out.println(s.charAt(0));
: System.out.println(s.charAt(1));
: System.out.println(s.length());
: System.out.println(s.substring(0, s.length()-1));
: }
|
h**********c
发帖数: 4120 | 6 It looks like a severe bug. but
1. java doesn't have operator overload etc.
to compare value of ADT, non-built-in, the interface function is equal().
a.equal(b).
2. probaly == compare the references' hash values, it happens to be a
collision? not sure about 2.
Above all Java is not c++.
【在 j*a 的大作中提到】
: :~$ javac -version
: javac 1.6.0_32
: :~$ cat a.java
: import java.lang.Integer;
: class a {
: public static void main(String args[]) {
: int a=1000, b=1000;
: System.out.println(a==b);
: Integer c=1000, d=1000;
: System.out.println(c==d);
|
r*****l
发帖数: 2859 | 7 You need to understand the differences between "==" and "equals()".
"c == d" means that is c and d are same objects. "c.equals(d)" tells you if
their values are the same. With equals(), you always get consistency.
Internally, Java maintains a small Integer cache from -127 to 127. When you
do autoboxing, if the value is within that range, the objects from the cache
is returned. e and f are both from the cache and they are the same object.
For c and d, > 127, when Java does boxing, it creates new object using new
Integer(). That's why c and d are not the same object.
【在 j*a 的大作中提到】
: :~$ javac -version
: javac 1.6.0_32
: :~$ cat a.java
: import java.lang.Integer;
: class a {
: public static void main(String args[]) {
: int a=1000, b=1000;
: System.out.println(a==b);
: Integer c=1000, d=1000;
: System.out.println(c==d);
|
r*****l
发帖数: 2859 | 8 This is not a bug. Nothing is in conflict with Java SE or JVM specs.
This is related to auto boxing and unboxing in Java. You are right to say
Java does not have operator overload.
"==" does NOT compare hash values.
You are right to say Java is not c++.
I see that probably you are a very good c++ programmer.
【在 h**********c 的大作中提到】
: It looks like a severe bug. but
: 1. java doesn't have operator overload etc.
: to compare value of ADT, non-built-in, the interface function is equal().
: a.equal(b).
: 2. probaly == compare the references' hash values, it happens to be a
: collision? not sure about 2.
: Above all Java is not c++.
|
h**********c
发帖数: 4120 | 9 Where did you get these things?
API?
【在 r*****l 的大作中提到】
: This is not a bug. Nothing is in conflict with Java SE or JVM specs.
: This is related to auto boxing and unboxing in Java. You are right to say
: Java does not have operator overload.
: "==" does NOT compare hash values.
: You are right to say Java is not c++.
: I see that probably you are a very good c++ programmer.
|
k*****y
发帖数: 744 | 10 感觉最大的好处是 b-a = length；还有b是下一段的开始，如果要iterate的话，看起
来比较清楚。
【在 N***m 的大作中提到】
: 这样做的目的或者是好处是什么？
: 是不是和c++的iterator类似的目的？
|
|
|
k*****y
发帖数: 744 | 11 I think you only have references to the objects in Java. So in some sense
the object variables are just like pointers in C.
So "==" means they have the same address. Should use "equals" to compare the
dereference values.
【在 h**********c 的大作中提到】
: It looks like a severe bug. but
: 1. java doesn't have operator overload etc.
: to compare value of ADT, non-built-in, the interface function is equal().
: a.equal(b).
: 2. probaly == compare the references' hash values, it happens to be a
: collision? not sure about 2.
: Above all Java is not c++.
|
h**********c
发帖数: 4120 | 12 So my question is:
So when you println an object. suppose you didn't override toString,
is that value printed an absolute address or hashed value of an address?
the
【在 k*****y 的大作中提到】
: I think you only have references to the objects in Java. So in some sense
: the object variables are just like pointers in C.
: So "==" means they have the same address. Should use "equals" to compare the
: dereference values.
|
k*****y
发帖数: 744 | 13 The address is already unique and fits in 32bit/64bit, so I don't see why
the implementation need to hash it again. But I don't think it matters,
since Java doesn't have the concept of address and what do you want to do
with that?
I am new to Java too. Please correct me if I am wrong.
【在 h**********c 的大作中提到】
: So my question is:
: So when you println an object. suppose you didn't override toString,
: is that value printed an absolute address or hashed value of an address?
:
: the
|
j*a
发帖数: 14423 | 14 i see. thank you.
if
you
cache
【在 r*****l 的大作中提到】
: You need to understand the differences between "==" and "equals()".
: "c == d" means that is c and d are same objects. "c.equals(d)" tells you if
: their values are the same. With equals(), you always get consistency.
: Internally, Java maintains a small Integer cache from -127 to 127. When you
: do autoboxing, if the value is within that range, the objects from the cache
: is returned. e and f are both from the cache and they are the same object.
: For c and d, > 127, when Java does boxing, it creates new object using new
: Integer(). That's why c and d are not the same object.
|
f*******n
发帖数: 12623 | 15 See the documentation for Object.toString()
http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#
this method returns a string equal to the value of:
getClass().getName() + '@' + Integer.toHexString(hashCode())
It is whatever number hashCode() returns. If you overrode hashCode(), it
will return the number that method returns.
If you didn't override hashCode(), then see the documentation for Object.
hashCode()
http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#
As much as is reasonably practical, the hashCode method defined by class
Object does return distinct integers for distinct objects. (This is
typically implemented by converting the internal address of the object into
an integer, but this implementation technique is not required by the JavaTM
programming language.)
So it is some kind of unique identifier; it may or may not be based on the
address.
【在 h**********c 的大作中提到】
: So my question is:
: So when you println an object. suppose you didn't override toString,
: is that value printed an absolute address or hashed value of an address?
:
: the
|
f*******n
发帖数: 12623 | 16 No
1. It is not a bug. This is the correct behavior
2. == on references ALWAYS compares if the two references point to the same
object. It has nothing to do with "hash values" or anything like that
【在 h**********c 的大作中提到】
: It looks like a severe bug. but
: 1. java doesn't have operator overload etc.
: to compare value of ADT, non-built-in, the interface function is equal().
: a.equal(b).
: 2. probaly == compare the references' hash values, it happens to be a
: collision? not sure about 2.
: Above all Java is not c++.
|
g*****g
发帖数: 34805 | 17 Simply put, as long as it's an object (Integer included), you are
not supposed to use == for comparison, unless you want to check
it's the reference.
Even e == f yields true, it's a bad usage.
【在 r*****l 的大作中提到】
: This is not a bug. Nothing is in conflict with Java SE or JVM specs.
: This is related to auto boxing and unboxing in Java. You are right to say
: Java does not have operator overload.
: "==" does NOT compare hash values.
: You are right to say Java is not c++.
: I see that probably you are a very good c++ programmer.
|
s*****h
发帖数: 155 | 18 不应该 -1 的呀
java里面的范围一般都是(start, end+1) |
