I have just had my first encounter with the C++ Wall. This is a term that I once heard a classmate use when talking about advanced object oriented designs. Basically there is a lot of OO sort of things that C++ does not provide support for. To put things in more concrete terms, let me share a little bit of the development process that I'm going through with the HyperUtil library.
The initially stated goals of the HyperUtil library include being MT Hot with zero dependencies to the stdlib. This meant having an architecture to support a pluggable memory model and a pluggable threading model.
The first components that I made were the rudimentary interfaces for the AbstractThreadingModel and AbstractMemoryModel base classes. Next I made an AbstractList interface to encapsulate the implementation details (backed by linked list or primative array for example). In Java, this sort of thing is quite easy to do and I frequently use Abstract Container-type interfaces. After fighting with the compiler and various syntax iterations I resigned myself to scouring the internet for help, only to find that there is no way to subclass a templated Abstract Base Class. This is due to a number of characteristics of the language. First, the template mechanism is really more like a fancy macro system. The code for the templated type is only created during specialization (the process of telling a templated class / function what type you will be using) and two specializations of the same type are not the same in the language!
I sort of put the problem aside for a while and went on with developing an array type for the library (resizable, maintains a length) that is templated. I want to use the flexibility provided by templates, but I strongly dislike how using a templated type anywhere causes the template keyword to infest more and more of your code until it begins to resemble the STL. As a temporary workaround for my list interface issue, I have been considering another use of templated types. Consider the following C++ code (Note: exposing 'T' from the templated concrete list to this template is left as an exercise to the reader):
template <typename AbstractList>
class ListBehavior
{
private:
AbstractList* m_pListImplementation; // Delegate
public:
// Constructor, destructor etc omitted for clarity
T& operator[](int index);
const T& operator[](int index) const;
int size(void) const;
};
Given this class, we then begin to see that the ListBehavior templated class can be used as a way of providing an interface (or even a contract of sorts). With that idea in mind, those methods can be defined in such a way that we get free compile-time checking to ensure that the list behavior we define is adhered to (just like an interface class).
template <typename AbstractList>
T& ListBehavior::operator[](int index)
{
return (*m_pListImplementation)[index];
}
template <typename AbstractList>
const T& ListBehavior::operator[](int index) const
{
return (*m_pListImplementation)[index];
}
template AbstractList>
int size(void) const
{
return m_pListImplementation->size();
}
Now, when a ListBehavior object is specialized, the compiler will create the simple delegation code and cause an error if the type used to specialize it doesn't implement all of the AbstractList functionality!
I understand that this is a slightly complex usage model (using a templated type as a wrapper for a certain subset of behaviors), but the intention if only to expose this to the Library internally, for flexible swapping of implementations and such.
The next hurdle I see is the same sort of problem. I'd like the AbstractMemoryModel type to be templated. I want this so that calls to the underlying implementation can actually allocate the correct types rather than just char pointers. I have a suspicion that the casting from char* to indiscriminate types may cause serious performance issues if not outright crashes due to byte-alignment considerations. This is not a terrible problem on PC platforms, but could be debilitating on embedded systems not equipped to handle sloppy coding.
More to follow,
--Dahlgren
