There were no mentioning of the trade beeing a mistake, so human verification might not have changed anythnig.
tiller
@tiller
Best posts made by tiller
Latest posts made by tiller
-
RE: The cause of the 'flash crash'
-
RE: Any thoughts on this password behaviour?
It might do it if login page is storing a md5 hash of the users password in a cookie when the user login. And each page then check this md5 checksum up against the password to verify that the user have entered the correct password.
-
RE: When libraries aren't good enough ...
@Someone You Know said:
The documentation for that method states explicitly that it creates a new object. Compilers shouldn't be going against that; the one from
SunOracle certainly doesn't.The same documentation also basically says that you should never use that constructor for anything, ever, but I doubt if the people who wrote this code have ever read it.
@tiller said:
But the java compiler wil not rewrite the += anyware in this program to use a StringBuffer.
The language spec allows compilers to optimize this sort of thing wherever they want. I admit that I don't know exactly where it's done in practice, but it may differ from compiler to compiler.
The compiler can optimize what it want as long as it don't change the semantic of the program. So it might in this case notice that no other function is given a reference of the string in the loop, and add usage of a StringBuffer.But I really don't think the compiler wil do that. I mean sun have added StringBuffer/StringBuilder for people who want Strings which can change so there is no reason to assume that += should be optimized for strings. (Unless you optimize your compiler for code submitted to thedailywtf.
Ofcause the real wtf is that the only Object in java which can use is += is String which is also specified as immutable and thus the only class which in no way can make an effective append operation.
-
RE: When libraries aren't good enough ...
@Someone You Know said:
@tiller said:
@Someone You Know said:
@zelmak said:
Indeed. I'm trying to break the other programmers of this habit, but it's slow going.
So there's more than one person who does this? Where did they all get the idea that using a copy constructor on a literal of the same type makes any kind of sense?
It's java(I guess, looks like it). so there is no copy constructor, and the code is not really more ineffective then just writing s="." (But s="." is more readable).
What is really ineffective is that strings in java are imutable so each time it does a += it creates a new string and throw the old string away.
The String(String) constructor being used here takes a String as an argument and constructs a new String object that is a value copy of that String. In what way is that not a copy constructor?
It is "more ineffective" than String s = "."; because it creates two String objects — the literal "." and s — and discards one of them without using it for anything.
I wouldn't worry about the concatenations as much, though; newer versions of Java are reasonably clever about that, and will convert String += String expressions to use StringBuffer or StringBuilder behind the scenes if there are a significant number of them in rapid succession.
You are right, it is a copy constructor unless the java compiler does some fancy optimization. Is someone bored enough to try and compile and then dis-assable the program to se if java compiler does the obvious optimization :}
But the java compiler wil not rewrite the += anyware in this program to use a StringBuffer.It will only insert an extra StringBuffer when you do something like "Some" + myVar + "other things" but in this case the right side is always a single char/string so it wil generate a new string for each +=. But given the number of wtf's in this code and the fact that this is most likely not in a performence critical place that is rather low on the list of things to fix.
-
RE: When libraries aren't good enough ...
@Someone You Know said:
@zelmak said:
Indeed. I'm trying to break the other programmers of this habit, but it's slow going.
So there's more than one person who does this? Where did they all get the idea that using a copy constructor on a literal of the same type makes any kind of sense?
It's java(I guess, looks like it). so there is no copy constructor, and the code is not really more ineffective then just writing s="." (But s="." is more readable).
What is really ineffective is that strings in java are imutable so each time it does a += it creates a new string and throw the old string away.
-
RE: The data doesn't have to be accurate
That's one solution, but a better solution would most likely be using a transaction and doing a "select ... for update"
-
RE: We can always deal with it manually
Can't you atleast use transactions to prevent the "some subset of the original tables and some subset of the "marked" tables, with who-knows-what set of constraints, triggers and indices." problem? Ok I admit i have newer tried to see if drop table/trigger/indices work in a transaction with rollback, but I seems to remember that PostgreSQL did implement transaction/rollback support for drop table and drop column.
And please don't quit your job, the design you need to work with make anything else sane by comparison :}
-
RE: Representative line
@synecdoche said:
@tiller said:
The original problem that malloc is fixing* is not a memory leak, but a stack overflow which is kinda the opposite of a memory leak(More data then allocated ram).
But this code does create a new leak :-}
*Fixing as in: Works for me now, don't touch anything.
The malloc fixes a buffer overflow by actually creating a memory leak: that's what's funny/worrying about the comment.
Immediately before this the program declares a variable-sized array:
<font face="Lucida Console" size="2">float *some_array = malloc(sizeof(float) * (1 + magical_size_variable));</font>
Running <font face="Lucida Console" size="2">malloc(4096);</font> "works" because the new memory is allocated straight after the array. A more subtle and slightly less brittle way of doing the same stupid thing is to add 4096 to the malloc where the array is allocated, and a proper solution would be to fix whatever horrendous calculation is used to come up with the magical_size_variable.
I ended up not touching this code at all: it's executed once per page hit, so with a generous 1,000 hits per day = leaks 4MB per day. If I started fixing everything wrong with this code, I could keep going for years, and worse, I'd get a reputation as "the guy who knows about FooProject". Everything about this code is poison by now: the source control system before we inherited it was a bunch of folders named fooproject_1, fooproject_2 etc., up to fooproject_20.
Those numbers represent "branches", by the way, not revisions.
Once per page hit? Are the company writing a webservice in c++. And with only 1000 expected hits per day. I think we have the true wtf right here :}
Why would anyone write a website with very low performance requirements in c++ ????
-
RE: Representative line
@PJH said:
@tiller said:
But this code does create a new leak :-}
Only if it's executed more than once, without freeing the result from the previous invocation. What you're saying is akin to saying "declaring global variables creates memory leaks," in that memory is reserved at start up, and there's no user code to free that memory. In both cases (assuming the code is executed only once), there's a single allocation and in both cases it's freed when the program exits.[1]
Both are bad practise, but neither necessarily create 'memory leaks' in the conventional sense of the term.
I used to hear rumours that GameOS used to *really* leak memory under such circumstances - i.e. not free it up once the program had exited, but that was years ago, and I'm sure they've fixed it now. Firefox has now taken up the gauntlet...But as can be seen from the code, he newer store a pointer to the value allocated by malloc, so he can't free it again.
-
RE: Representative line
The original problem that malloc is fixing* is not a memory leak, but a stack overflow which is kinda the opposite of a memory leak(More data then allocated ram).
But this code does create a new leak :-}
*Fixing as in: Works for me now, don't touch anything.