• Cube (unregistered)

    I would think that newer compilers would have a warning about shadowing in this situation, but maybe warnings were disabled.

  • bluerere (unregistered)

    it should be 37 =)

  • cardboard box (unregistered)

    Didnt something complain about use before initalization here?

  • (cs)

    LOL good one :)

    Reminds me of Matlab, where you do "global SomeVariable" to do what this guy did here.

  • artcodex (unregistered) in reply to Cube

    There is no shadowing, the original variable is in the local scope of the constructor

  • Mystified (unregistered)

    On the flip side, I constantly come across crap like this:

    public SomeType SomeProperty { get { SomeType typeInstance = new SomeType(); typeInstance = SomeType.SomeFactoryMethod(); return typeInstance; } }

    I guess they want to make sure the garbage collector doesn't get bored, or maybe they like tripling up on lines of code. Regardless, it kind of defeats a key purpose of the factory pattern to have a public constructor, let alone to use it to create a throw-away object.

    Morons.

  • Mystified (unregistered)

    On the flip side, I constantly come across crap like this:

    public SomeType SomeProperty { get { SomeType typeInstance = new SomeType(); typeInstance = SomeType.SomeFactoryMethod(); return typeInstance; } }

    I guess they want to make sure the garbage collector doesn't get bored, or maybe they like tripling up on lines of code. Regardless, it kind of defeats a key purpose of the factory pattern to have a public constructor, let alone to use it to create a throw-away object.

    Morons.

  • vP (unregistered)

    nSomeValue is a local variable declared both in constructor and Accessor. It is not a class attribute, so visibility is messed up. How come the compiler is not complaining about using uninitialized variable in printf()?

  • Buggz (unregistered)

    My guess is it's because ints are a primitive type and don't have constructors, hence nSomeValue gets initialized with a rather random value when created.

  • Mystified (unregistered)

    Sorry 'bout the double-post. Not sure how that happened.

  • Harro (unregistered)

    It's a miracle if you do get 42 as a result !

  • Mystified (unregistered) in reply to Buggz

    Not to nitpick, but the value isn't "random". The value is precisely what was already in that location in the stack frame's memory where the variable is put.

  • Cable (unregistered)

    I'm not so sure what I should say about that... maybe autsch does the trick. Maybe they thought the compiler should be able to find the sourcefiles where the programmer didn't know about local and global scope. I always thougt dau's were just users not programmers, clearly if been wrong.

  • dkfal (unregistered)

    I ran this code 2,390,298 times and it did not give 42 once.

  • (cs) in reply to dkfal
    dkfal:
    I ran this code 2,390,298 times and it did not give 42 once.

    The FOOLS! When will they learn to run it 2,390,299 times?

  • leeg (unregistered) in reply to Oliver Klozoff
    Oliver Klozoff:
    dkfal:
    I ran this code 2,390,298 times and it did not give 42 once.

    The FOOLS! When will they learn to run it 2,390,299 times?

    Next time?

  • (cs)

    I never considered myself an awesome programmer. Just a competent one, but I still suffer from an overly large sense of modesty. Seeing things like this make me feel much better about myself.

  • cardboard box (unregistered) in reply to bonzombiekitty
    bonzombiekitty:
    I never considered myself an awesome programmer. Just a competent one, but I still suffer from an overly large sense of modesty. Seeing things like this make me feel much better about myself.

    I second that wholeheartedly :D I know Im not the best programmer on the planet but atleast I know Im not the worst :D

  • Christian Gudrian (unregistered)

    Recently I was asked by a fellow programmer, why the following routine's return value was corrupted every once in a while:

    char * getName()
{
   char temp[255];
   getNameFromSomewhereElse(temp);
   return temp;
}

    Christian

  • (cs)

    I've dome something very much like this, where a superclass had a variable called "mVariableName" and my method had a parameter named "inVariableName", where I assigned some value to one and read it from the other. Surprisingly, it worked on my machine, and I didn't catch it at all until it was tested on a machine with a different architecture...

  • (cs)

    Apparently someone needs to learn about variable scope!

    I don't consider myself a programmer and I know this. Perhaps being a programmer isn't quite the awe-inspiring state of mind I imagined it to be...

  • An apprentice (unregistered)

    Naming a method 'Accessor' so that it would somehow do the right thing... I too hope the computers will be able to write programs by themselves someday!

  • Anonymous (unregistered) in reply to Cable
    Cable:
    I'm not so sure what I should say about that... maybe autsch does the trick. Maybe they thought the compiler should be able to find the sourcefiles where the programmer didn't know about local and global scope. I always thougt dau's were just users not programmers, clearly if been wrong.

    You haven't been around here for too long, have you?

  • Newbius Maximusq (unregistered) in reply to Cube
    I would think that newer compilers would have a warning about shadowing in this situation, but maybe warnings were disabled.
    ...or just ignored. Some of my co-workers at a previous job didn't think there was any reason to worry if their application compiled with (literally) 1000 warnings - hey, it compiled, right? What could POSSIBLY go wrong?
  • FDF (unregistered)

    I hope they used better code when simulating the computer that gives the correct answer to the ultimate question of life, the universe, and everything, which is used by the computer build to find the ultimate question of life, the universe, and everything

  • brian (unregistered)

    code like this makes a complete mockery of the 4 years i just spent learning computer science

  • Marcin (unregistered)

    The real WTF is of course that they decided to violate encapsulation by having an accessor.

  • (cs) in reply to brian

    With this kind of code, how did they even produce anything that would work?

  • Zaphod Beeblebrox (unregistered)

    Well, why would it print 42? That's the answer to Life, The Universe and Everything so it's a difficult answer to come to. Hell, it took Deep Thought 7 million years!

    captcha: atari (hardly Deep Thought!)

  • (cs) in reply to clevershark
    clevershark:
    Apparently *someone* needs to learn about variable scope!

    I don't consider myself a programmer and I know this. Perhaps being a programmer isn't quite the awe-inspiring state of mind I imagined it to be...

    Chess players are placed on a similar pedestal.

    "Wow, you actually play chess in tournaments? You must be pretty smart to do that!" "Um, no, it just means I like to play chess." (It also solidifies nerd status, but I don't mention it, since that's usually implied.)

  • CHound (unregistered) in reply to Volmarias
    Volmarias:
    With this kind of code, how did they even produce anything that would work?

    To paraphrase the first HP Movie - "5 points are awarded for Sheer Dumb Luck!"

    My personal favorite is a program that compiles perfectly on the development system but generates REAMS of erros on the production system because someone changed the environment to point to a different build version of the compiler.

  • Cochrane (unregistered)

    What wonders me most is why they even ask why this isn't working. It looks like someone said "Hey, I'll try that instance variable thing", and then it didn't work. Wouldn't the logical course of action be: Re-read where you first heard about instance variables, and compare it to what you have?

  • (cs)

    Fixed it:

    class Something{
  public:
    Something() { int nSomeValue = 42; }
    void Accessor(void)
    {
        int nSomeValue;
        printf("%d\n", 42);
        // Problem solved. Always prints out '42'!
    }
}

    --Rank

  • (cs) in reply to Cube
    Cube:
    I would think that newer compilers would have a warning about shadowing in this situation, but maybe warnings were disabled.

    The shadowing is only in your mind. (And in the title. "In the Broken Scope of Giants" sounds stupid.)

  • (cs) in reply to Mystified
    Mystified:
    Not to nitpick, but the value isn't "random". The value is precisely what was already in that location in the stack frame's memory where the variable is put.
    It's not truly "random", but being that unless you specifically plan for this case there's little way to predict exactly what will be in that part of memory when you access it, it might as well be random.

    I think it was clear enough what the original poster meant, and anyone should have been able to figure out the intent. You really were just nitpicking for the sake of nitpicking, I dare say.

  • weeyin (unregistered)

    And what's with the 'printf' in a C++ program ?

  • BenM (unregistered)

    Ram is cheap (mostly) Compilers optimize away redundancy

    Please initialize your variables, and learn the keyword "static" for your return variables.

  • (cs) in reply to BenM
    BenM:
    Ram is cheap (mostly) Compilers optimize away redundancy

    Please initialize your variables, and learn the keyword "static" for your return variables.

    Please, please tell me that your comment about statics for return variables is a joke...

    Please don't return references to local statics. Either return a copy, or design your interface to require users to pass in a reference for output. Statics are not threadsafe, and are confusing as all hell for maintenance programmers.

    I once saw a function that was indirectly recursive (A calls B calls C calls A) with local statics, and the return value was placed in the local static. That's a hell of a tough function to debug...

  • GUnit (unregistered) in reply to Rank Amateur

    You silly goose, this is a better approach:

    class Something{

    public:

    Something() { int nSomeValue = 42; }

void Accessor(void)

{

    int nSomeValue;

    while(nSomeValue != 42)
    {  
      printf("%d\n", nSomeValue);

      // Problem solved. May take a while though
    }
}

    }

  • (cs)

    Aw come on - I'm in IT, and I understand this one! Classic!

    (And BTW, some of us mere IT people fix programs to boot! But only WTFs like this, usually...) ;)

  • (cs) in reply to Cube

    For the love of C, don't even try to blame this one on a "dumb comp. sci. graduate". If there's one thing that's hammered into our heads, it's that local variables are put on the stack and can't be used outside of a function.

    This looks like somebody's first time using classes and instance variables. Especially with the cluelessness as to why it wouldn't work.

    Seriously, can we come up with some standardized test to prove that you are a programmer and not just a cheap hack? I stopped seeing this crap from students by the end of second year classes.

  • Peter (unregistered) in reply to GUnit
    GUnit:
    You silly goose, this is a better approach:

    class Something{

    public:

    Something() { int nSomeValue = 42; }

void Accessor(void)

{

    int nSomeValue;

    while(nSomeValue != 42)
    {  
      printf("%d\n", nSomeValue);

      // Problem solved. May take a while though
    }
}

    }

    actually as your not changing the memory location you are looking at or the value in it, thats an infinite loop unless 42 is in there to start with. Unless printf modifies its parameters now :P!

  • James (unregistered)

    My guess is that this is the result of a veteran of some language that doesn't require variable declaration (and possibly has no concept of scope) iteratively fixing compiler errors.

    Something() { nSomeValue = 42; }

    "Hmm... compiler complains that nSomeValue isn't a declared varaible. I'll fix that!"

    Something() { int nSomeValue = 42; }

    "OK, it stopped complaining."

    printf("%d\n", nSomeValue);

    "WTF? The compiler seems to think nSomeValue doesn't exist again? Maybe if I remind it what type it is... stupid C with its strong types..."

    int nSomeValue;
