TheoLogic

Or use auto if your compiler support this C++11 feature std::vector<Resolution*> ResolutionList; //... for(auto it(ResolutionList.begin()); it != ResultionList.end(); ++it) { /*...*/ }

It is not stupid, and clearly defined in the standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf (23.4.4.3 map element access)

There are 2 raknet plugins which may interest your: - http://www.jenkinssoftware.com/raknet/manual/directorydeltatransfer.html - http://www.jenkinssoftware.com/raknet/manual/filelisttransfer.html Never used them, so feedback if you do would be great! If you use C++ on Windows only I propose: http://www.codeproject.com/Articles/7530/Zip-Utils-clean-elegant-simple-C-Win32

I used Boost on Nintendo Nitro, iOS, OSX, Windows and Android. No problems at all!

Calling Boost ****, shame yourself! Boost developers are mostly active in the C++ ISO committee and create great libraries which eventually may end up in the standard. Best examples are the new C++11 smart pointers and hash containers. I agree with the fact that you don't want to use Boost, it's pretty cumbersome do yet it deployed, but calling it **** crosses the line.

Agreed, your animation example is a good one. I might state as: * Static: use enumerations * Dynamic: use strings for debug, used hashes in release. You can fairly implement such system that in debug you have access to the actual string value (member of your hash object), but in release it's a hashed version only.

Vector is not a linked list, an element in a vector does not know the next element... Lists are double linked lists. Indeed, maps is probably the most used container after vectors for the reasons you state. I have to agree partially with Josh's comment that you should probably use an "integer type". I suspect he means static const integers, but I would strongly suggest enumerations. Depends, it's rather a design principle. If you don't design your object to be inherited from, just make all members private, else make the members required in the subclass protected. You should never have globals (and if you have them please do add them to a namespace) and public datamembers. Really, a book to read for everyone working with C++! It's "just" 101 rules, short book, but very handy.

You should really read this book: http://www.amazon.co...s/dp/0321113586 Everything you are stating here will gently be countered in 101 rules by Herb Sutter, C++ ISO chairman, and Andrei Alexandrescu. 2 veteran C++ developers! You are burning yourself to the very things they are warning about. For example: 7. Know when and how to code for scalability. 14 10. Minimize global and shared data. 19 11. Hide information. 20 41. Make data members private, except in behaviorless aggregates (C-style structs). 72 76. Use vector by default. Otherwise, choose an appropriate container. 150 77. Use vector and string instead of arrays. 152 78. Use vector (and string::c_str) to exchange data with non-C++ APIs. 153 Really, don't take this the wrong way. I broke myself on endless nights, making the same assumptions as you make. That's just what's making C++ so hard!

Oh boy (going off topic). Iterating over vectors is faster as over a list. List is node based and vector is a contiguous blocks of memory, which the CPU loves... That's also the reason that C# containers are slower as C++ containers, in C# all (except arrays) are node based. And be honest, what do you use the most? Inserting and removing or iterating? * render all items * update all items Simple examples, this is where you need the performance! Not in that rare case where you need to add or remove for example, this could be done during loading! And even most of the time if you require adding, vector push_back is as fast as list push_back. And OK, you have a case where you have both: often iterate and often remove in the middle for example. Use move semantics! Sorry Josh, but you need to work on your C++ skills. * Using std::map (red-black binary tree) for entity management? Use objects, or at least std::unordered_map (C++11 hash map) if you really, really, really want to use an ID * Using std::list where you want std::vector * Public datamembers, just wtf. Encapsulation my friend!

Yep, indeed a C++11 feature. Finally a way to express temporaries! EDIT: Have an article on rvalue references and move semantics for the interested: http://www.benoitroosens.com/articles/rvalue-references-and-move-semantics

Why would that be? Just one example how you can handle it: for(auto it(myVector.begin()); it != myVector.end(); ) { if(must_remove_this_element) { myVector.erase(it++); } else ... } std::vector can reserve capacity, so knowing the maximum number of elements can indeed be a nice thing. However, with move semantics you are able to just move elements on resizing. STL has been modified to support this, so std::vector<std::string> for example will not copy on reallocation, but move. You can write your own move constructor and assignment operator if this is your bottleneck.

