Code Projects

Projects

I have worked on lots of different programming projects over the years. Some are worth remembering and some are not. Luckily for you, many of them I have subsequently lost through hardware failure or other general movement between machines.

Patches

Over the last few years, I've written several patches for open source applications. Some of those patches were even accepted!

Back in 2004 I tried my hand at creating my very own Linux kernel module. The result was this dmesg.c file. I dropped it in as drivers/char/dmesg.c in the kernel source. I would provide an actual patch against the kernel source, but unfortunately the last time I compiled it was against 2.4.27. The basic idea was to create a character device called /dev/dmesg that would allow anyone with write access to it to dump messages to the kernel ring buffer. While it may not be particularly useful, I found it very educational.

Inheritance

These are some of my thoughts on Inheritance. I read a book called Effective C++ Second Edition by Scott Meyers (ISBN: 0-201-92488-9). In this book, there is a large section on Inheritance. Most of my thoughts are based on what I read in this book.

There are two types of Inheritance:

1. Interface Inheritance (public abstract inheritance)
2. Implementation Inheritance (private inheritance)

Interface Inheritance is what most people think of as theoretical inheritance. This type of inheritance strictly follows the Subtype Principle. Many language s explicitly provide this through "Interfaces".

Implementation Inheritance is what most people think of as code reuse. This type of inheritance cares nothing for the Subtype Principle. Its single goal is to implement a class using functionality from some other class.

In C++, virtual public inheritance is how one does strict Interface Inheritance. One would use private inheritance to do strict Implementation Inheritance. Typically, C++ inheritance is done using regular public inheritance. Simple public inheritance accomplishes both Interface and Implementation at the same time.

Multiple Inheritance often complicates things. In fact, it can be quite problematic. However, I've found that when Inheritance is properly understood in terms of Interface and Implementation Inheritance (as specified above), Multiple Inheritance problems can be avoided fairly easily.

Inheriting multiple Interfaces should only ever be a problem if two methods have the same name. In this case, the Interfaces should probably be broken up into smaller pieces.

Implementation Inheritance can be more problematic. It should be possible is to inherit multiple implementations when "implementations" involve only methods. When data members become involved, it gets more complicated. In this case, one must re-examine why the Implementation Inheritance is necessary.

I would definitely like to hear any responses you might have to my thoughts on Inheritance. Visit my contact page to let me know!