   polymorphic containers a bad idea?
  Its a fairly common idiom to have say Renderables, with subclasses that do specific rendering like Mesh, Window, etc. Then to render you iterate over a container of Renderables and call their virtual Render function. This seems like the most common use for polymorphism in c++ anyway, because for regular function parameter polymorphism you could just use templates. Is this a misfeature? Because when iterating over a laqrge container is when you are also most likely to care aqbout the ovwerhead of virtual function calls. Has anyone tried making a "polymorphic" container that actaually internally had one container for each concrete type? Then when you wanted to loop over them you would do all of one type at a time.   
  AFAIK the overhead of virtuals isn't too much.However, if you have an array of BaseClass pointers and iterate over them all (to draw them?), all it does is fetching the pointer to the member-function, which depends on the DerivedClass type.If you were to build a system with lists for each derived class you are:a. Restricted to the derived class you added support for (defined a list for in the container...).b. You have a slight RAM overhead of all the extra listsc. You have overhead of iterating over the listsI say, test it :). Test how much it differs. From personal tests, IIRC, virtuals have barely any overhead. Correct me if I'm wrong though (also, isn't Java full of it?).   ;  I have never come across a scenario where the cost of calling a virtual function would be significant when compared to the cost of rendering an object.   ;  Nitage, I think that's true but misses the issue. If I have many Renderables, at some point the combined virtual function call cost will be equal in cost to 1 or more rendering operations, so you are certainly at some scale eventually limiting your throughput.Virtual calls are expensive *relative* to regular calls and other primitive ops. One isn't going to kill you, but I'm discussing a death by a thousand cuts scenario, which I think you're more likely to encounter when iterating over a large container. And since iterating over a container is the primary use I see in c++ for polymorphic dispatch, I wonder if virtual calls are a misfeature.   ;  As far as I'm aware the main one might want to avoid virtuals from a speed point of view is not because the function calls are a pointer dereference longer (which is basically nothing), but virtual functions cannot be inlined (because the function is called at runtime, so there is to way to inline it at compile time). This might mean that a certain amount of "magic compiler optimization" might not occur. Given how subjective the whole nature of inlining and optimization is from the average programmer's point of view, if architecturally the best thing for your application is to have polymorphic containers, then you should probably use them I would have thought.   ;  You might want to look at  this article by Sneftel.   ;  For something like rendering, the virtual function call overhead is basically completely overshadowed by the amount of work that the virtual render function does. virtual call overhead is really only a concern for very light-weight virtual functions.I wish I could recall the topic, but there was a thread not long ago where someone here had made an analysis of virtual function call overhead. IIRC, the virtual function used to provide the workload for the test was only a moderate amount of work -- it was possibly the dot product -- and if I recall the results correctly, virtual function call overhead, vs a non-inlined call, was only responsible for something like 1/5th of 1 percent of the overall run time. Compared to an inlined call (in an unrolled loop,) the virtual function overhead was still significantly less than 1 percent.As bandwidthjunkie said, the difference between a non-inlined function call and a virtual one is only a single pointer deference and, as you can imagine, CPUs have gotten pretty good at that. even compared to inlined calls, your pay-off is very small, and will likely be negated or overshadowed by the overhead of whatever method you implement to emulate polymorphism.For example, in your scenario of multiple containers for each type hiding behind a facade of a container of the base type, I don't see a way for you to know when the type being given to you by the iterator has changed from one concrete type to another (not to mention that an iterator can't magically change, anyhow) -- hence, you'll still have to call the functionality through the base class and virtual methods. The only practical way I can see around this is to just have multiple container types explicitly, and looping over each one, but then you loose out on the convenience/elegance of having just a single container.furthermore, optimal rendering is achieved through intelligent batching of like-resources to minimize state-changes. Renderable objects should be batched according to material type, rather than other arbitrary criteria.   ;Related.   ;Quote:Original post by SiCraneYou might want to look at  this article by Sneftel.That's a great article on substituting compile-time polymorphism for run-time polymorphism, however it won't do the OP much good because he appears to want a single container that contains (or at least appears to contain) all renderables -- I don't see a way to get around the need for run-time polymorphism unless he goes to explicitly separate containers.   ;  The solution isn't really that hard; have one renderable type and don't subclass it.Things which need rendering HAVE-A renderable object, this in turn would contain information with regards to what is required to render it.This basically breaks down to;- shader/materials- vertex buffer- pass informationSo, you fill your 'renderable' in some way and then compile a list of them based on the objects which are currently in the world.class Foo{//... other defs etcpublic:  Renderable * GetRenderable();private: Renderable * whatIuseToRender;}Ah, 'component based'; that's the term I was after.   