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

Advertisements

std::ios_base format flags are a resource that needs RAII

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

Installation of gcc on a user account

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

Subversion with Cyrus SASL

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

Global PATH in Debian Wheezy XFCE

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

So that seemed to be what I was looking for. Read more of this post

Type pack metaprogramming

I did advertise once to my c++ students that my feelings tell me that variadic templates are going to be key in implementing type lists in c++ template metaprogramming soon, and showed them a half-baked sketch. But they were not happy with that, “So, you have that class that depends on the type pack, very nice, now, how do you write a method whose signature is calculated out of your type pack?” they asked immediately. Such students’ questions brighten your teacher’s day, even if all you have to say at that point is “I’ll tell you next week”. So I will try in this post to work on the answer step by step.
Read more of this post