4.16.2012

Stuff!

Added a bunch of useful macros to ITK along with a generic floating point matrix stack ala OpenGL for 2D, 3D, ND as well as a new "buffer" datatype that'll be used as the sole input method for IGE's render strings. Works quite nicely, but has a certain overhead for single values. However, I'm certain that this input method will be very useful for other systems as well. It's really quite a good idea in my opinion! I mean what else would you want to have for an in-code VM that will never be fed with any language but a few commands with indices as parameters. Though I have to be honest that I don't yet know what other uses might be.

ITK is growing nicely so far. Everything I want to use in some other code that's not too specialized will find a place in ITK. Especially the vector and matrix stuff is quite varied. Though I'm once again convinced that C++ templates are better for anything type-related. However, I'm still not convinced of the whole inlining thing that's imho more important than the generalization interface. After all, function calls in inappropriate places do totally suck. Another reason to code in C and get more creative about how YOU define your algorithms and interfaces instead of complaining about it. No one said that clever C programming is not about puzzling.

Also, I'm going to implement a little OOP macro collection in C and probably add it to ITK because some things sjust don't profit from not choosing classes and virtual tables. I found myself a bit rebellious when my internship interviewer insisted on C not beeing able to do most stuff C++ can do. Well, it's true that a lot of C++ features are not possible in C, but those are rather of syntactic sugar or parser steps like namespacing. There are also some compiler-specific lowlevel optmizations that can't be done in classic C, but those only add efficiency for certain paradigms. The processing will always be the same for both, independent from what you want to do. Anyway, to prove that OOP is possible (with a certain comfort of course), I'll clean up and expand the macros I'm currently playing with and try to add as much as possible. It's won't be as smooth as a builtin syntax of course, but if you really want to utilize it along with normal C code, it's absolutely no problem. The only concern I'm having is that since it's all on a macro base, the used symbols should be as short as possible. Symbols like I, V, CP, P, VV and whatever no are perfect if you no what they are and quick to use. But they're still global, you know. Nothing that can be called clean.

No comments: