- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- 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
Actually, look into the IEEE floating point specs. Because floating point numbers are not all representable, you can get to a case where a - b = a. b could be a very small number, or the difference in magnitudes of the two could end up making a big difference. not a correct example, but imagine infinity - 1 = infinity. yes, the IEEE spec has a value for inifinity (both positive and negative, as well as many forms of NaN). While YOU might not run into problems like this, people who do hardcore numerical stuff (which you can be pretty sure the WTF isnt :) ) have to deal with crap like this all the time. My favorite is NaN != NaN.
See : http://docs.sun.com/source/806-3568/ncg_goldberg.html
Admin
Brilliant! But personally, I'd write it as:
Looks cooler. Code must look cool.
As a bonus, you can also have the following function:
Code reuse! Woot!
--Rank
Admin
First, no, the original poster (captain_damage) was not anonymous. Whassupwitdat?
Second, I have a math degree and I'm a good programmer, so you can smeg off now, kthxbye.
Okay, now that that's out of the way, let's consider the following alternative comment:
where C2 is a scaling factor, and C1 is to compensate for current_num and prev_num being zero or otherwise extremely small. There's a trade-off between efficiency and accuracy; if you want as much accuracy as possible without resorting to bigfloats, then it's best to stick with the original method, and let the system automagically figure out exactly how much accuracy that is. For most functions that numerical analysis encounters, I suspect that the efficiency gain isn't all that much. Anyway, both methods are sufficiently non-intuitive to warrant an explanatory comment.
Admin
The problem is it's not possible to know more than six months in advance whether a leap second will be necessary, so it's more trouble than it's worth to patch core C code to handle leap seconds.
So what I'm guessing happens is that the internet NTP servers drag out 23:59:59 over two seconds... and all the internet NTP clients just assume that their hardware clock had a blip.
Admin
This is correct for the conventional time_t representation, but the C standard does not mandate any specific representation and some C libraries can count leap seconds:
$ uname
Linux
$ cat test.c
#include <stdio.h>
#include <time.h>
int main()
{
struct tm tm_buf = { 0, 0, 0, 1, 1-1, 2005-1900 };
tzset();
printf("%ld\n", (long)mktime(&tm_buf));
return 0;
}
$ gcc test.c
$ TZ=posix/GMT ./a.out ; TZ=right/GMT ./a.out
1104537600
1104537622
Admin
Smeg off? Red Dwarf lives!
Oh, and with regard to your first point -- unregistered users are anonymous no matter what alias they use for posting.
Admin
While the "this==null" check is a WTF in that it will make most people say WTF when looking at it, it is not impossible for that to be the case.
Calling this code in C# would never result in a "null this" reference, but if the method were called from IL or C++, this could happen, and I wonder if it was not some sort of sanity check for some low-level code in the framework. If the method is ever called from the runtime directly then this might be a problem.
You see, C# (and most other high-level .NET languages, like VB) almost always uses the "callvirt" IL instruction when calling a method, even if it knows the method is not virtual. While it could use the "call" instruction, but that instruction does not check for a null reference and throw a NullReferenceException.
This WTF may also date back to an early alpha/beta of the framework when C# did not use callvirt in such cases. Since Graphics is a sealed class, virtual calls are not technically needed. At some point the decision was made to always check for null because not doing so is a debugging nightmare.
There are a lot of "WTF" artifacts from early versions of the framework. Take for instance the distinction of Delegate and MulticaseDelegate. All delegates are now MulticastDelegates, yet there exists code in mscorlib.dll that acts as if there was a difference. Personally, I would have made events multi-cast and callbacks single-cast, but I didn't design the framework. I mean, having a multi-cast Comparer<T> delegate is a WTF in and of itself.
And in regards to the question about reflection, I'm fairly certain that Reflection makes sure the "this" parameter is not null when calling a method, since it also goes to the trouble to make virtual calls, and you cannot make a virtual call on a null reference. I could double check it but then I might be proven wrong.
Admin
That's what you get in Reflector if you create a static class. And you're right, the compiler won't allow it, which is why it's confusing that that is how the CLR sees static classes. oh well. Funny to look at it in VB.NET:
public mustinherit notinheritable class Foo
end class
Admin
"So what I'm guessing happens is that the internet NTP servers drag out 23:59:59 over two seconds... and all the internet NTP clients just assume that their hardware clock had a blip."
No, they all couldn't care less because they're all in the pub getting drunk
Admin
This reminds me of a most excellent post on the PHP manual I ran across:
The conclusions he comes to - that because he found a way to hack and hijack the language implentation, it means something entirely different from what generations of OO proponents have conceptualized, are the best.
Admin
Couldn't resist:
#define paul brillant
Admin
rather, #define paula billant
:sigh:
Admin
The code does actually check the 'this' reference for 'null', so the code shown is effectively pseudocode that accurately captures the real behavior, even though it won't in fact compiler as shown. Presumably the code wasn't actually written in C# - I'm guessing the author of this WTF submission copied that code out from Reflector. (They probably don't have access to the source code, and if they do they shouldn't be sending it here!) Reflector decompiles the code in question as shown, even though it won't recompile as such... But then Reflector frequently produces uncompileable code. The originaly routine was most likely written in Managed C++, which does let you write such things.
More importantly, it's possible to get this test to succeed. So a test for 'this' against 'null' isn't completely pointless. It's a strange thing to do, but it is possible to get this particular code path to throw the exception. You can'd do it from C#, but with either Managed C++ or IL you can actually call an instance method on a null pointer. (Just like you can with instance methods on regular C++ classes - if nothing in the method actually tries to use fields in the class, or use virtual methods, it turns out to work!)
So it's not as stupid as is being suggested. Certainly the people in this thread who are under the impression that .NET prevents you from calling instance methods on null references are mistaken. Indeed, in beta 1 of .NET, even the C# compiler would let you do this. It used to generate the 'call' instruction for non-virtual functions rather than 'callvirt'. 'call' doesn't test for null, but 'callvirt' does. People complained about the fact that it was possible to invoke member functions on a null reference, so the C# compiler was modified to emit a 'callvirt' for all function calls, whether virtual or not. And the main reason people lobbied Microsoft for this change was so that they didn't have to write such checks!
.NET still lets you do this even though C# doesn't. So even though C# was changed, the check isn't completely pointless. However, it's not really necessary, because by convention, the 'this' reference isn't regarded as 'input' so most code doesn't bother. Invoking an instance method on a null reference is such an obscure thing to do that it's not normally regarded as being worth testing for - just let the code throw a NullReferenceException as it surely will when it tries to use a field or virtual member function.
This code almost certainly dates back to the early betas of .NET when such checks wouldn't have looked so odd. Before C# had this bizarre feature removed, you might reasonably have felt it worth checking for a valid 'this' reference, particularly if you're about to do interop type stuff.
Interestingly, this code is gone from .NET v2.0 beta 2 - it no longer does the null check. Now it just ends up throwing an exception when it tries to retrieve the 'this.NativeGraphics' field. Arguably the old behavior was 'better' - if you passed in bogus input (a null 'this') it would throw an ArgumentNullException, whereas now it just bombs out. I guess they removed the check because most people don't use a language that allows it, and anyone who goes far enough out of their way to invoke an instance method on a null reference probably gets what they deserve!
Admin
Not really. Here is what my co-worker replied:
The CLR allows you to call non-virtual instance methods without an instance of the object. Some languages, e.g. Managed Extenstions to C++, let you do this. E.g.:
// C#
public class CSharpClass
{
public int Foo()
{
return 42;
}
}
// C++
int _tmain()
{
CSharpClass *c;
Console::WriteLine(c->Foo());
return 0;
}
// Output is 42
C# doesn’t allow this. To achieve this, C# will always compile a method call like that to the “callvirt” IL instruction, even when the method it’s calling isn’t virtual. C++ will use the “call” instruction.
Admin
This is the pass-through filter you see in electronic devices to clear out the noise on the signal and strengthen it. Because you would never know when a boolean in Java might become weak or noisy, would you?
Admin
Are you stupid? Try replacing
if (1 < 2) return 5;
with
return 5;
Admin
Technically that's too late to do this in C++. You're dereferencing a NULL pointer to call the function, so it's undefined behavior. Certainly, if it's a virtual function (that the compiler can't resolve), you're screwed. (also, multiple inheritance could cause a more subtil problem) Otherwise, most implementations do define the behavior to be "call the member function with this == 0." Still, it's a sign of less than wonderful code.
Admin
Let's actually include some references here ...
http://tycho.usno.navy.mil/systime.html
http://tycho.usno.navy.mil/leapsec.html
http://whyfiles.org/shorties/187timeout/
Admin
Well, likely not, because the people who do all the official timekeeping don't actually use them. Leap seconds are used because the earth actually takes very slightly longer than 24 hours to rotate once. The time it takes it to rotate once is actually increasing, and it's not completely predictable. For example, the earthquake in the Pacific that caused the tsunami that was all over the news also slightly increased the rotation of the earth.
If you're trying to figure out where you are on the earth within a meter or two using a time signal from a satellite overhead, it's very important to know about leap seconds. At the equator, the surface of the earth is moving at 1000 miles an hour. That translates to 1467 feet of error if you're off by a second. So leap seconds that allow the exact rotation of the earth to be precisely timed are very important, even if they seem pointless and trivial.
Now your everyday business application isn't going to care, but the C library is used in a wide variety of places, so it does have to care.
Admin
Can't overload operators in Java, which is why comparing two objects of any kind requires you to use something along the lines of... "object.equals(other_object)", using the mere "==" actually compares identities (checking if the objects are two references of the same thing)
"==" works with primitive types though (raw C/C++ types \o/)
Admin
<FONT face="Courier New" color=#0000ff>I've seen another form of the if (this == null) construct in Java.</FONT>
<FONT face="Courier New" color=#0000ff>Foo foo = new Foo();</FONT>
<FONT face="Courier New" color=#0000ff>if (foo == null) return;</FONT>
What's wrong with that? That's not a WTF and is hardly the same as (this == null) which is just non-sensical.
In the Foo example above, what if the constructor had an exception or if the system did not have enough memory to create a new object?
Admin
This wouldn't be WTF if Graphics defined <FONT face="Courier New"><FONT size=2>op_Equality (operator==</FONT>)</FONT> in terms of checking an internal field. In this case <FONT face="Courier New" size=2>this == null</FONT> would resolve into a call to <FONT face="Courier New" size=2>Graphics.op_Equality(null)</FONT> which might just choose to check the null against anything it liked.
But Graphics doesn't implement op_Equality(). So WTF?
Admin
Leap seconds are observed at 11:59:60 UTC, so it wouldn't be the ball in New York that we have to worry about, but the...uh...whatever they have in London.
Admin
Then the code path would be aborted and resumed at the nearest exception handler. So the check would never be run anyway.
Admin
Triple leap seconds are not allowed in the current UTC definition.
Admin
He said that, if he just sticks return 5; in there it won't compile if there are statements after that. I've run into this before too, though I like to use 'if (3 > 2)' myself...
Admin
there's no wtf here. you need to do this in order to get -0.
p.s. has anyone ever mentioned that this forum software is a wtf?
Admin
if this is true, who ever designed it should be shot.
Admin
If autoboxing is in place, yes.
But if anyone has a java.lang.Boolean as a flag, that in itself is a WTF.
Admin
If that is
kill the developer.
Admin
Perhaps a micro-WTF in itself: in any languages I use, you can sign an integer 'foo' simply by the expression '-foo'. So multiplying by -1 seems like a silly way to accomplish the same thing.
Admin
Dereferencing a NULL or unitialized pointer to invoke a static method is defined and allowed by the standard. However, that isn't the case here since we are talking about testing this.
Admin
I love reading the WTF replies from people who have no idea what they are talking about.
In C++, the "isActive" example is perfectly valid (but verbose) because even a "bool" has more values than just true and false.
As others have already stated, "a + b == a" can be true for when "b != 0". Read up on floating point math.
Also, the "this == NULL" test is common in C++ (which many others have stated). For example, MFC uses that trick in get GetSafeHWND routine to return NULL when this is NULL.
Admin
Huh? And what other values are there besides true and false?
Admin
I find your ideas intriguing and wish to subscribe to your newsletter.
Admin
Not in the last 5 hours.
Admin
And, for integer types, practically any compiler rsp. processor translates this to a subtraction from zero, not a multiplication with minus one. For floating-point types, it's a simple bit flip.
Admin
See his first sentence. Perhaps he wanted to read his own post later.
Admin
You love reading your own posts?
Actually, that's complete and utter bollocks.Thanks for trying, anyway.
Admin
Well, the drafts for C++0x are rumored to contain the new "maybe" and "dunno" keywords.
Admin
I got the connotation that he got a compiler warning, rather than an error, and just wanted to shut off that particular warning without having to shut off a whole category of other warnings that he might actually want to see.
Admin
Admin
Uhh.... Have any of you actually read this code?? I think some of you need just as much help as the authors of these other samples.
f(x) = n - (2n) g(x) = n - n - n h(x) = -n
f(2) = 2 - (2*2) f(2) = -2
g(2) = 2 - 2 - 2 g(2) = -2
h(2) = -2
ok ... well now lets try another input:
f(-2) = 2 - (2 * -2) f(-2) = 2 + 4 f(-2) = 6
So now f is not the same as -x.
g(-2) = (-2) - (-2) - (-2) g(-2) = (-2) + 2 + 2 g(-2) = 2
ok. g(x) is equivalent to -x. h is obviously the same as g (as far as results go).
Just thought you guys ought to be more careful when posting things making fun of the author's inability to understand his own code.
Anyway. I'm done wasting my time here.
Admin
Do I smell chicken Vindaloo hehe [:)]
Yuri says you're being too negative [:D]
Admin
Is this a troll? It should be
f(-2) = -2 - (2 * -2)
f(-2) = -2 - (-4)
f(-2) = -2 + 4
f(-2) = 2
Admin
Nobody mentioned that you can negate an integer like this:
x = ~x + 1;
Isn't that significantly easier to maintain?? (sarcasm there...)
Admin
if(this == null)
this = new System.Drawing Graphics();
Admin
wtf?
I have no idea what you're trying to say with this.
Even if the syntax was correct it won't work; System.Drawing.Graphics has no public ctors.
Is that your point?
Admin
Reminds me of the 'verbose' way of describing (char) 0:
'-'-'-';
Admin
It's obvious now, looking at the code like this, what was wrong. But (and this is all from memory) it was long (2,000+), badly written, and we didn't have the luxury of debuggers. I just love reading core dumps.
The problem in debugging it was tracking down why looks were finishing early. But why was it written this way? There was a rumour amongst IBM Cobol programmers at the time that setting up a constant like this made it fractionally more efficient to write:
PERFORM BB00-MAINLINE VARYING WS-INDEX FROM 1 BY 1
UNTIL WS-INDEX > FIVE.
than
...UNTIL WS-INDEX > 5.
Those were the days.
I like to remember this code, because I hated it so much, as being the only piece of Cobol I maintained that had an altered GO TO in it. For thems that don't know about this abomination, you could (but would not, or I'll kill you) write this:
PP10-ALTER.GO TO.
and then elsewhere in the code have:
ALTER PP10-ALTER TO PP30-SOMEWHERE-ELSE.
Then when the code passes through PP10-ALTER, control immediately goes, well, somewhere else. There is never a good reason to use it. Dynamically modified code is just wrong.[N]