I've been thinking about my progress in own programming stuff since I'm working around 8h per day of which I can use 8h to sleep and 3h to go to/come from work, leaving 3h for freetime and 3h travel time. That's not much if you want to put a lot of time into clever macro constructs and planning in general. In fact, programming with macros requires more care thinking about what to evaluate before you can pass it as an argument, so I have to think about how use it then, too.
It's a bit depressing because I don't make any progress and those day where felt just too pissed to code cause of anything else in the world makes it impossible to advance any further. Thus, I've been thinking about a different approach I dropped before: inline functions. Inline functions are not guaranteed to be inline, but I learned so much about not using hardcoded types and avoiding memory copying so that I think that it's totally possible to use them without any symbol or type passed using macros. I also believe that I should study GCC's inline condition further to know what makes it easy for GCC to optimize. There are still things like vector macros that can't be changed much, but that's totally ok. I just don't want to think about everything because starting to code.
Anyway, I became quite good at seperating actual type-independent logic from code that's always the same. I believe GCC has a very simply philosophy about inlining. For example, calling malloc in function won't inline it (my experience of course) as well as using their reference anywhere. Also, I've seen const types beeing an optimization criteria for which GCC will create unique function versions. Since I'm already prefixing macros with i_ for input, o_ for output, io_ for both and t for temporary variables, I'll rely on const beeing the input type and t can be dropped. I wonder under which circumstances GCC can optimize out function pointers. I mean if you pass const function pointers everywhere and if you're still inside the same module, it should be possible that GCC's can detect this. Though I bet that you'll have to use static functions then. Hmmm, that's difficult to say without reading about it. And that's time-consuming, too. Well, ok, just look up the internet and browse a bit but I got only 3h with internet that's inside my working hours. I don't want to do this while working, too much distraction.
On a sidenote, today I realized how well-defined a simple function call structure is. See, if you have a really huge C++ project with lots of classes, objects interfaces and whatever else combined with multiple libraries giving overridable interfaces to you, the number of possible errors manyfold due the underlying virtual table system. And that's not just some purists pointless rant - callback-based system are similar to this as you'll not always be able to properly trace stuff back to where it happened, why it happened and especially what happened before. I always try to minimize any kind of this problem giving only the minimum amount of needed callback stuff. I strongly believe that all programming tasks can be solved properly without any of this. The number of errors that can not only happen cause you don't know whether a library does checking of false data but also cause you don't really know how it'll be changed in the process - especially true for commercial libraries.
Well, once again it seems that I'm not interested in solving errors that shouldn't happen in any way but rather try to express what I'd do to not let it happen. One can of course see this as impractical, but who is it struggling with spaghetti OOP and too scattered bug indices? Well, I certainly don't since I have very program flow guidelines for only I am responsible. Oh my, I'm sounding sorta snobby right now.