   What is this concept called?
  Good evening, Gamedev!    [C++] I have discovered an algorithm that will help me progress in my game development.  I'm sure someone else has thought of this concept, unfortunately I don't know what this concept is called or how to search for it.     The concept:  Any class (game object, specifically) derived from the template<class type> CCollection<type>::Entry class will, on construction, insert a pointer of itself into a static list, std::list<type*> CCollection<type>::m_list, and on destruction or expiration, remove itself from its respective list.  With this, I can iterate through a list of type objects more quickly than searching through the main game object list and comparing the types of each entity/object.    If anyone knows what this concept is called, please enlighten me, so I can do more research! (And rename the respective classes to something with a little less fail.)Thanks,_fastcall :)   
  Unless I'm not understanding you, it sounds like "sorting objects by type" but automatically in C++ using templates and constructors.And what does the C stand for in "CCollection"?   ;  It's called "a bad idea". Aside from static initialization order problems, this means that it is utterly impossible to create an object without it becoming part of the world, or to remove an object from the world without deleting it outright. Believe me, this is important functionality. If you want to make your object list efficiently searchable by type, there are much better ways of doing that.   ;  Thanks for the replies!Quote:Original post by BoderUnless I'm not understanding you, it sounds like "sorting objects by type" but automatically in C++ using templates and constructors.And what does the C stand for in "CCollection"?Yes, in a way I'm "sorting objects by type."  Using std::list<type*>, the list won't delete the objects.  The purpose of the CCollection is only for iterating through same-type objects.(The "C" stands for "class")Quote:Original post by Sneftel... it is utterly impossible to create an object without it becoming part of the world, or to remove an object from the world without deleting it outright.In my point of view, I don't see any use for creating a game object that isn't part of the world. Quote:Original post by Sneftel... there are much better ways of doing that.Such as std::map<CObjBase::enum_type, std::list<CObjBase*> >?  I'm not sure I understand...[Edited by - _fastcall on March 19, 2008 12:12:51 AM];Quote:Original post by _fastcallYes, in a way I'm "sorting objects by type."  Using std::list<type*>, the list won't delete the objects.  The purpose of the CCollection is only for iterating through same-type objects.Obvious question 1: when do you need to iterate through all objects of a given type? I personally find the need to iterate through all objects in a container, but I seldom have to iterate through all objects of a given type within that container (this is what separate containers and/or virtual functions are for), and I even more rarely have to iterate through all objects (because most of my objects can exist as temporaries, or similar non-globally-relevant entities).Obvious question 2: why use a list instead of a vector?Quote:(The "C" stands for "class")Well, it seems quite obvious that a type called Collection is necessarily a class type. Or are you trying to indicate that Collection is a type? What example can you find where it is not obvious that Collection is a type, yet it is an interesting thing to know?Quote:In my point of view, I don't see any use for creating a game object that isn't part of the world.If that is the case, then you cannot have;A temporary instance of a game object used as part of the loading or saving process.An original instance outside the world used to create other instances through cloning.A snapshot of the world at an earlier point in time, used to represent a checkpoint.An object temporarily removed from the world, such as a weapon in the player's backpack.Any algorithm which consists in "insert object X into the world" now becomes "create and insert object X into the world", forcing you to write more code.Any algorithm which consists in "remove object X from the world" now becomes "save the data of object X and remove it from the world".Quote:Such as std::map<CObjBase::enum_type, std::list<CObjBase*> >?  I'm not sure I understand...First, try to understand why you care about all objects of a given type, and realize that you actually care about all objects of a given type created within a specific context (namely, the game world). Then, alter that context so that it registers the same-type objects it creates in an ad hoc list, without forcing other instances of that type to be placed in that list.;Quote:Original post by _fastcallQuote:Original post by Sneftel... it is utterly impossible to create an object without it becoming part of the world, or to remove an object from the world without deleting it outright.In my point of view, I don't see any use for creating a game object that isn't part of the world.I know. But please trust my experience as a software designer: you will find one. And when you do, your proposed architecture will be so entrenched that your only recourse will be a "m_inWorld" member, and rewriting masses of code to make sure that objects which aren't in the world aren't accidentally affected by events in the world. And you will miss some, and the result will be frustrating bugs which are difficult to reproduce, find, or fix.   ;Quote:First, try to understand why you care about all objects of a given type, and realize that you actually care about all objects of a given type created within a specific context (namely, the game world). Then, alter that context so that it registers the same-type objects it creates in an ad hoc list, without forcing other instances of that type to be placed in that list.Alright! Thanks for the help!;  For reference, the Ruby language has something like that built-in; they call it ObjectSpace. Some guys seem to dislike it, some find it useful. I agree that it's probably a fun thing to have during debugging and exploration, but there are too many special cases and unintended consequences for this to be something you really depend on.   