4nt1 V3nd0r

In the end the decision is quite simple. And it's not a matter of managed vs. unmanaged. It's more a matter of whether I am going to commit myself to the technologies provided by one certain vendor or not.

And the simple answer is no! It took me a lot of time and energy to find out whether I am willing to limit my possibilities and to move to a vendor specific style programming. It should be said that this is not quite correct because in fact C++/CLI - which is what I am talking about - has become a standard. Additionally it should be said that I think that C++/CLI will definitely appaer on an open platform. But for me the problem is the support by the underlying class library. And what I doubt is that platforms like Mono will be 100 percent compatible with M$ .NET. I think they will differ. Once these platforms are established in the open source world I think I will re-consider moving to C++/CLI. But at the moment this is no option for me.

Native or not - That's the question!

This week has been a week with a whole lot of work. And all that despite the fact that today is the last day of my two weeks lasting vacation. Actually, I thought that I could bring the project, a friend of mine and me are currently working on to a new point, but that's something I wasn't granted.

And the reason is that I started (more or less accidentally) reading about C++/CLI. If anybody asked me why I couldn't say. And this took me on a journey through a whole lot of new stuff - managed c++, Visual Studio 2005, .NET 2.0, WinFX.... and that's where I am. All this made me wonder whether it were useful to put our project on a native base or whether it would make more sense to start on the upcoming managed system programming interface that will be published next year with Windows Vista - namely WinFX.

OK, wondering if and what makes sense never takes anybody to any destination and this is why I have finished right in this very moment running the installation tools for the whole WinFX stuff on Windows XP. Everything went fine and my computer now contains the beta versions of the next windows system programming environment. Well, there were times when I would have put down anybody who is doing this as an idiot. It seems that I am the idiot now, but I think next year I'll be glad about this. There's just one flaw. The WinFX extensions for the Visual Studio 2005 Beta 2 do not support Visual C++ 2005 Beta 2, but only Visual C# 2005 Beta 2. Hmm, it seems that one day I will have to learn this language, too. At least I starts with "C" ;)

The next shot

Today is a nice day. I finished the first version of a tiny piece of software which is to become one of the more important building blocks in my upcoming work.

For a long time I carried the idea of expanding C++ objects whenever I want to with me. And since it's my character to stick to a goal until I am at least a bit satisfied I am now able to say that the expansion framework has become reality. It is to become one very important characteristic in the object system I am currently fixing my thoughts on.

To explain the idea very briefly. I want to take a C++ object, put it into a blackbox that has a "Expand-Object-with-X"-button. And when I pressed that button I want another object to come out on the other side that contains the original one and the expanded part.

Now one might ask what this is necessary for. Well, having such a mechanism allows me to combine arbitrary data in one object. I can use different "stages" of an expansion to select behaviors just by overloading. More precise: If I decide to take an int. And I decide to expand it with a float. And the result is then an IntFloat. Then I can write a function which takes an IntFloat as parameter and furthermore I can overload this function with lots of other "stages", for instance IntFloatBool and so on. This is a very big advantage since I am using the type system of C++ as a state value. In addition the object that is finally created might "know" how to do  certain tasks, e.g. encode itself into another representation. Since the outcome of the expansion is a structured type, i.e. a class hierarchy I can address certain "subobjects" and do whatever I like with it.

Another thing I can do with the object expansion framework is that I can combine behaviors together, e.g. I can create an object that contains the methods of two distinct classes that do know nothing about each other.

If this isn't a reason for today to be a good day.....

First Results

Well, it's been a long time for me since I found the opportunity to write some lines. But that's now over. While more or less away I thought about some template related problems which I want to come up with a solution for. At least I think I found a way to deal with these problems a bit more elegently. In addition I took my time to start my first serious template coding affords.

So, here we go. The first tiny thing I already mentioned earlier is the problem of using templates in dynamically loadable entities such as DLLs or shared objects on unix platforms. My way of approaching this problem is quite simple since it doesn't require any special techniques. It's just a matter of how classes are designed - templated classes in special. Since the definition of a class, function or member function templates has to be known at the point of usage it is necessary to put the definition of those templates in the same header file as the declaration. Not doing so would result in a separation of the template declaration from the template definition which is no good idea since then the compiler is not able to generate code for the instantiated template after including the header. Only the template-id will be introduced, but later linker errors will occur.

At this point a must say that I act on the assumption that the inclusion model is used and not the separation model since an implementation of the export keyword is not spread very far. So I concentrate on this scenario.

Now, when designing a class I'd propose to separate that part of the class which is not templated and the other part which is dependent on the template parameters. The non-templated part is moved in an own class, say a core or impl class. This class is then made public (or if its functionality should be accessible only for the templated part then protected). This way we can provide an interface that can be exported from the library without problems.

The templated part then is derived from the core class, so that it doesn't need any member of it. Its implementation is done completely in one header (or in two with a class definition and an imline implementation of its methods.

The effect is, that when compiling the dynamically loadable library the functionality of the core class is exported (which is what we want). The template doesn't get any export/import declaration since it resides completely in headers. When the header is used in an application later the core will be imported (because all necessary parts of the library are imported by the application). And that's it. Easy!

The difficulty of templates

Now that I have had some time to get used to the needs and habbits of templates and STL containers I feel like not everything is as nice as it seems to be from the far distance....

Well, to start at the beginning, let me explain what I have done.

At first I decided to re-write the Sniffnose CORE SDK. And how? Yes with C++ templates. The reason for this decision is simple: It's more generic and I am forced to think about the code in a quite more detailed way. So I took some pieces of the existing code and modified it accordingly.

This made me aware of a problem I never got in touch with this intensively - exporting templates from dynamic libraries. Have you ever tried to do this? If not, don't just even try - it doesn't work. Well, it works, but only If you are willing to specialize the template and export this class - but why should I export a specialized template? It's not better than a "normal" class - DAMN!

And today I found a second thing. OK, this was more due to the fact that I haven't used templates intensively so far - especially the STL containers. Using const values in these containers is something which is not advisable, BUT there are compilers the are willing to accept these constructs - for instance VC.NET 2003. The funny thing about this is, that VC6 complains - btw: in a very cryptic way - about std::set :)

Hope you find this information useful.