Comment On In the Shadow of Giants

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

it should be 37 =)

Didnt something complain about use before initalization here?

LOL good one :)

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

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

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.

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.

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

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.

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

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

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.

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.

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

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?

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?

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.

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

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

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

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

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!

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?

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?

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

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

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

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

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

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

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.

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?

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

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

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.

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

Ram is cheap (mostly)
Compilers optimize away redundancy

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

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

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

}

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

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.

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!

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

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

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

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.

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.

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

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!

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