printf("%d\n", nSomeValue);

    "There we go -- it stopped complaining. Jeeze, what a dumb complier to forget what type it is from one line to the next. DWIM (do what I mean) already!"

    The dangers of letting people learn Basic...

  • DrYak (unregistered) in reply to Cube
    Cube:
    I would think that newer compilers would have a warning about shadowing in this situation, but maybe warnings were disabled.

    Test.c :

    #include <stdio.h>
#include <stdlib.h>

int main () {
    int bork;

    printf("bork : %d\t%08x\n", bork, bork);
    exit (0);
}

    gcc -pedantic -Wall -x c -std=gnu99 -o test test.c

    gcc -pedantic -Wall -x c++ -std=gnu++98 -lstdc++ -o test test.c

    Then :

    ./test

    bork : -1208837232 b7f29b90

    Using latest extension, neither C nor C++ version did complain about non-initialised memory.

    Good practice should recommend to always initialise variables to something. In case where that value is unused, the optimizer will drop useless writing to variable (unless variable is of 'volatile' type and its value could be accessed by background procedure between two writes).

    But compiler should detect this situations (they are already able to keep track of this kind of stuff for their optimizers) and emit a wraning, because this could lead to data corruption. (Imagine if the wasn't an int but a pointer. That the code checked for NULL before writing some data, and that the memory spot was previoulsy containing some valid memory address - like the pointer from some critical piece of data).

  • Stormy (unregistered)

    The real WTF here is that the site is called "Worse Than Failure". When I looked at the code, I said out loud, "What the F*ck?", not "What the Failure".

  • Martin T (unregistered)

    Nice bork program, but gcc will complain if you comile with -O.

    The problem is that without any optimization, the compiler don't generate the structures needed to find uninitialized variables.

    Conclusion: Always compile atleast with -O. It's not much slower, and it causes -Wall to generate lot's of usefull warnings.

  • Eam (unregistered) in reply to Saladin
    Saladin:
    It's not truly "random", but being that unless you specifically plan for this case there's little way to predict exactly what will be in that part of memory when you access it, it might as well be random.

    I think it was clear enough what the original poster meant, and anyone should have been able to figure out the intent. You really were just nitpicking for the sake of nitpicking, I dare say.

    Actually, it's a pretty important nitpick. The fact that it's not truly random may very well mean that it almost always has a reasonable value on a particular machine. If the initialization problem isn't as stupidly obvious as this case, the fact that it's not random could make for a real debugging nightmare.

  • ManicMailman (unregistered) in reply to Martin T

    Jeez... Visual C/C++ has been warning about using uninitialized variables since at least VC 6 (example is without optimizations, but you get the same warning with them):

    C:\Temp>cl /Od bork.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

    bork.c bork.c(13) : warning C4700: local variable 'bork' used without having been initialized Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

    /out:bork.exe bork.obj

  • (cs) in reply to clevershark
    clevershark:
    Apparently *someone* needs to learn about variable scope!

    I don't consider myself a programmer and I know this. Perhaps being a programmer isn't quite the awe-inspiring state of mind I imagined it to be...

    There's a big difference between imagining that you're a programmer, and actually being one!

  • (cs) in reply to James
    James:
    My guess is that this is the result of a veteran of some language that doesn't require variable declaration (and possibly has no concept of scope) iteratively fixing compiler errors.

    Such as JavaScipt :)

    
<script>

function Something()
{
   this.nSomething=42;
   this.Accessor=Accessor;
}

function Accessor()
{
   alert("Problem Solved! "+this.nSomething);
}

something=new Something();
something.Accessor();

</script>

    I used to have so much fun with classes in JavaScript, you've got to love a language that lets you redefine the interface of an object on the fly :D

Leave a comment on “In the Shadow of Giants”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article