• Content count

  • Joined

  • Last visited

Community Reputation

819 Good

About petewood

  • Rank
  1. std::map Question

    Quote:Original post by bubu LV I usually do this with #define macro: #define foundInMap(Map, Key) ((Map).find(Key)!=(Map).end()) How about... ? template<typename Map, typename Key> bool MapContainsKey(const Map& a_map, const Key& a_key) { return a_map.find(a_key) != a_map.end(); }
  2. [C++] dependency tree library?

    Also see Generalizing Observer by Herb Sutter
  3. Put in two lines before the loops assert(m_pTileMap.size() == m_TileMapWidth); for (int i = 0; i < m_TileMapHeight; i++ ) { for (int j = 0; j < m_TileMapWidth; j++ ) { assert(m_pTileMap[j].size() == m_TileMapHeight); fin >> m_pTileMap[j][i]; } } In debug these will tell you if the assertions aren't true. They may indicate to you that i and j should be the other way around. If not, remove them again.
  4. look into pooling memory clicky
  5. See the Apache Portable Runtime. Here are some of their aims: Quote: The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations. The primary goal is to provide an API to which software developers may code and be assured of predictable if not identical behaviour regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features.
  6. Pointer declarations ...

    This gets asked a lot. See Bjarne's FAQ: Quote:Is `int* p;` right or is `int *p;` right? Both are "right" in the sense that both are valid C and C++ and both have exactly the same meaning. As far as the language definitions and the compilers are concerned we could just as well say `int*p;` or `int * p;` The choice between `int* p;` and `int *p;` is not about right and wrong, but about style and emphasis. C emphasized expressions; declarations were often considered little more than a necessary evil. C++, on the other hand, has a heavy emphasis on types. A ``typical C programmer`` writes `int *p;` and explains it ``*p is what is the int`` emphasizing syntax, and may point to the C (and C++) declaration grammar to argue for the correctness of the style. Indeed, the * binds to the name p in the grammar. A ``typical C++ programmer`` writes `int* p;` and explains it ``p is a pointer to an int`` emphasizing type. Indeed the type of p is int*. I clearly prefer that emphasis and see it as important for using the more advanced parts of C++ well. The critical confusion comes (only) when people try to declare several pointers with a single declaration: int* p, p1; // probable error: p1 is not an int* Placing the * closer to the name does not make this kind of error significantly less likely. int *p, p1; // probable error? Declaring one name per declaration minimizes the problem - in particular when we initialize the variables. People are far less likely to write: int* p = &i; int p1 = p; // error: int initialized by int* And if they do, the compiler will complain.
  7. STL again!

    Quote:Original post by Agony A possible alternative would be a deque. It's very similar, has random access, but can handle inserting at the beginning just as well as at the end, I believe. Remember though that the data is not contiguous and cannot be used where a function expects a C style array.
  9. Odd casting error

    Quote:Original post by Tera_Dragon How can I change the project settings to use ANSI with MSVS2005 beta? Make sure _UNICODE isn't defined. It's better to use _T() though as it'll work whether _UNICODE is defined or not. See this link for more info.
  10. you could overload it to mean something
  11. forward declarations

    Unfortunately you shouldn't forward declare things from within the standard library. You'll have to #include <vector>. I find it best to put all library headers such as the standard library, boost, etc, into a precompiled header. It makes things much faster to compile. In related news, iostream is quite a heavy-weight header and the standard committee decided to include a forwarding header, iosfwd which is relatively lightweight.
  12. Have you thought about writing the whole game in Python? If you're worried about speed check out Psyco (for Python). It's cool. It profiles your program while it's running, works out what needs optimising and does it if possible.
  13. I don't like the background. It distracts me. I turned it off and the page looked sooo much better to my mind. Post a small amount whenever you can. The initial glow of excitement of having a blog can quickly lead to feeling you need to post something worthwhile every time and eventually to not posting at all. If a jobs worth doing, it's worth doing badly. If you've got writers block write about what it's like to be blocked and what you're afraid of. All the best. Pete
  14. STL reference book Suggestions

    Quote:Original post by AzCoder Josuttis See whether you can get a second hand copy if you're on a tight budget.... although there might not be many people wanting to sell.