5.09.2011

Much better Iterators

Since I fleshed out the details of a better iterator system and even had a moment where it proved it flexibility, technically. Normally, one would either use iterators with a fixed and limited function base or pointers aka direct addresses on the items and then calculating or reading the next adress. Both concepts are pretty fixed and iterator have a more runtime-generic approach that can, with careful design decisions, also be done statically. Used statically and properly inlined they provide equal performance - one thing to keep in mind I think. However, iterator are a tad too generic, as they only have very, very basic functionality. For example, how do iterators link/unlink elements in a doubly linked list? No way you can get that properly done with a fixed set of commands that has also has to work with arrays or non-linked lists. So I put the concept a little further by defining an army of interfaces. These interfaces have a only one or two methods in and mark significant features of the underlying "storage class" (means the way of storing elements) and per-element navigation/operation. I read about so many different posible ways of storing data elements, only a small subset of them is able to work standard method sets like push/pop/next etc. So if your alghorithm needs a storage class or iterator, you only need to make it generic, use the type T and extend it with all the interfaces/methods you want to have. It comes at a cost, though. The most annoying disadvantage is that you need to specifiy each used method on your own (can be simplified by creating dummy interfaces including all other required interfaces). Since it only bases on interfaces and generics, I think it's quite static except when I use polymorphic generics. However, I believe in this concept and see great use for it in all upcoming I may write later. Though it's currently only done (haha, done...) in Java, it's probably quite easy to port it to C++. Guess I hit the nail this time! And implementing it in Java first makes me a bit more comftable with it. I must admit I'm quite conservative when it comes to choices of programming languages. I prefer having both lowlevel and highlevel functionality - only if they are well-designed, though. In this case I prefer lowlevel functionality and mixing my own mojo.

I'm looking forwared seeing this concept in action and designing my renderer with it. Something says me that, on my own, I'm always "inventing" everything again. No matter the complexity. Well, someone has to do it. What would be the world without people like me? A bunch of people without any idea of actually trying to improve existing concepts.

No comments: