| « Prev | Page 1 | Page 2 | Next » |
|
Why? That's stupidity personified. Well, unless something called a global boolean is really something else, which would be far scarier still.
True cargo-cult programming here. |
Re: Globally Local
2007-08-10 10:15
•
by
Andy Goth
(unregistered)
|
|
I hope that semicolon is part of the joke...
|
Re: Globally Local
2007-08-10 10:18
•
by
Andy Goth
(unregistered)
|
|
Nice Richard Feynman reference. The "cargo cult" concept has been very useful to me in understanding many of the WTFs I encounter from day to day, technical and nontechnical.
Do I know you from the Tcl Wiki, or are you another DKF? |
|
While the use of globals may be contentious the code presented doesn't seem like a WTF to me. It looks like a singleton design pattern that initialises the resource from a external location. Of course it is not a thread safe implementation - but given no context as to where the code came from this may or may not be a WTF.
|
You mean you think there might be another one of me? Scary! (Yes, I hang out on that wiki.) |
|
All the code does is return bGlobalBool every time. Why write code that does nothing?
|
Re: Globally Local
2007-08-10 10:26
•
by
Andy Goth
(unregistered)
|
|
"Scary" must be the word of the day. I wonder if it's one of the CAPTCHAs this site uses. (Mine was "howdy", probably in honor of the state in which I live.)
|
|
As someone already pointed out, this is just a common implementation of a singleton using stupid variable types.
However, like this code, the vast majority of singletons I have seen over the years are just as dumb as this code because the implementor knew that "global variables are bad". As Sutter once said, "Singletons are just a global variable in sheep's clothing." Singletons have some important use cases, but they also have the same vast majority of design issues as global variables. Just different initialization characteristics. |
|
Global variables are bad because of the potential for naming conflicts (OHHHH, it's a JOOOKE, nevermind).
Oh, I get the WTF now, it's because they didn't explicitly put an access modifier in there. It was so obvious! |
|
The goggles do nothing!
|
|
Wow... I think i may need to steal that code... its so elegent. so amazing. so... so...
Globals = Bad because when students use globals you come out with code like: int someNum = 0; foo(){ //some code here someNum = 1; bar(); //some more code here } bar(){ // some humanly unreadable code someNum = 2; // some more code that is humanly unreadable } TEACHER TEACHER... SOMENUM IS 2 FOR SOME WIERD-O REASON! I THINK COMPUTERS ARE OUT TO GET ME! And thats why, kids, global variables just may be the spawn of the devil! |
|
It's not a singleton pattern because this code is all contained in a single method (hence the multiple references to "local" in the title and preamble). Thus, bInitialized will always be false when it's called, and as it was pointed earlier, the method will always return the contents of bGlobalBool. It really makes no difference that any of those locals happen to be declared static.
Also interesting to note that even if this really did implement a singleton (which, if this is C code, would require bInitialized and bBoolToReturn to be uh, global), then it would be an incorrect implementation, because it would return the wrong value if bGlobalBool were ever changed after the first method call. So basically, out of sheer luck, the programmer managed to write a function that's merely pointless and not buggy or harmful. I would call this cargo cult programming as well - he thought he was writing a singleton because it sort of looked a bit like a singleton with the static declarations, but it's actually not even close. |
Re: Globally Local
2007-08-10 10:46
•
by
H. Sluga
(unregistered)
|
|
bIninitialized won't always be false when it's called; it's static, so it will be false only the first time.
There is potentially a side-effect-as-point-of-the-function here if bGlobalBool is an object with a (bool) cast. |
bInitialized will only be false the first time the function is called (the state of static local variables is preserved between function calls) so this will always return whatever the value of bGlobalBool was the first time the function was called. I can think of easier ways to store the value of a variable... |
Here, in part, is why it's a WTF... Because this does exactly the same:
Which is not quite the same as this:
Since the latter will always return the current value of bGlobalBool, while the former (and the original post) return the value of bGlobalBool at the time of the first call. WTF knows what is really wanted... But at least the person writing it should have known how statics worked. |
Re: Globally Local
2007-08-10 10:51
•
by
FailedToEnterMyNameException
(unregistered)
|
|
the real wtf is this discussion - i BET the author didnt think of singletons!
CAPTCHA: gygax - wtf is that? |
Gary Gygax was one of the original authors of the Dungeons & Dragons game system. |
|
OK, I guess my C is worse than I thought. You're right, the static will be preserved. In which case, it really is buggy code because it's only guaranteed to return the correct value of the global variable the first time it's called. And if that's the intent, it's certainly not clear.
|
|
This code might be correct if person, who wrote it, just want always return value bGlobalBool which was on the first call ReturnBool, because bGlobalBool can be changed latter.
|
Since software development is not my full-time job, I had never heard of the "singleton" design pattern. So, I did the usual Google search & found a Wikipedia article. It had the following delightful explanation:
Now, there have been quite a few new programming languages created in the time since I studied programming...but having a method which creates new languages is a bit of overkill, IMO. |
Re: Globally Local
2007-08-10 11:10
•
by
PeterE
(unregistered)
|
Its a singleton that initialises from a global resource at the first time the routine is run. After the routine has been run then the global can be changed without affecting the internally saved value. This allows you modify the global during program execution and control when the internal copy is updated (which is really on program restart). Yes it is badly coded, but IMO it is functional. The problem with WTFs like this is there is no context. We don't know where the global comes from, why its being buffered like this or in how many locations this routine is being called from. The only thing you can say (as has previoulsy been pointed out) is that you can refactor the code to remove the "if" statement. |
|
I'm sorry but I don't see what's wrong with that CodeSOD !!
You guys miss the point.. This function will always return the VALUE THAT bGlobalBool HAD THE FIRST TIME the function is called If that's what the author intended, then it's fine, and you tell me how to do otherwise (in C in an encapsulated manner) |
Re: Globally Local
2007-08-10 11:16
•
by
PeterE
(unregistered)
|
Gotta love Wikepedia .. If an infinite number of Monkeys with typewriters can produce Shakespeare in an infinite amount of time, then that qoute looks like 10 Monkeys in 1/2 hour. |
Yes, it looks that way to start with. But the problems run deeper than that. Firstly, there is no guarantee of when the global will be read, so who knows what value it will get. Secondly, they're not using double-checked locking, so either they're single-threaded or the behaviour is even less defined. Thirdly, there's a good chance that the previous points are moot because the global is actually constant in value in all practical senses, rendering this code a piece of valueless rococo voodoo. In short, either the code is pointless or its wrong. |
It means that you're clueless. Typing your captcha was our first hint, but not knowing who Mr. Gygax is sealed the deal. |
There is no indication that that's the intent, though. Of course it could be anonymization, but I'd expect to see a word like "buffer" or "cache" in there. It's not logical that the contents of a global variable (especially a primitive type) would be cached throughout the entire lifetime of an application, and since the variables are local to that method, there is no way they can ever get updated without restarting the program. This is either a horribly botched singleton implementation, or an even more botched MRSW implementation. |
Re: Globally Local
2007-08-10 11:31
•
by
psmears
(unregistered)
|
Perhaps you should go re-read K&R: the "static" does make a difference (it effectively turns the local variables into globals), so this *is* a singleton (of sorts)... |
"the static keyword specifies that the variable has static duration (it is allocated when the program begins and deallocated when the program ends) and initializes it to 0 unless another value is specified." So if the global variable is modified after program start (but before the function call), then your function will fail, while the original won't. Well OK, they'll work differently. |
Re: Globally Local
2007-08-10 11:56
•
by
Sgt. Preston
(unregistered)
|
Either you had a corrupted document in your browser or that Wikipedia article has been cleaned up since you posted, because the bizarre statement you quoted is not there. The (formerly or allegedly) garbled sentence reads:
|
Re: Globally Local
2007-08-10 12:14
•
by
the littlest hobo
(unregistered)
|
|
Just cleaned, by likely wtf reader DocSigma.
http://en.wikipedia.org/w/index.php?title=Singleton_pattern&diff=150407118&oldid=149987640 |
|
In Python, rebinding globals to a local scope is a well-known speed trick, indeed :-)
(note: the speed gain may be less than zero if you have no fancy loops) |
That quote from the MSDN Visual C++ article is a bit misleading as a static variable defined in a function may be allocated at startup but it is *not* initialized at startup. It is initialized when the function is first called. |
Edit: Never mind, you just came late to the party and obviously didn't read the other comments. That point was already addressed. |
My Java's still kind of rusty. Does that copy the value of bGlobalBool into bBoolToReturn, or does it just create a reference. Even if it is copying it, that's still some wierdness. "This function returns whatever the value of bGlobalBool was when this function was first called." Addendum (2007-08-10 12:40):
My Java's still kind of rusty. Does that copy the value of bGlobalBool into bBoolToReturn, or does it just create a reference. Even if it is copying it, that's still some wierdness. "This function returns whatever the value of bGlobalBool was when this function was first called." Edit: Yeah that does look more like C. Why did I assume it was Java? |
|
Nothing wrong with it, its just a bit mislabeled! ;D
bool Latch(void) { static bool bLatchValue = false; static bool bLatchInitialized = false; if (bLatchInitialized == false) { bLatchValue = bGlobalBool; bLatchInitialized = true; } return bLatchValue; } Cheers! |
...IF you can trust your compiler, and if you're coding in C++. Some of the compilers I stopped using years ago would get static local variable initialization wrong. Regardless of what the code says, static variables would be initialized to zero, especially in .so's. This would wreak havoc on non-trivial classes that expected their pointer members to be non-NULL. C doesn't have initialization of anything from non-const expressions, of course, so the if statement is required in that language. IIRC (I do have the ISO C++ standard, but I'm too lazy to read it today ;-) C++ requires special scope-based, thread-safe initialization magic for static local variables, but no such magic for globals, file-scoped statics, or static members. A lot of people don't know this, and assume that static local variables behave like all the other kinds of static-ish variables, which are initialized in undefined or implementation-defined order before main(). This is of course wrong, but writing with the 'if' statement works both ways. |
Re: Globally Local
2007-08-10 13:00
•
by
Anonnmouse GuY
(unregistered)
|
Hmm, gcc 2.95,3.3,4.0.4,1 won't compile with that, gives me an error:
Although, g++ 2.95,3.3,4.0.4,1 will compile it, and it acts the same as the original. Perhaps the compiler they were using gave them that error, because using the if/then that was in the original does work in GCC. |
Re: Globally Local
2007-08-10 13:01
•
by
Anonnmouse GuY
(unregistered)
|
Hmm, gcc 2.95,3.3,4.0.4,1 won't compile with that, gives me an error:
Although, g++ 2.95,3.3,4.0.4,1 will compile it, and it acts the same as the original. Perhaps the compiler they were using gave them that error, because using the if/then that was in the original does work in GCC. |
Not quite, it returns the value that bGlobalBool had the first time the function is called. If bGlobalBool is later changed, this function will never notice. |
Re: Globally Local
2007-08-10 13:15
•
by
Anonymous Pedant
(unregistered)
|
Actually, an infinite number of monkeys will produce Shakespeare in exactly as long as it takes to type the work in question. Comes to that, they'll produce an infinite number of copies. (Good luck finding one though....) |
Ever heard of Wikipedia vandalism? All it'd take for you to see the correct definition is to look at the history of this page. Duh. |
Nope. Consider yourself 100% clueless about how Wikipedia works. Big deal, so there are idiots out there who will wreck perfectly good entry for no reason... and then comes a fool like ya who has no clue, too. Cheers! |
OK, I got un-lazy and decided to look this up:
In other words, the bBoolToReturn could contain *either* the value of bGlobalBool some time between program start and calling main(), *or* the value of bGlobalBool the first time ReturnBool is called, depending on the compiler. The C++ standard considers either to be correct. Yeouch! |
No surprise--you can't initialize global or static variables with non-constant values in C, period. Constructors are a C++ feature. |
Re: Globally Local
2007-08-10 14:30
•
by
psmears
(unregistered)
|
Hmm, I seem to be accessing the page through some sort of webcache that is introducing a delay... when I refreshed just before posting, yours was the last comment there :-/... sorry about that! |
|
The joke is that static variables are just as inefficient as global variables. Did everyone ignore the sentence "gain all the benefits of global variables without hampering performance too much" ??
Lemme explain for those who don't think in assembly (and still write code in C++): Static variables have static allocation, and global variables have static allocation: the runtime doesn't care about the artificial concept of "scope", which is all the code snippet introduces. |
|
What if you were to reference a local variable with a far pointer??? How close is that variable
|
|
Regarding wikipedia, someone just did an edit and accidentally erased the words: "one. If the programming" so that two adjacent sentences ran together.
Captcha: Sanitarium. "Is that where they're taking me? Because if it's cleaner than my home with the filthy filthy germs that are everywhere and oh god must keep scrubbing..." |
Actually, that's not entirely true. Shared library runtimes care very much about the concrete concept of "visibility". ELF shared library symbols are visible (exported) by default (some would argue this is a WTF in itself, but it's the way ELF works). Global variables have externally visible symbols, which means that they must be resolved against the symbol table either at dynamic link time or on first use. That includes global variables that are both defined and used in the same shared library. ELF allows you to have the same global variable defined in multiple shared libs, but have all the libraries use a common instance of that variable. Accidental name collisions can occur, and when they do they usually ruin your day. Static variables, on the other hand, can be referenced by a simple offset from the start of the library's data section every time the variable is used. No symbol lookup is required, because there is no way the symbol could possibly be defined or used in another library in a way that refers to the same variable (that's what "static" means, after all). Symbol lookup is quite slow compared to integer addition, so avoiding lookup makes the code go faster. Even if the global symbol's address is cached after lookup (which of course it is), it's still very slightly slower to use than the static symbol. Also, dynamic linking time is proportional to the number of symbols in the library, so a static variable is cheaper at load time as well. Of course, non-exported global variables are just as fast as static variables. The linker treats such variables as global while building the library, then discards their symbols (so the variables appear to be static from the point of view of some code outside of the library) once all the objects in the library are built. If you're really evil, you can force the dynamic linker to do relocation on the shared library (which rewrites the library at dynamic load time so that it doesn't need to do symbol table lookups, but at the expense of longer startup time and more memory consumption). In that case, there is no difference between static and global variables any more (all references to them in the code have been replaced with absolute addresses), but the cost of this "optimization" is astronomical compared to the benefits in most cases. a.out shared libs solve this problem by fixing the address of every global or static variable ever defined. By anyone. Ever. Worldwide. Needless to say, this solution scales so badly that nobody bothers to use it any more. There are other ways to reduce the cost of global or static variables. For example, in theory function bar is faster, even if the code is identical except for replacing 'i' with 'my_i':
|
| « Prev | Page 1 | Page 2 | Next » |