You still get most of the benefit of StringBuilder since the long string is built with it. It could be better but performance will be the same order at least.
Posts made by Jonathan
-
RE: Cheap code
-
RE: It's critical that this is fixed!!!!1!!eleven!!
The RWTF is that Google finds thirty million results for ש״ח and zero for ₪.
-
RE: Time Zone Converter
@Cassidy said:
@Jonathan said:
Dates as strings are necessary in order for them to be human readable.
Then you transform them just as you're about to display them to a human.
For all other operations, it makes sense to leave them as a Date object.
So far we haven't been given any requirements so we don't know if any other operations are needed. The unknown requirements may or may not call for this code.
So the worse than failure here is expecting requirements to be assumed, which is the worst of all worse than failures.
-
RE: Time Zone Converter
@OhNoDevelopment said:
@Jonathan said:
The basic idea seems correct to me. What is the worse than failure?
For starters, dates as strings are silly strings. This whole thing would not have been necessary had it simply used date objects instead.
Dates as strings are necessary in order for them to be human readable.
So this code doesn't meet your requirements? You haven't shown us your requirements and this code is basically correct for what it does.
-
RE: Time Zone Converter
The basic idea seems correct to me. What is the worse than failure?
-
RE: Programmers trying to talk to non-programmers without getting sidetracked by trivialities? IMPOSSIBLE!
I don't see the worsethanfailure. The discussion is an intelligent one about basic programming theory. It's trivial only superficially. People dying because of programming errors and how that affected language design is not trivial.
You do have a funny avatar though, so there's that.
-
RE: Saving timestamps in the database, displaying local time
@Jonathan said:
@morbiuswilters said:
@Jonathan said:
Isn't the number of seconds since midnight on January 1, 1970 the same as the number of seconds since December 31, 1969?
Yes and no. From the point of view of calculating a timestamp, the last discrete second of Dec 31, 1969 would be 23:59:59, so if you calculate from there you'd end up with an extra second.
The last second of December 31, 1969 did start at 23:59:59 but it ended at midnight.
And the last second of December 31, 1972 started at 23:59:60.
-
RE: Saving timestamps in the database, displaying local time
@morbiuswilters said:
@Jonathan said:
Isn't the number of seconds since midnight on January 1, 1970 the same as the number of seconds since December 31, 1969?
Yes and no. From the point of view of calculating a timestamp, the last discrete second of Dec 31, 1969 would be 23:59:59, so if you calculate from there you'd end up with an extra second.
The last second of December 31, 1969 did start at 23:59:59 but it ended at midnight.
-
RE: Saving timestamps in the database, displaying local time
@morbiuswilters said:
@Jonathan said:
The way I read that Wikipedia link is that these days Unix time is the number of seconds since December 31, 1969 UTC minus the twenty four leap seconds not counted.
Well, midnight on January 1st 1970 UTC. But at least you read the article and understood that epoch is a date and the unix time (basically) the number of seconds since the epoch (minus the leap seconds, which I didn't mention in the interests of keeping things simple).
Isn't the number of seconds since midnight on January 1, 1970 the same as the number of seconds since December 31, 1969?
-
RE: Saving timestamps in the database, displaying local time
@Speakerphone Dude said:
The way I read that Wikipedia link is that these days Unix time is the number of seconds since December 31, 1969 UTC minus the twenty four leap seconds not counted. It gives the example of 1998-12-31T23:59:60 and 1999-01-01T00:00:00 being represented by the same Unix time even though they are a second apart. It also says that before 1972, UTC seconds were longer than they are today.In the context of this discussion, epoch refers to "unix epoch", and this means the number of seconds since Jan 1 1970 UTC (see the Universal Truth).
-
RE: Too stringy to digest
@Petrea Mitchell said:
[...] I'm afraid I'm not a "he".
I'm afraid you've made it too easy to figure out your pseudonym.
-
RE: Another pre-wtf: Queries in tables
@Lorne Kates said:
[...]
-- and make it impossible to use diff tools to look for query changes-- and will take all of they query code out of version/source control--
[...]
Why?
-
RE: CheckStyle, round two + FindBugs
@mott555 said:
@pjt33 said:
@belgariontheking said:
In this case, it's declared outside a try that I didn't show you. Inside the try is where it initializes, fills, and returns it.
But if it's returned inside the try, it can be declared inside the try. Minimise the scope and you can avoid the dead store, so it's not unreasonable to flag it up in pedantic mode (and IIRC from the previous thread, the config settings are pushing for pedantry).
Unless he needs access to the object within the catch or finally blocks.
Try moving or copying the return to outside the try.
-
RE: Overcoding?
@zelmak said:
If it were me, I would probably implement the guts more like:
if (thisString != null) { rtn = thisString.compareTo(thatString); } else if (thatString != null) { rtn = - thatString.compareTo(thisString); }
if (rtn != 0) {
return rtn;
}
.
.
.
rtn is already 0 so no need to check for both being null; compareTo(null) Does The Right Thing(tm); extraneous/duplicative checks for nullness removed.
The existing code is simple and easy to maintain. Your code is more complicated and changes the behavior to throw null pointer exceptions. In fact I'm not really sure why you are even bothering to check for null.
-
RE: Negative zero $
The IEEE 754 floating-point representation and one's complement integer representation both allow negative zero which differs from positive zero.
One of my professors told a story about figuring out what his electric meter needed to read in order to generate a predetermined total due. He would pay for two billing periods so that when the electric company ran the billing process for the second period, his total due would be exactly negative zero. This would crash their mainframe. They repeatedly requested that he discontinue this practice which inspired him to continue until they stopped asking.
-
RE: Payed by LOC??
The problem here is the horrid database design, not this query. Union all is the best way to select this data without redesigning the database. There is no equivalent shorter query.
-
RE: Four Values on Average
// This is for 1.1 serialization compatibility
This is for 1.1 serialization compatibility.
-
RE: Doctor CHOICE is the best in the business
[url]http://kentonville.net/dr-choice-best-choice.html[/url]
-
RE: Oracle breaks sun forums google search
[url]http://webcache.googleusercontent.com/search?q=cache:forums.sun.com/thread.jspa?threadID=5438103[/url]
moved to
[url]http://forums.oracle.com/forums/thread.jspa?messageID=5498687[/url]
where SunForumsGuest registered a month and a half ago and has over two and a quarter million posts.
-
RE: Get the default value by type
@Someone You Know said:
@joe darcy said:
Instead, a switch should occur on a predictable and fast
integer (or long) function value computed from the string. The most
natural choice for this function is String.hashCode, but other functions
could also be used either alone or in conjunction with hashCode. (The
specification of String.hashCode is assume to be stable at this point.)
If all the string labels have different lengths, String.length() could
be used instead of hashCode. Generally a String.equals() check will be
needed to verify the candidate string's identity in addition to the
evaluation of the screening function because multiple string inputscould evaluate to the same result.
Since there exist multiple Strings that have different values but the same String.hashCode() value, the hashCode value alone can't be used as a switch constant. This guy proposes using String.equals() as well (presumably only if the hashCode values are equal). Is this really going to provide a significant performance increase over a series of if/else statements? If it doesn't, then this is like Java generics all over again — a feature that everyone wants, but when it's finally implemented, it's done in such a way that it's little more than syntactic sugar.
If you're going to go down that road — using a switch constant that may be the same for value-distinct switch values — why not allow switching on all Objects?
The only way to check what value a string has is to check each character in the string, and String.equals() is the most efficient way to do that. There is no getting around the fact that efficient switching on strings requires calling String.equals(). Putting those calls as the second stage inside a switch statement adds efficiency by reducing the number of calls to String.equals() down to one or only a few.
The reason switching on strings was added and not switching on other classes is because the string class is immutable and String.equals() is known to have no side effects.
-
RE: Get the default value by type
@JohnWestMinor said:
Y'know, you could also concatinate the ascii code for each character into one long string (with like a 6 character cutoff) and then turn those into a long, divide by a standard number to get it down to an int and then switch on that value.Of course, you would have false positives from similar strings, but that's a problem for the next developer.
In the given case after checking for a null value or empty string, you can switch on the first character of the string since they are unique.
You still have the problem of false positives but the solution is to use the original calls to String.equals() for each case in the switch. This is how it will be implemented behind the scene when switching on strings.
So the given case could be coded like below. A better solution would be to use enumerations.
public Object getDefaultValue(String strType) {
if(strType==null || strType.equals(""))
return null;switch(strType.charAt(0)) {
case 'S':
if(strType.equals("STRING"))
return "";break;
case 'I':
if(strType.equals("INTEGER"))
return new Integer(0);break;
case 'F':
if(strType.equals("FLOATING"))
return new Float(0.0f);break;
case 'D':
case 'T':
if(strType.equals("DATE") || strType.equals("TIMESTAMP"))
return new java.util.Date();break;
case 'B':
if(strType.equals("BOOLEAN"))
return new Boolean(true);break;
case 'G':
if(strType.equals("GUID"))
return "";break;
case 'O':
if(strType.equals("OBJECT"))
return new Object();break;
}
return null;
} -
RE: Get the default value by type
@Someone You Know said:
In Java, you can only switch on primitive types. (Strings are not primitives in Java.)
Java's switch statements assign an integer constant to each case value, so that the whole thing can be optimized into a lookup table of instruction pointers. There is no obvious way to do this for a Java Object that will both a) always work the way you want it to and b) be faster than a series of if statements, especially if the runtime type of the object is not known at compile time. Thus, switching on an Object would just be syntactic sugar, which the language designers apparently felt was not worth the effort.
Java 7 will have switching on strings.
-
RE: C++ compiler does not understand comments (yet?)
I caused a bug once (that I know of) with an extraneous semicolon like this.
if (condition);
{
doStuff();
}
Even when I was looking directly at it I didn't see the problem until after actually stepping through with a debugger a few times. It would be really nice if there were a compiler warning that caught autonomous braces. I never purposely use autonomous braces so if they exist in my code, it's certainly a bug.
-
RE: Whaddya mean "else"?
Does the CustAge declaration allow it to be defined as null?
-
RE: Wisconsin e-file
Oklahoma has almost the same thing. I like it because it makes it easy to fill out the form. When the form is printed it has a two dimensional bar code that encodes all of the entered information. The form still has to be mailed but it can be processed quicker and cheaper.
The only thing I hate about it is it won't let you save the form with the entered information. You have to enter the information and print from the same computer. I had to enter my information again on a different computer the first time. I'd really like to find out what the developers were thinking about that.
Jonathan
-
RE: 681765,999616 bytes of data
One byte of memory is 0,0009765625 kilobytes. There's nothing wrong with the precision used. The reason the total value doesn't match the sum is because the displayed values are rounded to the nearest millionth of a kilobyte.
-
RE: I guess that is more secure?
If you share a cubicle wall then trust me, he knows you by voice.