ernstsson

Great idea, done!

Sure, zoom in and out with the + and - buttons, resize the browser window to resize the viewer size. That is, when following the links to analysis.ernstsson.net, the images on ernstsson.net are just examples.

Well written! I think that potentially hideous code, putting together groups of injected code is one of the hardest type of component get right. My background is in embedded and mobile so I usually expect a stupid OS or perhaps not even an OS at all (or perhaps writing part of the OS). Artificial restrictions is just silly tough.

Well, not reinventing to be honest, rather redocumenting. There's a lot of cavemen behavior that still needs to be taught to "cave-kids". You're correct, an experienced C programmer should know this, but I do expect more to join the ranks. Good list of rules! Well, actually good to keep in mind even with the original tangled design but when resolving the tangle it actually clarifies the responsibility of this even further (the documentation, making sure there's a void* etc etc).

As previously mentioned in one of the other comments; to "facilitate run-time configuration and testing.". Removing the static coupling has a value in itself, making the component isolated to facilitate unit-testing.

Yes the example used to explain dependency inversion indeed happens to be an observer pattern. Well known yes, at least amongst experienced C programmers, but as mentioned in a comment on the page; "all the more reason that it should be explained in blog posts.".

Yes, I agree, it's about facilitating run-time configuration and testing. Not sure I agree with the increasing of code complexity though. Maybe there's an aspect of code complexity that increases with dependency injection. I personally feel that code complexity more correlates with explicit branches, something that I usually eliminate using DI or polymorphism. And yeah, any way of writing code has it's downsides and upsides, just a matter of finding balance.

So as a summary to the comments above; Function pointers between files isn't bad for performance if we can't do link time optimization. When link time optimization really becomes widely available, it's still not bad? Just the step in the middle that could be affected then? Thinking out loud here, any thoughts on this? I usually opt for structure over performance before profiling proves otherwise, but I still find this to be an interesting topic.

Good old callback, exactly what it is! In a very simple case like this perhaps the additional state is complicating things, it does have it's uses is many cases though, as described in the post. I personally think function pointers doesn't make code more difficult to debug than any dependency injection used in many of the higher level programming languages as Java. It is usually the main argument against dependency injection as well. Usually it goes; Since it makes it harder to debug I'd rather make it more coupled. When it's more coupled it's harder to unit test. Since it's harder to unit test, I need to debug more, etc etc. Personally I'd rather break that chain early. In the end, debugging code with function pointers (or dependency injection) gets easier with time.

Normally compilers does not do optimization of function calls between files anyway, so in this specific case that wouldn't matter. Within the same file it would've been different of course, bringing us to the second point; Yes, in this simplified example it's really very silly to have two files at all. The code itself isn't bad, just badly abstracted. The best refactoring for this limited problem would of course be to combine the files, but then the description of how to invert dependencies would've been lost. The cost of having examples easy to grasp in a short blog post I guess.

Yes, definitely. I think (or hope?) the main reason for the score is that the directory structure and the actual architecture of Linux isn't fully in sync. Most of the score comes from the top directory tangles and complexity. When I compare it to the commonly used kernel map (http://makelinux.homelinux.com/kernel_map/LKM3_512.png) I really don't see it matching as well as Arqua requires for a good score. Note also that the score doesn't say that the software doesn't work, just that the structure of the source in relation to the call graph of the functions is complex.

True, Coverity needs to be configured correctly for the target system to get it working for you (I assume that especially Symbian C++ can be tricky). Similar here, the tolerance values for complexity might be set wrong giving us a lower score than we should have. The image itself is valid though.

Thanks for the comment, added the link in the post as well.