Haven't seen, but thanks. Lived and worked while following some of the ideas mentioned. E.g. at the whole bottom of the page in some comment is a link to: "Wh

Haven't seen, but thanks. Lived and worked while following some of the ideas mentioned. E.g. at the whole bottom of the page in some comment is a link to: "Why should I have written ZeroMQ in C, not C++ (part II)" https://250bpm.com/blog:8/ https://250bpm.com/blog:8/ where the author writes "Let's compare how a C++ programmer would implement a list of objects..." and then "The real reason why any C++ programmer won't design the list in the C way is that the design breaks the encapsulation principle" etc. I have indeed more than once used intrusive data structures in non-trivial C++ code, and the result was easy to read, and very efficient. There I really didn't care about some "thou shalt not" "breaking the encapsulation principle" because whoever thinks at that level of "verbot" 100% of times is just wrong. The "encapsulation principle" is an OK principle for some levels of abstraction, but nobody says that one has to hold to it religiously (exactly my point before). I would of course always make an API which would hide what's behind it. But where I implement something ("the guts" of something), I of course have my freedom to use intrusive elements, if that solves the problem better. I have even created some "extremely intrusive" stuff (with a variable number of intrusive links in the structures). It worked perfectly. Insisting on doing anything as "ritual" all the time is just so, so wrong.