#define container_of(ptr, type, member) ((type *)((char *)(ptr) - offsetof(type, member)))

IMHO getting away from the memory layout and working with abstractions is a benefit I am happily paying, if there is any. The mixin solution leads to a similar memory layout, though, and is more OO-style (with all OO-benefits), once one adds member functions instead of plain member variables to the mixin.

And the conception "low level == efficient" is not necessarily true, as Stroustrup points out in his presentation (google for Day 1 Keynote - Bjarne Stroustrup: C++11 Style) when comparing std::sort with qsort. Both implement a quicksort, but std::sort has more information for optimization because it knows the types and can inline function calls. I would only resort to low-level optimizations when profiling has shown that it is a hotspot and measure afterwards.

"if you exercise full control over memory layout it leads to violations of OO paradigm."

I would generalize this to "if you exercise full control over memory layout it leads to violations of many established design principles of any design methodology" because basing your design on implementations instead of abstractions is never a good idea, being it OO or not.

The above is exactly the point of the article. The OO in a certian way isolates the developer from actual memory layout and thus can lead to sub-optimal solutions. Other way round, if you exercise full control over memory layout it leads to violations of OO paradigm.

"Where do you enclose members into a critical section?"

I've added an example into the article.

node <node < node <person> > >

While theoretically possible, I am not sure how well would the implementation deal with multiple overloaded prev's and next's. Also, the declaration is extremely ugly and non-intuitive.

All in all, using a simple non-OO hack instead and compex and confusing OO implementation should be preferable.

Remember that OO is here to make things easier for you. So keep your mind open — if, in some particular case, OO doesn't deliver the ease-of-use and simplicity, just ignore it and use some other solution.

PS: If you program in C++, you should use the C++-casts instead of the plain C casts.

By the way, I don't understand "That, however, doesn't fit well (at least mine) mental concept of objects. For example, I want the object to be "atomic" in the sense that if I enclose all of its members into a critical section, I won't get any data races and undefined behavior." What does it mean? Where do you enclose members into a critical section?

 #define get_containing_class(ptr, type, member) \ ((type*) (((char*) ptr) - ((size_t) &(((type*) 0)->member)))) 

Usage:

 person *p = get_containing_class (nodeptr, person, list1); 

 /* Takes a pointer to a member variable and computes pointer to the structure that contains it. 'type' is type of the structure, not the member. */ #define get_containing_class(ptr, type, member) \ ((type*) (((char*) ptr) - ((size_t) &(((type*) 0)->member)))) 

The problem with doing this automatically is that offset of person* and list::node* varies. For example, imagine the person object can be contained in 3 different lists:

 class person { list::node item1; list::node item2; list::node item3; }; 

You have to convert the list::node* like this:

 auto *p = get_containing_class (nodeptr, person, list1); 

The cast from list::node* to person* depends on which of the three lists the list::node* you are trying to cast belongs to.

You can definitely devise some clever helpers based on templates and possibly involving pointers to members (->*). This is left as an exercise for the reader :)

 class list { public: class node { friend class ::list; private: class node *prev; class node *next; }; void push_back (node *item) { mtx.lock (); item->next = 0; item->prev = last; last = item; mtx.unlock (); } private: mutex mtx; node *first; node *last; }; 

Note that data both in list and list::node are protected by the mutex.

Now, imagine the you want to mess with prev or next fields from outside of the list class:

 class person { public: list::node item; private: int age; int weight; void be_evil () { item.prev = 0; } }; 

Obviosuly, this kind of thing would lead to race conditions and undefined behaviour. Luckily, the enclave pattern ensures that the code above won't compile:

 error: ‘list::node* list::node::prev’ is private 

 class list { public: class node { friend class ::list; private: class node *prev; class node *next; }; void push_back (node *item) { item->next = 0; item->prev = last; last = item; } private: node *first; node *last; }; 

