Polymorphic objects with value semantics – custom interfaces

polymorphic values

In my previous post I showed how we could provide object handlers, called polymorhic, that were the cure to most of the troubles that follow from using pointers, even smart pointers. Given class b with base class a we could write

polymorphic<a> p1(create<b>(args_to_constructor_of_b));
p1->foo();              // properly calls foo virtual or not
polymorphic<a> p2 = p1; // real deep copy of contained b
const auto p3 = std::move(p1); // real move from p1
p3->mutate();           // doesn't compile, implements ordinary const semantics
b bobj;
p2 = bobj;                 // properly copies bobj of type b into p2
std::cout << p2;        // calls operator<< suitable for b
}              // p2,p3 correctly delete b even with no virtual destructor in a

All this boon has been achieved by keeping and leveraging a second virtual dispatch table inside polymorphic. The remaining question was how to open the interface of polymorphic to using additional configurable interfaces–vtables. I will try to present two solutions to this problem in this post.
Read more of this post

Polymorphic objects with value semantics

(Updated on 27.11.2016 to correct the forwarding through tuples infrastructure, corrected code shows in the post, old version is available in collapsed sections. Update to the follow-up post will be posted in a few days.)

My last article got posted on reddit, quite unexpectedly for me, and in the comments there some people mentioned things they find abominable in c++ or in my coding. That’s great to know someone cares, so I decided to share one thing I personally find abominable, and some ideas how to cope. Please don’t hesitate to express your opinion, as usual, there’s a comment section below…

Too low level unique_ptr

C++11 introduced unique_ptr, which, together with move semantics, finally allowed for a reasonable management of heap-allocated objects. Unfortunately, one was still forced to write std::unique_ptr<A> ua(new A{}), keeping new on the client’s side of things. This was somewhat corrected in C++14, where you can write std::unique_ptr<A> pa = make_unique<A>{}. However, while unique_ptr has its merits in low-level implementations, I think that it is an abomination as far as dealing with objects belonging to class hierarchies is concerned. I say this, because there is no way to make deep copies (unless you hand-craft zilions of boilerplate clone methods all over the hierarchy), you can shoot yourself in the foot if you forget to make your base destructor virtual, the pointer objects have pointer const semantics, there is no immediate way to convert an existing object of one of the classes into the pointer, make_unique is the preferred way of creating the pointer but it is impossible to create a nullptr pointer with it so this case needs special treatment, this has no chance of working: std::cout << *pa, and, finally, you can call .get() on the smart pointer and leak the result (see for instance http://bartoszmilewski.com/2009/05/21/unique_ptr-how-unique-is-it/ for possible problems). I will try to address all these issues in this article. I am not sure, as usual, if somebody hasn’t already invented what I present here, if you know any references, please let me know. For a discussion on OO (aka class hierarchies) vs. value sematics see http://akrzemi1.wordpress.com/2012/02/03/value-semantics/.

Read more of this post

To const or not to const – the Liskov substitution principle

The Liskov priniple

When inheritance comes to play, it is not always clear how to design interfaces of classes to make reasonable and safe use of it. Most textbooks mention the Liskov substitution principle in this context. Informally speaking, it says that objects of derived classes must be transparently usable wherever objects of the base class are. In this article I try to get to the ultimate conclusions of this rule that I can think of. The ideas here are not entirely new, I admit I just reinvented them, (see for instance Kazimir Majorinc, Ellipse-Circle Dilemma and Inverse Inheritance), but, unfortunately, most discussions end prematurely in my opinion, and I was missing an exhaustive text to organize my thoughts and for teaching. I beg for your patience while reading this lengthy post. It is written with examples in C++11, but I believe it may be relevant to any language with inheritance.
Read more of this post