The rest of the data structures in the STL follow the same (anti-)pattern.

They all either take ownership of your data, or point at your data unidirectionally.

This means that given a pointer to your data you cannot, for example, delete it from multiple data structures it is contained within without going from these structures roots to re-find the pointers to your data.

Whereas with intrusive data structures (the way it is done in the Linux kernel and other "advanced" C projects), you can easily embed your structure in multiple data structures, such that you can do very quick deletion or modification of the data without re-finding it.

How about: Any C or C++ programmer knows not to use linked lists anyway.

In C, you can use a bit of macro trickery to get the same safety, e.g: by defining a 0-sized array of the some type alongside the intrusive node. Then, macros that do the "cast down" from the intrusive node to the container element can also do a type-comparison (using some trickery) between the anchor's array and the container type.

I've seen it implemented, but everyone uses the typical non-type-safe one anyway :)

I don't think I've ever had such bugs in a lot of code though, since I tend to wrap the "containerof" call with a little function like: foo_of_lru_entry and foo_of_hash_entry. A bit of boilerplate for each data structure, but worth it.

You might find http://www.locklessinc.com/articles/dlist/ interesting: it describes a (perhaps excessively) clever way to do intrusive lists that gives type checking.

(Unfortunately it does rely on `typeof`, an extension.)

I found a stack overflow question that seems to go over it. Basically it looks like there's almost always a better choice for whatever you're doing.

http://stackoverflow.com/questions/18449038/is-there-ever-a-...