First question, do you require a linked-list, or a dynamic array? In my experience, std::vector covers 90% of the container use cases. List: http://www.cplusplus.com/reference/stl/list/ Vector: http://www.cplusplus.com/reference/stl/vector/ Next some remarks on Roland's code: for(auto it(myList.begin()); it != myList.end(); ++it) { cout << *it << endl; } 1. Use auto to define iterator types (if you have a C++11 enable compiler). Saves you time, and you can change the container type as you like and don't break your code. 2. Use '++'-like prefix, especially for iterators. http://thunderguy.com/semicolon/2002/08/13/prefer-prefix-operators-over-postfix/

I tried but the link pointed to my blog entry... Strange, I may have made a mistake: http://www.codersource.net/c/c-miscellaneous/c-virtual-destructors.aspx @Roland: I don't say that you are wrong, making all destructors virtual is just not the right solution. Your base destructor should ALWAYS be virtual, just like you stated. It is a good practise to also make your derived destructor virtual to state that you inherit from a base. If you don't want that your class is inherited from, you shouldn't do that however... Maybe to remove the confusion, it's the same idea as: class Base { public: virtual ~Base(); virtual void Foo(); }; class Derived { virtual ~Derived(); virtual void Foo(); }; In Derived, you don't need the virtual keywords. But it shows that you overwrite a base implementation of Foo for example.

Sorry, but that's what you say to school developers in the first year C++ . There is a huge performance impact as from you have 1 virtual function. It should actually be the other way around, If you inherit or want you class to be inherited from, make your destructor virtual... A() { _pmem = new char[1024]; } A() : _pmem(new char[1024]) { } //No default initialization. Modern compilers should optimize this...

Const functions do not exist in Java, I won't blame your uni teachers . Regarding the variable initialization, you should do this: struct CollisionHitResponse { CollisionHitResponse() : NumEntitie****(0), EntityHit(nullptr), CollisionPoint(nullptr) { } unsigned int NumEntitie****; Entity * EntityHit; //unsigned int NumCollisionPoints; //A collision point is only saved if the entity the ray collided with is also saved, so these "count" variables will be the same, making one redundant - in this case, I chose this one. TVec3 * CollisionPoint; }; You may not rely on the "fact" that another method "may" initialize the variables for you! Also a best practise, if I write "auto blah = new Whatever();" I expect that an initialized object. I often see creation followed by an initialization method, which is just plain evil because you can forget it. I create something that I want to use, so please create it completely. Did you read the article? As you can see you must use virtual destructors or else the base object won't be destructed! So if you have inheritance, 2 things to do: 1) Check if the base has a virtual destructor, if not the object is probably not ment to inherit from (eg. std::string, std::vector, ...) 2) Set your own destructor virtual. This defines that your class may be inherited from or/and that you inherit from another class. Why pass it as const reference is actually pretty simple. std::string allocates dynamic memory behind the screens, and if you pass it by copy you will get an extra memory allocation. There are 3 possible options. void Foo(const std::string& bar) //You will only use bar, no changes allowed. This doesn't create a copy, but a reference to the same object! Performance is good. void Foo(std::string& bar) //You will change bar, this is the original value that you pass to the function, be careful!!!!!!!!! std::string blah("whatever"); Foo(blah); //OK Foo("whatever"); //ERROR! You may not bind a temporary to a modifiable lvalue reference (ISO standard). But please note that Visual C++ allows this, also known as the evil extension... void Foo(std::string blah) //Copy of original string passed to function, ideal if you will perform temporary changes on the string in your function. No problems with sharing, this is the reason why I also like to share code, you learn a lot from other people! My remark to lifetime if probably because I coded for Nintendo DSi in the past. You really need all memory you can get, and having global instances is just not the way to do it. What we did were Singletons which we destroyed if unneeded: MyObject::DestroyInstance(); ftw!