Comments for page "Enclave Pattern"

(no title)

Sat, 16 Nov 2013 14:46:29 +0000

Yes, it's a pretty lame solution. I've posted the article only because I've never seen this pattern in the wild. I thought it would make for interesting reading and possibly make people think of limitations inherent in existing languages.

(no title)

Sun, 10 Nov 2013 06:10:26 +0000

Problem 1 is still present in your solution, since you have to modify the class ‘B` every time you want to add it to another list. Not that it were something bad. But you’ve mentioned this yourself in your previous blog post as an argument against C++'s way, and directed it upon other people's attempts at solution, so you should respect your own standards here too ;-) According to this standard, this solution is still not the ideal. And making it ideal by enforcing 0 modifications to the ‘B` class, or even no recompilation required, could be difficult to achieve, if not impossible. Because, as you’ve said yourselves, you need to put those ‘prev` and `next` somewhere this way or another. And every time it would have to be a part of `B`’s objects' layout in memory, whenever this layout will change, `B` and its users would have to recompile at the very least, I guess.

(no title)

Wed, 09 Jan 2013 05:19:54 +0000

Thanks! As a long-time OO programmer I've found this pattern pretty surprising when it arrived to me. It kind of goes against the grain of the common use of the C++ language. Enjoy.

(no title)

Tue, 08 Jan 2013 21:45:26 +0000

Martin: Congrats, this is a very interesting exercise. I like the 'enclave pattern' solution. I will use it for team projects. For small personal projects I will stick with the simpler C language solution and be a 'disciplined' programmer.

(no title)

Sun, 30 Sep 2012 06:14:14 +0000

Yes. However, if you check the implementation of offsetof macro, it does exactly the same thing as my implementation.

(no title)

Sun, 30 Sep 2012 06:12:44 +0000

Yes. Unless you use some genric-to-specific conversion (like get_containing_class) the container would have to know the type of the element it contains.

(no title)

Sat, 29 Sep 2012 22:07:24 +0000

And of course even if you could declare that pointer-to-member template parameter, there may be no way to use it.

 struct person { list::helper all_persons_helper; // ?? };

(no title)

Sat, 29 Sep 2012 22:04:28 +0000

I've tried different solutions but it seems to be impossible to get away with only one list class (and no instance class). The problem is that you can't the declare a pointer-to-member as a template parameter because the helper type isn't declared yet. On the other hand, if you try to move helper outside of the list, it seems impossible to make it a friend of list.

(no title)

Sat, 29 Sep 2012 21:52:30 +0000

I've come up with a version of your list which doesn't require get_containing_class(). Instead, the list itself knows what elements it contains and it links directly to them instead of helpers. For this to work it also needs to know what its helper object is within the element, and this is done using a pointer-to-member template parameter. (note: this does actually compile with g++ and run)

 template  class list { public: class helper { private: Entry *prev; Entry *next; friend class list; }; template  class instance { public: instance () { first = 0; last = 0; } void push_back (Entry *item) { (item->*HelperMember).next = 0; (item->*HelperMember).prev = last; if (last) { (last->*HelperMember).next = item; } else { first = item; } last = item; } private: Entry *first; Entry *last; }; }; struct person { list::helper all_persons_helper; list::helper tall_only_helper; int age; int weight; }; typedef list::instance<&person::all_persons_helper> PersonsList; typedef list::instance<&person::tall_only_helper> TallPersonsList; int main () { PersonsList persons; TallPersonsList tall_persons; person p1; person p2; persons.push_back(&p1); persons.push_back(&p2); tall_persons.push_back(&p2); // p1.all_persons_helper.next = 0; // Doesn't compile! }

(no title)

Sat, 29 Sep 2012 20:58:18 +0000

I think this pointer conversion can actually be done in standard way (not implementation dependent) by using the standard offsetof() macro (as I've already mentioned in the previous blog post):

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

(no title)

Fri, 28 Sep 2012 07:44:17 +0000

Yes. My claim was that using C++ for system-level programming (ZeroMQ) was not a very good idea. Once you get higher in the stack, C++ becomes more and more preferable. For rapid development where 100% reliability and utmost performance isn't that important it's almost perfect.

(no title)

Tue, 18 Sep 2012 15:21:07 +0000

It makes things easier for me, because I don't loose all the abstractions I want which make maintenance a lot easier. Programming against implementations is the worst you can do, independent from OO or not. And talking about maintainability, I can add a fourth list without changing anything in the source code by extending the declaration to have another node. The other approach violates many established principles, at least single responsibility, dependency inversion and open/closed principle.

(no title)

Tue, 18 Sep 2012 15:16:41 +0000

"The OO in a certian way isolates the developer from actual memory layout and thus can lead to sub-optimal solutions"

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.

(no title)

Tue, 18 Sep 2012 07:54:01 +0000

"In a real OOP design, I am not interested in data members (and surely not in data layout)"

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.

(no title)

Tue, 18 Sep 2012 07:49:51 +0000

IIRC the helio's implementation would require something like this when object is included in 3 lists:

node > >

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.

(no title)

Tue, 18 Sep 2012 07:39:53 +0000

100% correct

(no title)

Mon, 17 Sep 2012 23:22:17 +0000

I am not sure enough in my grasp of C++ to know for sure myself, but it seems this requires class person to know it will be stored inside a container of class list – it makes it impossible to alternatively store a person instance in a container of a different class without declaring another enclave inside person for every possible container, i.e. the only encapsulation achieved here is data hiding. Is that right?

(no title)

Mon, 17 Sep 2012 12:50:11 +0000

Of course you never want to do that! You should always rely on interfaces and abstractions, and never on implementations such as data layout in memory. Having to use this kind of a hack would prevent me from using the hole machinery and use some other implementation for intrusive lists. Boost discusses some alternatives, and helio and I have shown another.

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

(no title)

Mon, 17 Sep 2012 12:43:34 +0000

Well, it adds the functionality to be part of a list to B, so in that way it is a mixin. Of course, you chose to implement the functionality in a way which is kind of non-oop because it does not talk about behavior or actions but about some members of a "glorified struct". In a real OOP design, I am not interested in data members (and surely not in data layout), but in the interface and behavior of objects. I think you should focus less on data layout and data modelling but on interfaces and behavior of things if you want to have an object-oriented design.

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?

(no title)

Mon, 17 Sep 2012 05:21:57 +0000

You can use the following macro for example:

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

Usage:

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