And here's the usage:

 class person { public: list::node item; private: int age; int weight; }; int main () { list l; person p; l.push_back (&p.item); } 

Looking at the wikipedia article about mixins, it seems that mixins are bundles of functionality that you can add to your class.

However, in the example in the article there's no functionality involved. Making C a member of B has zero impact on the functionality of B. It adds no functionality that can be used from within B and no additional functionality for the owners of objects of class B.

What really happens is that memory for couple of member variables of unrelated class A is allocated with instance of B instead of with instance of A.

The 'enclave' pattern redefines how boundaries of objects are perceived. In plain C++ class is just a glorified struct. It's a continuous piece of memory with some functions attached.

That, however, doesn't fit well (at least mine) mental concept of objects. For example, I want the object to be "atomic" in the sense that if I enclose all of its members into a critical section, I won't get any data races and undefined behavior.

So, in the last example in the article. 'list' class contains members 'prev', 'next', 'first' and 'last'. The latter two are standard members, both in terms of visibility and memory location. The former two have the same visibility as normal members, however, memory-wise they happen to be located elsewhere (alongside the instances of class 'person').

I am not sure whether this kind of thing quialifies as a mixin. Wikipedia doesn't seem to suggest so.

my main point was that the solution you propose is another way to implement a mixin (or a trait), so I don't think it is a new pattern.

1. I don't see a difference here to your solution. With template mixin, I need one mixin class for every list, while your solution needs a new helper class for every list. Both don't scale well, but the mixin have the advantage that I don't have to modify the person class every time. This is nice when it comes to testability and single responsibility.

For both solutions, you need a different list type for every list the object will be contained in.

2. Same solution as in your proposal: Make the members private and declare the list as friend of the mixin:

class Personlist;

template <class contents, typename List> class node: public contents
{
friend List;

node<contents, List> *prev;
node<contents, List> *next;
};

class person
{
int age;
int weight;
};

typedef node<person, Personlist> person_node;

class Personlist
{
public:
void add(node<person, Personlist>& n)
{
n.prev = &last;
n.next = nullptr;
last.next = &n;
last = n;
}

private:
node<person, Personlist> first;
node<person, Personlist> last;
};

1. How to embed the object into multiple lists?
2. How to ensure that prev & next members are accessible only by list class and not by anyone holding pointer to the object.

Nested class is used in the example, but it's used only to make it nicer. Everything would work in the same way even in C was declared as a top-level class.

Closures deal with storing a snapshot of the environment, they don't seem to have much in common with the topic discussed here.

Take a look then on nested class and closure.

According to wikipedia: "The intent of the Builder design pattern is to separate the construction of a complex object from its representation. By doing so, the same construction process can create different representations."

However, the construction is not being discussed here.

What's discussed is a data member of class A, which cannot be accessed by methods of class A, only by methods of unrelated class B.

Builder pattern to return nested class or aggregate as a contract appropriately constructed with specific semantics.
If you want exclusivity(?) i assume you mean here immutability of items - return nested class or ask builder to make you a contract with Enumerable(iterator) to underlying storage, which do new instance(copy) of each returned item.

In case you refer to exclusivity in a sense of immutability of underlying storage - i.e. after generating contract not to observe changes in underlying storage (new item added for example due to laziness of Iterator will be still observed) - copy underlying storage and evaluate it eagerly.

In case you refer to exclusivity in access semantics - that’s exactly why we want to have contract.
The only purpose of builder pattern is to generate the contract with exact semantics caller requested. (access semantics, items semantics (mutability), lazy, etc)

Otherwise common pattern is to create (using builder pattern or just simply return nested object) on request a contract for some underlying (polymorphic) data structure, without breaking encapsulation of that structure. This way you can return for specific request (in case of builder pattern) a contract - immutable, with possibly wired events to underlying storage and AP pattern to morph it functionality (and safely compose it), for example to dynamicly extend contract for new query type (this can also be hardwired into builer as well but with losses).
Really its all common topics in any OOP CS.