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

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

(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/.

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

Suppose we wanted to write a class Fraction which would come equipped with an input operator>> that would accept input in the form -2/4 or 3/-8, but disallowing any spaces around the division bar. We would need the fraction class itself first, so, trying to stick to Test Driven Development rules, we would need to satisfy the following test function:Read more of this post

The new gcc 4.9 out now, I decided to give it a try on the FreeBSD server my account is on. Of course, no way to convince the admins to have it as default, they’re so conservative they still keep 4.2.1. So the only way is to build it within the user account, and there are some technicalities about it that are worth a note.Read more of this post

I’ve been keeping my programming stuff in svn repositories for quite some time now, and I came to running my own server software instance, after one free service had unexpectedly changed its rules and another just vanished. The server infrastructure my account is on runs FreeBSD 9.2 with nginx 1.4.7, and while this seems robust enough, it did not make setting up subversion easier. I reckon you should encrypt just about everything, to keep Uncle Sam entertained (or any of your other uncles, for that matter), even if what you put there is just your kitchen recipes or your favourite deformed convolutions no one really cares about. But being a user with no root rights behind an nginx server, with just a virtual web server means that the https access is out, having it this way would require my own IP number, and my own Apache instance, and I was not ready to go that way. That leaves one possibility: run the svnserve (1.8.8) server coupled with Cyrus SASL 2.1.26 encryption layer.Read more of this post

As a step in a long term plan to get rid of all MS dependencies of my workspace, I tried to setup TeXLive together with TeXstudio on my Wheezy machine. Got the TeXLive installer, ran the install-tl, which completed, after some choking, with a message, that I should now setup PATH so that it be visible, but without any hint how to do so. Some googling brought the advice to link the binaries to /opt/texbin by typing ln -s /usr/local/texlive/2013/bin/* /opt/texbin as root so that this directory is to be linked instead of /usr/local/texlive/2013/bin. So far, so good. Now, it seems that the installer of TeXstudio is able to detect a TeXLive installation provided it is visible, and installation shall be run as root. It would therefore seem worthwhile to have one central place to append /opt/texbin to the PATH setting of any user running any shell (or clicking on some activator in the GUI). More googling brought information on /etc/profile, ~/.profile, ~/.bashrc and the like, but they are either user or bash–specific, as far as I understand. Then there is /etc/environment, but since this is not a script but a definition file, it seems it is not possible to actually append a path to a preexisting system–set PATH, but to replace it altogether, which, as far as I understand, may lead to a nasty hard–to–understand situation, should the system modify its default PATH. And ultimately, at least according to google, there is the /etc/login.defs file, which is supposed to actually contain the systemwide defaults defined separately for root and non–root users in lines
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games