String e = ""; // an empty string
String greeting = "Hello";
Length
The length method yields the number of code units required for a given string in the UTF-16 encoding. For example:
String greeting = "Hello";
int n = greeting.length(); // is 5.
To get the true length, that is, the number of code points, call
int cpCount = greeting.codePointCount(0, greeting.length());
The call s.charAt(n) returns the code unit at position n, where n is between 0 and s.length() – 1. For example,
char first = greeting.charAt(0); // first is 'H'
char last = greeting.charAt(4); // last is 'o'
To get at the ith code point, use the statements
int index = greeting.offsetByCodePoints(0, i);
int cp = greeting.codePointAt(index);
NOTE
Java counts the code units in strings in a peculiar fashion: the first code unit in a string has position 0. This convention originated in C, where there was a technical reason for counting positions starting at 0. That reason has long gone away and only the nuisance remains. However, so many programmers are used to this convention that the Java designers decided to keep it.
Why are we making a fuss about code units? Consider the sentence is the set of integers
The character requires two code units in the UTF-16 encoding. Calling
char ch = sentence.charAt(1)
doesn't return a space but the second code unit of . To avoid this problem, you should not use the char type. It is too low-level.
If your code traverses a string, and you want to look at each code point in turn, use these statements:
int cp = sentence.codePointAt(i);
if (Character.isSupplementaryCodePoint(cp)) i += 2;
else i++;
Fortunately, the codePointAt method can tell whether a code unit is the first or second half of a supplementary character, and it returns the right result either way. That is, you can move backwards with the following statements:
i--;
int cp = sentence.codePointAt(i);
if (Character.isSupplementaryCodePoint(cp)) i--;
Substrings
You extract a substring from a larger string with the substring method of the String class. For example,
String greeting = "Hello";
String s = greeting.substring(0, 3);
creates a string consisting of the characters "Hel".
The second parameter of substring is the first code unit that you do not want to copy. In our case, we want to copy the code units in positions 0, 1, and 2 (from position 0 to position 2 inclusive). As substring counts it, this means from position 0 inclusive to position 3 exclusive.
There is one advantage to the way substring works: Computing the number of code units in the substring is easy. The string s.substring(a, b) always has b - a code units. For example, the substring "Hel" has 3 – 0 = 3 code units.
String Editing
The String class gives no methods that let you change a character in an existing string. If you want to turn greeting into "Help!", you cannot directly change the last positions of greeting into 'p' and '!'. If you are a C programmer, this will make you feel pretty helpless. How are you going to modify the string? In Java, it is quite easy: concatenate the substring that you want to keep with the characters that you want to replace.
greeting = greeting.substring(0, 3) + "p!";
This declaration changes the current value of the greeting variable to "Help!".
Because you cannot change the individual characters in a Java string, the documentation refers to the objects of the String class as being immutable. Just as the number 3 is always 3, the string "Hello" will always contain the code unit sequence describing the characters H, e, l, l, o. You cannot change these values. You can, as you just saw however, change the contents of the string variable greeting and make it refer to a different string, just as you can make a numeric variable currently holding the value 3 hold the value 4.
Isn't that a lot less efficient? It would seem simpler to change the code units than to build up a whole new string from scratch. Well, yes and no. Indeed, it isn't efficient to generate a new string that holds the concatenation of "Hel" and "p!". But immutable strings have one great advantage: the compiler can arrange that strings are shared.
To understand how this works, think of the various strings as sitting in a common pool. String variables then point to locations in the pool. If you copy a string variable, both the original and the copy share the same characters. Overall, the designers of Java decided that the efficiency of sharing outweighs the inefficiency of string editing by extracting substrings and concatenating.
Look at your own programs; we suspect that most of the time, you don't change strings—you just compare them. Of course, in some cases, direct manipulation of strings is more efficient. (One example is assembling strings from individual characters that come from a file or the keyboard.) For these situations, Java provides a separate StringBuilder class that we describe in Chapter 12. If you are not concerned with the efficiency of string handling, you can ignore StringBuilder and just use String.
Java vs Cpp
C programmers generally are bewildered when they see Java strings for the first time because they think of strings as arrays of characters:
char greeting[] = "Hello";
That is the wrong analogy: a Java string is roughly analogous to a char* pointer,
char* greeting = "Hello";
When you replace greeting with another string, the Java code does roughly the following:
char* temp = malloc(6);
strncpy(temp, greeting, 3);
strncpy(temp + 3, "p!", 3);
greeting = temp;
Sure, now greeting points to the string "Help!". And even the most hardened C programmer must admit that the Java syntax is more pleasant than a sequence of strncpy calls. But what if we make another assignment to greeting?
greeting = "Howdy";
Don't we have a memory leak? After all, the original string was allocated on the heap. Fortunately, Java does automatic garbage collection. If a block of memory is no longer needed, it will eventually be recycled.
If you are a C++ programmer and use the string class defined by ANSI C++, you will be much more comfortable with the Java String type. C++ string objects also perform automatic allocation and deallocation of memory. The memory management is performed explicitly by constructors, assignment operators, and destructors. However, C++ strings are mutable—you can modify individual characters in a string.
Concatenation
Java, like most programming languages, allows you to use the + sign to join (concatenate) two strings.
String expletive = "Expletive";
String PG13 = "deleted";
String message = expletive + PG13;
The above code sets the variable message to the string "Expletivedeleted". (Note the lack of a space between the words: the + sign joins two strings in the order received, exactly as they are given.)
When you concatenate a string with a value that is not a string, the latter is converted to a string. (As you see in Chapter 5, every Java object can be converted to a string.) For example:
int age = 13;
String rating = "PG" + age;
sets rating to the string "PG13".
This feature is commonly used in output statements. For example,
System.out.println("The answer is " + answer);
is perfectly acceptable and will print what one would want (and with the correct spacing because of the space after the word is).
Testing Strings for Equality
To test whether two strings are equal, use the equals method. The expression
s.equals(t)
returns TRue if the strings s and t are equal, false otherwise. Note that s and t can be string variables or string constants. For example, the expression
"Hello".equals(greeting)
is perfectly legal. To test whether two strings are identical except for the upper/lowercase letter distinction, use the equalsIgnoreCase method.
"Hello".equalsIgnoreCase("hello")
Do not use the == operator to test whether two strings are equal! It only determines whether or not the strings are stored in the same location. Sure, if strings are in the same location, they must be equal. But it is entirely possible to store multiple copies of identical strings in different places.
String greeting = "Hello"; //initialize greeting to a string
if (greeting == "Hello") . . .
// probably true
if (greeting.substring(0, 3) == "Hel") . . .
// probably false
If the virtual machine would always arrange for equal strings to be shared, then you could use the == operator for testing equality. But only string constants are shared, not strings that are the result of operations like + or substring. Therefore, never use == to compare strings lest you end up with a program with the worst kind of bug—an intermittent one that seems to occur randomly.
Difference from cpp
If you are used to the C++ string class, you have to be particularly careful about equality testing. The C++ string class does overload the == operator to test for equality of the string contents. It is perhaps unfortunate that Java goes out of its way to give strings the same "look and feel" as numeric values but then makes strings behave like pointers for equality testing. The language designers could have redefined == for strings, just as they made a special arrangement for +. Oh well, every language has its share of inconsistencies.
C programmers never use == to compare strings but use strcmp instead. The Java method compareTo is the exact analog to strcmp. You can use
if (greeting.compareTo("Hello") == 0) . . .
but it seems clearer to use equals instead.
The String class in Java contains more than 50 methods. A surprisingly large number of them are sufficiently useful so that we can imagine using them frequently. The following API note summarizes the ones we found most useful.
NOTE
You will find these API notes throughout the book to help you understand the Java Application Programming Interface (API). Each API note starts with the name of a class such as java.lang.String—the significance of the so-called package name java.lang is explained in Chapter 4. The class name is followed by the names, explanations, and parameter descriptions of one or more methods.
We typically do not list all methods of a particular class but instead select those that are most commonly used, and describe them in a concise form. For a full listing, consult the on-line documentation.
We also list the version number in which a particular class was introduced. If a method has been added later, it has a separate version number.
No comments:
Post a Comment