- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- 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
It's like Battlesheep, but with ships.
Admin
Firstly the obvious WTF comment that a boolean needs to be a byte rather than a bit so it can hold a FILE_NOT_FOUND value as well as a true or false...
Now to the real issue of which one gives you better "performance".
If you plan to store millions of these in memory then using a bitset will occupy less memory.
It is marginally quicker in processing time to test a byte for true/false rather than testing a bit in a bitset, which requires first working out which bit of which byte before actually doing the bitwise operation. In reality though it is constant time and very fast either way.
Most of the time, choosing between them is likely to be a premature optimisation. I have never yet seen an application significantly sped up because they used an array of bytes rather than a bitset. I have seen large scale applications that store large amounts of data where a bitset was therefore more appropriate although if the plan is to iterate through it finding which bytes are set, and they are sparse, this is a linear search which is of course slow.
Specialising std::vector<bool> to use bitset internally is a WTF and everybody in the C++ world now knows it is. It is a premature optimisation on space which breaks the generic behaviour of std::vector, e.g. you can't do &v[0] to get an array of bool, and various other operations that will give you bools by reference. They added std::bitset for those who want it (which is also a WTF as it is not resizeable). boost provided dynamic_bitset which really is the best option to use for a bitset.
Storing a bitset as a static table would not really improve any efficiency and it would of course be harded to maintain. I would probably use 0 and 1 rather than T and x but it doesn't make a huge difference.
Of course if you were unable to locate this static table on your system, the result of a query on one of its values would genuinely be "file not found".
Admin
My guess is that it was synthesized from an Excel table embedded in a Word document with "specification" or "requirements" in the title.
Admin
The movie Battleship was terrible. The script writers didn't even make the requisite "G4? It's a hit!" joke from the box cover.
[image]Admin
Isn't that "Bob" Dobbs on that cover?
Admin
I like how the men on the box cover are playing the game, whilst the women have to occupy themselves with the dishes!
Admin
The actual WTF here is that he deleted the file containing the table, and missed a part of the code that still relied on it.
When that part of the code ran and tried to acquire the boolean result for the number, it got FILE NOT FOUND.
Admin
Don't know if trolling or assembly programmer, but I'll bite. I have one word for you: abstraction. And it is your friend, your god, and your savior at the same time. Therefore you say thank you and make good use of it. The guy who wrote this code didn't.
Admin
That table and the state variables reminds me an awful lot of the control PLA on the 6502. It's a big table very similar to that, and works under a similar principle.
Admin
As bad as the code is, it would have been worse if the table were filled with "F"s for false. Just try to find that lone F in a sea of Ts, or vice-versa.
And you "memory is cheap" people have obviously never had to write embedded firmware for a processor with 16K of memory. And no file system...