4 ms·
Good points, but for me number one would be to avoid runtime polymorphism like the plague. If your call graph has more roots than your neighbors garden and the
by weinzierl 2y ago
Good points, but for me number one would be to avoid runtime polymorphism like the plague.
If your call graph has more roots than your neighbors garden and the whole thing is a forest and not a tree you will have a hard time understanding, analyzing and ultimately debugging.
- zbentley 2y agoWhat do you mean by "runtime polymorphism" here? Vtable dispatches? Something else? I guess I'm confused by the mention of call graph roots; in my mind those are just ... entry points. Edges in the call graph might be a PITA to follow in a debugger because of indirections like vtables/optimizer inlining/etc., but isn't that separate? Or is my terminology model wrong?
- pjc50 2y agoPeople respond to the awful complexity of C++ in many ways, each trying to cut out huge sections of the language, but I think this is the first time I've seen someone argue against using virtual dispatch. Somewhere out there a Smalltalk programmer is laughing.
- gpderetta 2y agoIn the general case, I agree that runtime dispatch makes a code base harder to understand. But specifically for runtime debugging, you can get the actual stack trace, so runtime polymorphism is not much an issue. In fact a debugger can be a convenient way to understand how complex class hierarchies end up interacting.