| computerquip (1892) | |
|
Static class variables create a static variable shared by all of the class instances. It doesn't recreate the variable for each object. There is absolutely no reason to read in the file each time a bunny is made. That comment is fine. The reason it's part of the class (and private at that) is to prevent anyone outside of Game from using it. This is more or less a guide line for myself. http://codepad.org/x0FIB01E @bMutantRadioactiveVampireBunny variable: That's why the comment "Don't do this at home" is there. It's more of a joke, but it does apply. Almost anything I code can normally be justified to some extent. I will take any suggestions but saying things like, "WTF!?!" isn't exactly productive. Please provide alternatives and I'll will try them out and weigh out the differences. Until then, I'm still studying decent ways to provide logging and then afterwards, I'll grab a curses implementation and try to code this to work in a grid. That'll be fun. :D EDIT2: @Funky comment: I actually switched gender from the identifier of sex. My laptop has this issue where if I hover my finger over the pad, it will click and drag so I'll occasionally find strange compiler errors where I'll find half a word placed in some random place. Thank god for whoever came up with the Undo feature. | |
|
Last edited on
|
|
| firedraco (5414) | ||
Actually, I don't think it should be static, since if I create several games, they shouldn't all be using the same vector. They should all have different vectors. | ||
|
|
||
| computerquip (1892) | |
|
That would use an intense amount of excessive memory. If each bunny were to have its own vector, that's each file loaded into memory however many bunnies are made. If I load it into the Game, that's fine but I still don't see the point. The files will never change and the original list is still valid. Why would I want to not use the already valid list? | |
|
|
|
| Duoas (6734) | |
| For these purposes, a static vector is fine. | |
|
|
|
| Albatross (3551) | |
|
@computerquip's first post on this page: It was a joke. I think the variable name is brilliant. The problem called for Mutant Radioactive Vampire Bunnies, and you gave it just that. Though, you could have had somewhere #define bMutantRadioactiveVampireBunny bMRVB to save yourself typing.-Albatross | |
|
|
|
| helios (10126) | ||||
He also seems to have a strong bias to languages that typically run in managed environments.
That was terrible, I apologize. | ||||
|
Last edited on
|
||||
| firedraco (5414) | ||
Ew, defines. evil! http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.4 I would suggest just making the variable name shorter or if you REALLY don't want to, just make an accessor function that has a shorter name. | ||
|
|
||
| Albatross (3551) | ||
Gee, it seems that almost everything in C++ is evil. Next thing you'll be telling me is that volatile pointers are evil. -Albatross | ||
|
|
||
| helios (10126) | |
| While I generally agree that the FAQ is rather quick to classify C constructs as "evil", #defining a symbol as something else is quite nasty. It makes it much harder to know what a given piece of code is doing. One of the problems is that macros, unlike pointers or references, have no scope. The macro could even appear before the symbol itself is declared, or in a different file altogether. It's like symbol-level spaghetti code. | |
|
Last edited on
|
|
| Albatross (3551) | ||
That's perfectly true, due to the nature of C++ preprocessor, and I'm not disagreeing with you on that front. I'm only say its a potential solution, though I should go back and edit the post say "at the very top of the cpp file" (this is a one-file, one-header program, no?), which would help prevent abuse, which can be easy. In fact, most of the "evil" features seem to be considered "evil" because they can be abused... -Albatross | ||
|
|
||
| chrisname (5896) | |
|
That macro wasn't even helpful though. A macro that saves typing by abbreviating a variable's name? What? Just rename the variable! | |
|
|
|
| computerquip (1892) | |
yeah, no point in renaming it via a macro. That's like saying: #define PVOID void* Oh wait... Haven't I seen that before? :P | |
|
Last edited on
|
|
| helios (10126) | ||
| ||
|
|
||
| computerquip (1892) | |
| Then it wouldn't be a void pointer. | |
|
|
|
| chrisname (5896) | |
| Like helios said, there didn't used to be a void pointer. They used char pointers to the same effect. When C was ANSIfied in '89, they came up with the void pointer (actually they started ANSIfying C in 1983 but that's irrelevant). | |
|
|
|
| Gene (38) | |||
|
Thanks, this is great, i'm trying to make the dungeon crawl one in console so you input a direction then it will cout 6 lines that are the game board, but when I try something like if (test == 'a') { Blah blah blah } else if (test != 'a') { Blah blah blah } it will ignore the first and go straight to the else if, even if i cin a here is my complete code, the if's have been changed 'cos I wanted to see if it would actually track my input. Thanks in advance (By the way, not to sound rude or anything but THE ROGUELIKE COMMUNITY WILL SHUN YOU for not sticking to the age-old rule of having the player as a @, no offense or anything)
| |||
|
|
|||
| firedraco (5414) | |
| You have an off by one error in there. move[1] is the second character of the string, not the first. | |
|
|
|
| Gene (38) | |
|
Thanks, just realised that this morning, thanks for the help, do you think you'd be able to use an if statement similer to for (i>=100, i++) { if (move[i] == '@') { break; } } for a good way to finish the dungeon crawl? (i'd use some string.replace after that) | |
|
Last edited on
|
|
| garmot17 (3) | ||||
[/b][/output][/code]
| ||||
|
|
||||
| garmot17 (3) | ||
| ||
|
|
||