• (cs) in reply to emptyset
    emptyset:
    Anonymous:
    <FONT size=+0>IF</FONT> (current_num - prev_num = current_num) <FONT size=+0>THEN


    This is a method of testing that the change in numbers is
    too small to have any effect. I've seen and used that construct
    a lot in doing numeric analysis there the algorithm converges
    on some value.
    </FONT>

    <FONT face="Courier New" size=2>this is why mathematicians cannot program.  QED.</FONT>

    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

     

  • (cs)
    Alex Papadimoulis:

    It seems everyone has their own way of finding a way to avoid multiplying numbers by -1. Shaun Katona's colleague demonstrates another YAWN (Yet Another Way to Negate) ...

    <FONT color=#0000ff>int</FONT> makeNegative( <FONT color=#0000ff>int</FONT> n )
    {
      <FONT color=#0000ff>int</FONT> num;
      num = n - ( 2 * n );
      <FONT color=#0000ff>return</FONT> num;
    }

    Brilliant! But personally, I'd write it as:

    <FONT color=#0000ff>int</FONT> makeNegative( <FONT color=#0000ff>int</FONT> n )
    {
        <FONT color=#0000ff>return</FONT> n - n - n;
    }

    Looks cooler. Code must look cool.

    As a bonus, you can also have the following function:

    <FONT color=#0000ff>int</FONT> makePositive( <FONT color=#0000ff>int</FONT> n )
    {
        <FONT color=#0000ff>return</FONT> makeNegative(n);
    }

    Code reuse! Woot!

    --Rank

  • (cs) in reply to emptyset
    emptyset:
    Anonymous:
    <font size="+0">IF</font> (current_num - prev_num = current_num) <font size="+0">THEN


    This is a method of testing that the change in numbers is
    too small to have any effect. I've seen and used that construct
    a lot in doing numeric analysis there the algorithm converges
    on some value.
    </font>

    <font face="Courier New" size="2">this is why mathematicians cannot program.  QED.</font>



    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:

    if abs(current_num - prev_num) < min(abs(current_num),abs(prev_num),C1) * C2

    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.

  • (cs) in reply to Anonymous
    Anonymous:
    The time_t will have the same value, 1136073600, on both of those last two seconds. So there's no way localtime/gmtime can distinguish them, unless it does something really weird.


    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.
  • (cs) in reply to Anonymous
    Anonymous:
    The strftime() documentation is still wrong. Unless you modify a struct tm's fields yourself, the seconds will never be more than 59. struct tm's are generated by the gmtime and localtime functions, which take a time_t so there it no way they can distinguish between
    2004/12/31 23:59:60 and 2005/01/01 00:00:00, since they both would have a time_t value of 1104537600.

    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

  • (cs) in reply to emurphy
    emurphy:
    emptyset:
    Anonymous:
    <font size="+0">IF</font> (current_num - prev_num = current_num) <font size="+0">THEN


    This is a method of testing that the change in numbers is
    too small to have any effect. I've seen and used that construct
    a lot in doing numeric analysis there the algorithm converges
    on some value.
    </font>

    <font face="Courier New" size="2">this is why mathematicians cannot program.  QED.</font>



    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:

    if abs(current_num - prev_num) < min(abs(current_num),abs(prev_num),C1) * C2

    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.



    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.
  • (cs) in reply to Ronaldo Arribanorte

    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.

  • Ben Scheirman (unregistered) in reply to Alexis de Torquemada
    Alexis de Torquemada:
    Anonymous:
    That .NET one was pasted from Reflector, and you'll find a lot of that nonsense in the reflected code.

    Here's a pop quiz:  What's going on in this reflected code?

    public sealed abstract class Foo
    {
        //stuff
    }



    Seems perfectly alright to me if you don't ever want your class to be instantiated or subclassed. The C# compiler won't allow a mere mortal to write this, though. It would be better to just define only a private constructor.

     

    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

  • (cs) in reply to Maurits

    "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

  • (cs)
    Alex Papadimoulis:
    <font color="#0000ff">#ifndef</font> _IPProcess_h_
    <font color="#0000ff">#define</font> _IPProcess_h_

    <font color="#0000ff">#undef private
    #define private public
    #include <mtprocess.h> class</mtprocess.h></font> IP_MTProcess : <font color="#0000ff">public </font>MTProcess
    {
    <font color="#0000ff">public</font>:
    IP_MTProcess(pfnDoubleStatic func, <font color="#a52a2a">void</font>* arg1) : MTProcess(func, arg1, NULL) {}
    ~IP_MTProcess() { CloseHandle(_tid); }
    };
    <font color="#0000ff">#undef private
    #define private private

    #endif</font> <font color="#006400">// _IPProcess_h_</font>


    This reminds me of a most excellent post on the PHP manual I ran across:
    some fag:

    Lest anyone think this is somehow an omission in PHP, there is simply no point to having a protected or private constant. Access specifiers identify who has the right to *change* members, not who has the right to read them:

    // define a test class
    class Test
    {
      public static $open=2;
      protected static $var=1;
      private static $secret=3;
    }
    $classname="Test";

    // reflect class information
    $x=new ReflectionClass($classname);
    $y=array();
    foreach($x->GetStaticProperties() as $k=>$v)
      $y[str_replace(chr(0),"@",$k)]=$v;

    // define the variables to search for
    $a=array("open","var","secret","nothing");
    foreach($a as $b)
    {
      if(isset($y["$b"]))
      echo ""$b" is public: {$y["$b"]}";
      elseif(isset($y["@@$b"]))
      echo ""$b" is protected: {$y["@
    @$b"]}";
      elseif(isset($y["@$classname@$b"]))
      echo ""$b" is private: {$y["@$classname@$b"]}";
      else
      echo ""$b" is not a static member of $classname";
    }
    ?>
    As you can see from the results of this code, the protected and private static members of Test are still visible if you know where to look. The protection and privacy are applicable only on writing, not reading -- and since nobody can write to a constant at all, assigning an access specifier to it is just redundant.


    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.

  • (cs) in reply to Alexis de Torquemada
    Alexis de Torquemada:
    Alex Papadimoulis:
    <font color="#0000ff">#define private private
    </font>


    #define genius idiot

    The guy who wrote this is surely the greatest genius born to this world in a long time.



    Couldn't resist:

    #define paul brillant
  • (cs) in reply to tmountjr

    rather, #define paula billant

    :sigh:

  • Ian Griffiths (unregistered) in reply to Ytram

    Ytram:
    Matt B:
    Anonymous:
    Regarding the last example (dot net DrawImage method), I'm pretty sure the (this == null) check is useful when the method is invoked via reflection, and the "this" object is actually a parameter to the method invocation.  Can anyone confirm this?


    'this' is a reserved keyword, that code would never compile:

    Test.cs(17): Identifier expected, 'this' is a keyword



    That's essentially the point of the WTF in the code.  this refers to the instance of the object, and if it was null that method would never execute.

    I have no clue regarding Renaldo's comment, as my experience with Reflection in .NET is confined primarily to type checking and property information.

     

    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!

  • Alex (unregistered) in reply to Apoch
    Apoch:
    Alex Papadimoulis:

    public void DrawImage(Image image, int x, int y)
    {
    if (this == null) { throw new ArgumentNullException("this");
    }
    }

    I've seen this idiom quite a bit in C++ to help cushion against null pointer problems, since 0->func(a,b,c); compiles with thiscall as _decorated_func(0,a,b,c) -- but in .Net? WTF indeed...


    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.
  • luftwaffles (unregistered)
    Alex Papadimoulis:
    isActive = (isActive == <font color="#0000ff">true</font>) ? <font color="#0000ff">true</font> : <font color="#0000ff">false</font>;


    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?
  • Todd Aspeotis (unregistered) in reply to kipthegreat
    kipthegreat:
    Alex Papadimoulis:

    We'll start out with this simple piece of code that Jake Vinson tripped over while chasing bugs ...

    <font color="#0000ff">if</font>(3 < 4)
    {
    <font color="#0000ff">if</font>(chk.value == <font color="#ff0000">'Yes'</font>)
    fld.value = <font color="#ff0000">'No'</font>;
    <font color="#0000ff">else</font> fld.value = <font color="#ff0000">'Yes'</font>;
    }


    I've written code vaguely similar to this to trick the compiler, strictly debugging purposes.. I don't see how it applies here though.

    When I do it, it's usually because I want to return from a function early just to test something, say:

    <font size="1">int function() {
      statementOne;
     
      // <--   I just want to return a "correct" value here to see if it is the calling function that is the problem
     
      statementTwo;
     
      return realReturnValue;
    }</font>

    But if I just stick a "return 5;" in where my comment is, the compiler will complain that statementTwo can never be reached.  So I'll do this:

    <font size="1">int function() {</font>
    <font size="1">  statementOne;</font>
    <font size="1">  </font>
    <font size="1">  if (5 > 4)</font>
    <font size="1">    return 5;  // I just want to return a "correct" value here to see if it is the calling function that is the problem</font>
    <font size="1">  </font>
    <font size="1">  statementTwo;</font>
    <font size="1">  </font>
    <font size="1">  return realReturnValue;</font>
    <font size="1">}</font>

    And that is enough to trick the compiler.  But I don't see any reason for the WTF code, since it is not avoiding any compiler complaints.

    Are you stupid? Try replacing

    if (1 < 2) return 5;

    with

    return 5;

  • josh (unregistered) in reply to Apoch
    Apoch:

    I've seen this idiom quite a bit in C++ to help cushion against null pointer problems, since 0->func(a,b,c); compiles with thiscall as _decorated_func(0,a,b,c) -- but in .Net? WTF indeed...



    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.
  • Paul O (unregistered) in reply to CornedBee

    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/

  • (cs) in reply to Romeo
    Anonymous:
    Do they ever thought about a even more infrequent triple leap second?

    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.

  • (cs) in reply to John Smallberries
    John Smallberries:
    What if it's not a boolean?
    Couldn't it be some other type with the == operator overloaded?
    (I'm not that familiar with Java; does it even support operator overloading?)

    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/)

  • (cs) in reply to dubwai

    <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?

  • $$ (unregistered) in reply to Mung Kee

    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?

  • Anonymous (unregistered) in reply to Maurits
    Maurits:
    The next leap second will occur at the very end of December 31 2005.
    Let me count the new year down for you...
    2005/12/31 23:59:51 TEN!
    2005/12/31 23:59:52 NINE!
    2005/12/31 23:59:53 EIGHT!
    2005/12/31 23:59:54 SEVEN!
    2005/12/31 23:59:55 SIX!
    2005/12/31 23:59:56 FIVE!
    2005/12/31 23:59:57 FOUR!
    2005/12/31 23:59:58 THREE!
    2005/12/31 23:59:59 TWO!
    2005/12/31 23:59:60 ONE!
    <font style="color: rgb(255, 0, 0);" size="4">2006/01/01 00:00:00 HAPPY NEW YEAR!</font>

    It will be interesting to see if the ball drops a second early.


    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.
  • (cs) in reply to davidmwilliams
    davidmwilliams:

    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?

    Then the code path would be aborted and resumed at the nearest exception handler. So the check would never be run anyway.

  • dottedmag (unregistered) in reply to Romeo
    Anonymous:
    Maurits:
    sinistral:

    Are ya WTF-ed out yet? Let's hope not, otherwise you'd miss out on Duane Homick's discovery of the strftime documentation ...

    %S is replaced by the second as a decimal number [00,61].



    This is a WTF on the face of it, but there's a very good reason for seconds to includ e  61.  That would be when leap seconds happen, which they do periodically to allow clocks to  synchronize with the gradual slowing rotation of the Earth.


    Indeed, the linked manpage says just that:
    "The range of values for %S is [00,61] rather than [00,59] to allow for the occasional leap second and even more infrequent double leap second."


    Do they ever thought about a even more infrequent triple leap second?

    Triple leap seconds are not allowed in the current UTC definition.

  • Anonymous (unregistered) in reply to Todd Aspeotis
    Anonymous:

    Are you stupid? Try replacing

    if (1 < 2) return 5;

    with

    return 5;



    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...

  • (cs)

    if (trx.Amount < 0) trx.Amount = Math.Abs(trx.Amount); else trx.Amount = Convert.ToDouble("-" + trx.Amount.ToString());

    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?

  • er (unregistered) in reply to Ronaldo Arribanorte
    Anonymous:
    Regarding the last example (dot net DrawImage method), I'm pretty sure the (this == null) check is useful when the method is invoked via reflection, and the "this" object is actually a parameter to the method invocation.  Can anyone confirm this?

    if this is true, who ever designed it should be shot.
  • er (unregistered) in reply to Jenny Simonds
    Jenny Simonds:

    Alex Papadimoulis:

    And speaking of pointless code, John pulled this line of triply-redundant code from a Java production system that could be fairly easily simplified to ";".

    isActive = (isActive == <font color="#0000ff">true</font>) ? <font color="#0000ff">true</font> : <font color="#0000ff">false</font>;

    Not familiar with Java, but couldn't isActive have been set earlier to something like null, NaN, or undefined?


    If autoboxing is in place, yes.
    But if anyone has a java.lang.Boolean as a flag, that in itself is a WTF.
  • er (unregistered) in reply to dubwai
    dubwai:

    I've seen another form of the if (this == null) construct in Java.

    Foo foo = new Foo();

    if (foo == null) return;


    If that is

    Foo foo = null;
    try {
      foo = new Foo();
    } catch( Throwbale t ) {}
    if( foo == null) return;

    kill the developer.
  • David (unregistered)

    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.

  • Tim (unregistered) in reply to josh
    Anonymous:

    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.


    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.
  • Tim (unregistered)

    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.

  • Just (unregistered) in reply to Tim
    Anonymous:
    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.

    Huh? And what other values are there besides true and false?
  • (cs) in reply to Omnifarious
    Omnifarious:

    (...)

    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.



    I find your ideas intriguing and wish to subscribe to your newsletter.

  • (cs) in reply to III
    III:
    p.s. has anyone ever mentioned that this forum software is a wtf?


    Not in the last 5 hours.

  • (cs) in reply to David
    Anonymous:
    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.


    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.

  • (cs) in reply to Just
    Anonymous:
    Anonymous:
    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.

    Huh? And what other values are there besides true and false?


    See his first sentence. Perhaps he wanted to read his own post later.

  • (cs) in reply to Tim
    Anonymous:
    I love reading the WTF replies from people who have no idea what they are talking about.


    You love reading your own posts?

    Anonymous:

    In C++, the "isActive" example is perfectly valid (but verbose) because even a "bool" has more values than just true and false.


    Actually, that's complete and utter bollocks.Thanks for trying, anyway.

  • (cs) in reply to Just
    Anonymous:
    Huh? And what other values are there besides true and false?


    Well, the drafts for C++0x are rumored to contain the new "maybe" and "dunno" keywords.

  • (cs) in reply to Anonymous
    Anonymous:
    Anonymous:

    Are you stupid? Try replacing

    if (1 < 2) return 5;

    with

    return 5;



    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...


    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.

  • . (unregistered)

    public void DrawImage(Image image, int x, int y)
    {
    if (this == null)
    {
    throw new ArgumentNullException("this");
    }
    if (image == null)
    {
    throw new ArgumentNullException("image");
    }
    int num1 = SafeNativeMethods.GdipDrawImageI(
    new HandleRef(this, this.nativeGraphics),
    new HandleRef(image, image.nativeImage), x, y);
    this.CheckErrorStatus(num1);
    }

    If it's any consolation,
    if (this == null)
    {
    throw new ArgumentNullException("this");
    }
    has been removed from .NET 2.0

  • Just Another Hacker (unregistered) in reply to Rank Amateur

    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.

  • (cs) in reply to Stan Rogers

    Smeg off? Red Dwarf lives!

    Do I smell chicken Vindaloo hehe [:)]

     

    int makeNegative( <FONT size=+0>int</FONT> n )
    {
        <FONT size=+0>return</FONT> n - n - n;
    }

    Yuri says you're being too negative [:D]

  • (cs) in reply to WIldpeaks
    Just Another Hacker:

    ok ... well now lets try another input:

    f(-2) = 2 - (2 * -2)



    Is this a troll?  It should be

    f(-2) = -2 - (2 * -2)
    f(-2) = -2 - (-4)
    f(-2) = -2 + 4
    f(-2) = 2

  • steve dave (unregistered) in reply to emurphy
    emurphy:
    Just Another Hacker:

    ok ... well now lets try another input:

    f(-2) = 2 - (2 * -2)



    Is this a troll?  It should be

    f(-2) = -2 - (2 * -2)
    f(-2) = -2 - (-4)
    f(-2) = -2 + 4
    f(-2) = 2



    Nobody mentioned that you can negate an integer like this:

    x = ~x + 1;

    Isn't that significantly easier to maintain??  (sarcasm there...)
  • (cs)

    if(this == null)

    this = new System.Drawing Graphics();

  • (cs) in reply to Otac0n
    Otac0n:

    if(this == null)

    this = new System.Drawing Graphics();


    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?
  • Arachnid (unregistered) in reply to Rank Amateur
    Rank Amateur:
    Alex Papadimoulis:

    It seems everyone has their own way of finding a way to avoid multiplying numbers by -1. Shaun Katona's colleague demonstrates another YAWN (Yet Another Way to Negate) ...

    <font color="#0000ff">int</font> makeNegative( <font color="#0000ff">int</font> n )
    {
    <font color="#0000ff">int</font> num;
    num = n - ( 2 * n );
    <font color="#0000ff">return</font> num;
    }

    Brilliant! But personally, I'd write it as:

    <font color="#0000ff">int</font> makeNegative( <font color="#0000ff">int</font> n )
    {
    <font color="#0000ff">return</font> n - n - n;
    }

    Looks cooler. Code must look cool.

    As a bonus, you can also have the following function:

    <font color="#0000ff">int</font> makePositive( <font color="#0000ff">int</font> n )
    {
    <font color="#0000ff">return</font> makeNegative(n);
    }

    Code reuse! Woot!

    --Rank



    Reminds me of the 'verbose' way of describing (char) 0:
    '-'-'-';
  • (cs)
    Alex Papadimoulis:
    Laurie F wrote in to share a tricky bug that took almost a week to debug. It was about twenty-five years ago, and in COBOL on a good ole' IBM 4341. It may be in a foreign language to most here, but see if you can spot it yourself ...

           <FONT color=#a52a2a>77  FIVE               PIC S9(4) COMP     VALUE 4.</FONT>

     

    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]

Leave a comment on “The Friday Farrago ”

Log In or post as a guest

Replying to comment #:

« Return to Article