- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Spot on!
But that is the dark little secret of this site, isn't it? We all think we are hot programmers, and spitting at someone else's code sure reassures us. Actually we generally post according to different schemes, but they all follow the same patterns
1. Write some code yourself, which does the same as the wtf, but oh so much more elegantly
2. Use the "Well come on that's not so terrilble guys" (trying to go fo the experience edge)
3. Rewrite a worse version of the code, to show that you have understood what the problem was.
Actually, I find some of the answers really funny, especially for the no 2 posters. For instance "What's the big deal about string = "null" ", or "It's not really bad using the same variable for many purposes, that way you don't have to scroll so much".
Andrew
Admin
As in the (now famous) usenet newsgroup: alt.wesley.crusher.die.die.die?
Admin
Because:
void someFunction(Object obj){
System.out.println( obj != null ? obj.toString() : "");
} Useful if you know that obj is something which either IS a String, or returns some human readable value.
Also, if you are given a string from an Object it is far faster to call toString on it to get the value back than it is to cast it.
Object obj = "Some String, but it was passed to me as an object";
String str = obj.toString(); // faster String str = (String) obj; // slower
Admin
Me thinks like would still be far easier for java devs if null was the instance of a full fledged object, Ruby or Python style, no more NPE...
Admin
Actually, I can think of one good reason why you might want to clone a String in Java. I don't know whether this is true or not, but I've heard rumours that methods like "substring" don't create copies of the actual underlying character array, but simply create new objects which refer to the original String, using the appropriate mathematical magic.
Now, imagine that you have a three million character long string, and you take a twenty character substring of it. The substring contains a reference to the original string, keeping 6MB (2 bytes per character) around. Clone the substring, and the garbage collector can reclaim the 6MB leaving only the 40 bytes for the substring allocated.
I guess this might be a contrivedly silly example (three million characters?) but the idea holds.
Then there's always "intern", for doing exactly the opposite (getting rid of multiple objects with the same content), which ought also to save memory if used properly.
Admin
No rumor, this is absolutely correct. You get the source code of java.lang.String with the JDK, take a look.
Ususally this saves time and space, but in extreme cases like the one you describe you would want to get rid of the unused part. I wouldn't call that "clone" because that implies to me an exact copy of the internal state (that's what Object.clone() does). What you want to use is the String(String) constructor.
Admin
It's bad enough that so many people seem to think this code is Java when it is plainly C#. But you ought to know that even if it were Java, he could not have created a class that extends String, which is a final class. (I believe the C# equivalent is "sealed".)
Admin
I actually think I know how this one came about. I think this code monkey thrives on Intellisense(TM), and after he typed "someString = anotherString" he didn't realize that was all he needed, so he hit the period key.
Intellisense pops up, and he starts scrolling through, looking for a likely-sounding method to call (which is how he came across Copy() in one of the other examples). He spots "ToString()" and thinks to himself, "Ook! Ook!" (translation: that looks good), so he hits Enter.
Just one problem for our pet code grinder. His other finger was still hovering over the period key, and he accidentally taps it a second time. Intellisense pops up again, and now he's confused. "Didn't I just do this?" But, like the mindless Sphex wasp he is (Google "sphexish"), he repeats the process. ("Stimulus, response, stimulus, response. Don't you ever think!?")
He scrolls down to "ToString" again and hits Enter. This time he types a semicolon to end the line, and when he tests his masterpiece IT SEEMS TO WORK! And that is the one true sign for the code grinder. Any code that seems to work is golden, no matter how it is formatted or how many WTFs it contains.
I'm sure it's been cited here before, but Charles Petzold has an article in which, among other things, he has some criticisms of Intellisense.
http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html
Admin
(Okay, okay, I KNOW I always triple post when I come here -- sorry -- but, damnit, I only make it here on the weekend and I always come in at the end of an interesting thread.)
Actually, it seems to depend on the JVM. I tried it with the "client" JVM in Java 1.5, and the cast was between 2 and 3 times faster. I got the same results with Java 1.6 build 71. Then I tried the "server" JVM in Java 1.5, and the call to toString was faster, but they were very close (and they were both a lot faster, overall). The "server" JVM isn't distributed with the builds of mustang, so I couldn't try that. My benchmark did "warm up" the code to make sure the methods I was timing had been jitted.
Of course, I'm sure the cast would be massively slower in the case where it actually had to throw a ClassCastException.
But this kind of microbenchmark of one language feature is not really such a good idea. You should be writing whichever is clearer in context, not writing the cast as a call just because it might be faster. If you profile it you will also see that calling a method on an interface is slower than calling it on the actual class. Does that mean you should declare your variables and parameters as "ArrayList" instead of "List" for a speed boost?
It would be a rare method that actually DID something with a list where the speed of dispatching methods on that list was the limiting factor, or the method was so performance-critical that it deserved that degree of attention. Ditto for casting vs. calling toString. If you really need to worry about it, then you do, of course, but until then keep in mind the two golden rules of optimization:
1. Don't do it.
2. (for experts only) Don't do it yet.
Admin
"...figured that the best consultant probably charged the second highest rate..."
There's the WTF. What kind of hiring criteria is THAT? If a company is going to make a hiring choice based on such ridiculous guidelines, they deserve what they get.
Perhaps the rate for the crummy consultants are high because they are getting less and less business because word is getting around! The good consultants haven't had to raise their rates because their quality is high and they are getting all the work these dingdongs used to get.
Ow. my head hurts now.
Admin