EPTThe Big Programming Thread - Page 627
| Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
|
Propelled
Denmark184 Posts
| ||
|
Nesserev
Belgium2760 Posts
| ||
|
Blisse
Canada3710 Posts
What are you documenting that takes so long? | ||
|
Nausea
Sweden807 Posts
I just thought I might ask here what container i may want to use for the jewels, since I guess I will have to remove and move and add stuff very often. | ||
|
Blisse
Canada3710 Posts
| ||
|
meatpudding
Australia520 Posts
On May 03 2015 11:25 Nausea wrote: I'm a noob and thinking of trying to put together a bejeweled game to learn from. (In c++) I just thought I might ask here what container i may want to use for the jewels, since I guess I will have to remove and move and add stuff very often. I don't know the game, but.... An array, or if you like a std::vector. Both can be set up with the size that you need, in this case the size never changes. If you have a blank spot, just fill it with a blank element. You can access both types of containers in constant time. The trick is whether you decide to use 2d co-ordinates or 1d. Even though 2d would seem natural, 1d works just as well or better. For example:
| ||
|
Nesserev
Belgium2760 Posts
| ||
|
Millitron
United States2611 Posts
On May 03 2015 12:08 Nesserev wrote: I think most people tend to go for a 2-dimensional std::vector/array, or perhaps even a map with pairs as keys. Personally, after having dealt with 'quadrants'(?) far too many times, I think the best option (clean, flexible, most optimal) would be writing your own class that provides all your needs, around a one dimensional std::vector< ... >. It makes iterating rows/columns very easy and clean, and you can just use pointer/iterator arithmetics. Note that the only case that it's not very good at, is expanding the quadrant in both dimensions. (EDIT: Then you should prefer a 2D vector.) I never skip the inline comments, which help a lot during the coding process itself, or organizing/chaptering the code, but when I just want to continue coding, I postpone writing the class and method descriptions, code examples, etc. until later. I guess I might be a little bit guilty of excessive documentation. It's not like I document the most menial of details, but I tend to write documentation for the user of the classes, and developer/maintenance separately; and when I do, I pretend that the other person is a 5 year old. I don't think that it's a lot of documentation, it's just that I tend to get annoyed with it really fast. If only documentation was as fun as coding, or well... you could say it's part of coding, just the boring part :S There's nothing wrong with assuming the next dev is a 5 year old. While getting my CS degree, I came in on so many already-in-progress projects written mostly be people who documented next to nothing. I was somewhat traumatized after spending the better part of a week trying to understand how the UI to our department's robot was implemented. It was seriously a clusterfuck; it had two sentences of documentation, for about 10 pages of code. And was written using a version of XWindows that was obsolete over a decade before, meaning even finding documentation for that was difficult. By the time I understood it, and made the change I wanted to, we had managed to install Java on the robot and the whole project was made pointless. They made a better version of the UI in Java in one afternoon. So long story short, fuck XWindows and fuck people who don't document. Please continue assuming the next dev is 5. I'd rather have too much documentation than too little. | ||
|
Craton
United States17303 Posts
Yeah there are bad companies out there, but people in school are consistently bad because most haven't had exposure to why it's important and what's needed for it to be it's useful. At that point, most devs have rarely, if ever, worked on code involving more than themselves. Those that have usually just had a few disparate parts with minimal or no overlap. You don't need to treat the dev as an idiot, you just need to be clear and descriptive. Write documentation with the thought in mind that you're the one reading it with only a vague idea of what's going on. In practice, there's a pretty good chance a year down the road you will be the one reading it again trying to figure out what's going on. | ||
|
spinesheath
Germany8679 Posts
On May 03 2015 12:08 Nesserev wrote: I never skip the inline comments, which help a lot during the coding process itself, or organizing/chaptering the code, but when I just want to continue coding, I postpone writing the class and method descriptions, code examples, etc. until later. I guess I might be a little bit guilty of excessive documentation. It's not like I document the most menial of details, but I tend to write documentation for the user of the classes, and developer/maintenance separately; and when I do, I pretend that the other person is a 5 year old. I don't think that it's a lot of documentation, it's just that I tend to get annoyed with it really fast. If only documentation was as fun as coding, or well... you could say it's part of coding, just the boring part :S I try to avoid all inline comments and turn parts that need explanation into separate methods instead. Most of the time that results in many methods that are short, simple and have a descriptive name, so commenting those is kinda redundant, but that also makes it simple to comment. | ||
|
BByte
Finland49 Posts
On May 03 2015 15:21 spinesheath wrote: I try to avoid all inline comments and turn parts that need explanation into separate methods instead. Most of the time that results in many methods that are short, simple and have a descriptive name, so commenting those is kinda redundant, but that also makes it simple to comment. I agree with this, breaking methods up often makes for better code anyway and easier documentation is a nice bonus. I also leave redundant comments out. When reading object oriented code I typically find class level comments much more useful than the method comments. The name should be enough to tell what a method does, and reading the code is usually the best way to figure out the how. With classes the exact purpose is not always clear from the name and unlike good method naming conventions, class naming conventions seem to vary a lot. It's also a lot more work to find out how a class works just by reading the code compared to a method. In functional code I feel like I need to use even inline comments. I don't see it as a big problem though, the code is often succinct enough that I can spend a few characters and add a line comment.  | ||
|
ZenithM
France15952 Posts
On May 03 2015 12:03 meatpudding wrote: I don't know the game, but.... An array, or if you like a std::vector. Both can be set up with the size that you need, in this case the size never changes. If you have a blank spot, just fill it with a blank element. You can access both types of containers in constant time. The trick is whether you decide to use 2d co-ordinates or 1d. Even though 2d would seem natural, 1d works just as well or better. For example:
Huh, why is it better with 1d? With simple arrays, it's faster to follow 2 pointers rather than compute 1 multiplication and follow a pointer. The 2d array is obviously clearer, AND it's faster. I don't know why you would use a 1d array. C++ is not Java, with reference and boundary checking overheads everywhere :D | ||
|
netherh
United Kingdom333 Posts
On May 03 2015 19:19 ZenithM wrote: Huh, why is it better with 1d? With simple arrays, it's faster to follow 2 pointers rather than compute 1 multiplication and follow a pointer. The 2d array is obviously clearer, AND it's faster. I don't know why you would use a 1d array. C++ is not Java, with reference and boundary checking overheads everywhere :D I'd be pretty surprised if the 2d array was faster. And the 1d array is more flexible as you can iterate the whole thing in one loop. It's also much easier to resize, and much less wasteful of memory. EDIT: Read the answer to this question: http://stackoverflow.com/questions/17259877/1d-or-2d-array-whats-faster Given that you should want to wrap the thing in a class with a proper interface anyway, there's absolutely no difference in clearness outside the class itself. (And I think it's actually clearer anyway. You just have a GetIndex(x, y) function... all the other different code is shorter and clearer with a 1d array.) | ||
|
ZenithM
France15952 Posts
First, static 2D arrays are contiguous in memory, they're not more wasteful, it's actually the same exact amount. I don't think a Bejewel board needs to be resized in-game, so that point is pretty much moot. And plus, even in the case of dynamic arrays, as per the guy's tests, 2D arrays ARE faster at random access (even if just slightly so). But you're also right that you'll probably want to wrap whatever implementation you end up using in something clean and generic. To be perfectly clear, it's natural to think that the 1D array-like structures would be faster, but it's really not that obvious that it is. It depends on what actual structure you use, on whether you use static or dynamic arrays, on whether there are boundary checking going on at runtime (like on a JVM), on the amount of optimizations you enable in your compiler and all that. One advantage of 1D structures is that it's much easier to parallelize too. | ||
|
Zocat
Germany2229 Posts
I have a Cmake file which (should) generates a Visual Studio project file. Is it possible (if yes, how?) to add a post build event to the generated VS project through the Cmake? I have found add_custom_command, but I'm not sure if it is what I want (or if it just adds a cmake post build option). + Show Spoiler [The stuff I currently have] +
sourceDir and targetDir are of course other values. The error I receive is: "(stuff about policies) The target name "DICOM" is unknown in this context." | ||
|
Shield
Bulgaria4824 Posts
On May 03 2015 12:03 meatpudding wrote: I don't know the game, but.... An array, or if you like a std::vector. Both can be set up with the size that you need, in this case the size never changes. If you have a blank spot, just fill it with a blank element. You can access both types of containers in constant time. The trick is whether you decide to use 2d co-ordinates or 1d. Even though 2d would seem natural, 1d works just as well or better. For example:
Do you expect height * width to be huge to use 'new'? If yes, I still think it's a bad example and that bit should be moved to a RAII class.Edit: Or use a smart pointer. | ||
|
Mstring
Australia510 Posts
Keep it simple. | ||
|
sabas123
Netherlands3122 Posts
| ||
|
Blisse
Canada3710 Posts
| ||
|
Artesimo
Germany603 Posts
Also, when it is practical to group the list elements in some sort (like a dictionary with A,B...), should I create a list for each group, or should I rather use one big list, and have pointer to certain elements stored elsewehere, that simly point to certain locations(like "words with C start here"->)? If I want to use one big list, it seem like having a class that holds this information is best. | ||
| ||
