Archive for the ‘C++’ Category

Delegators #1 – C++ & Win32

Wednesday, November 14th, 2007

In the technical point of view a Delagator is a call-forwarder, as simple as that. But in the designing aspect it is a technique where an object outwardly expresses certain behaviour but in reality delegates responsibility for implementing that behavior… And thanks for Wiki for sparing me the ugly explanation. :)

The reason I came up to want to implement delegators as seamlessly as possible in C++ was because I got to a situation where I wanted to write a pure OOP wrapper for windows objects (CreateWindow). Now let me get into the juicy details before you raise your eyebrows. And even before that – yes, something like ATL but only for windows. So say you have a class that is responsible for creating a window and controling it by handling its messages and stuff. Sounds legitimate, right? It would look something like:

class Window {
Window(const cstring& name) { m_hWnd = CreateWindow(…) }
void Show () { ShowWindow(m_hWnd, SW_SHOW); }
 HWND m_hWnd;

And you get the notion. It looks ok and it is right, but let’s get further and hit the problem. When we create a window we need to pass the name of the window-class, that is some structure that contains more general info about the class itself, like the background color, mouse cursor and other stuff, but the most important one of them is wndproc pointer. The wndproc pointer is a pointer to a callback function that handles the messages of the windows that belong to this window-class. I assume you know how Win32 Windows system works. Now, can you spot the problem already?

Well, since it asks for a pointer to a function, and we want to have an instance of our Window object per window, there is no way to bind between the two. (OK, I lie, but continue reading please). In our case we would like to have the method of our message-handler being called and not a global function. If you’re not sure why, then think that each window has some private members in its instance that tells special things about that window. So we gotta find a way to link between our instance and our “window-procedure” method.

This is a start:

class Window
LRESULT WINAPI WndProc(HWND hWnd, UINT message, WPARAM wparam, LPARAM lparam)
 switch (message)
 return DefWindowProc(hWnd, message, wparam, lparam);
static LRESULT WINAPI WndProc(HWND hWnd, UINT message, WPARAM wparam, LPARAM lparam)
 // Delegate to the instance’s window procedure.
 return g_window.WndProc(hWnd, message, wparam, lparam);

So now the window-class structure will point to the static function WndProc which when called will delegate its parameters to the internal (private) WndProc that can access the members. It’s almost a good solution. But now we are allowed to have only one window and a global instance that contains it. The good thing is that a static public function can call a private method of the same class, so we can hide the core of it. The bad thing is we still expose an internal function we don’t want to in the first place.

The problem is now to find a way to link between a real window object and our instance. The ID of a window is its HWND (or Handle to Window). So we could hold a list with all HWND’s we created and look it up before delegation and then make the right call to the correct instance. This is too much hassle for nothing. There ought to be a way to store some private data on the window object itself, right? At least I would suspect so. Eventually, after reading some MSDN and searching the net, I found a savior function which is called SetProp (and GetProp ofc). Exmaining their prototypes:
BOOL SetProp(HWND hWnd, LPCTSTR lpString, HANDLE hData);
HANDLE GetProp(HWND hWnd, LPCTSTR lpString);
We actually have a kind of dictionary, we give a string and store a pointer (to anything we’re upto). Afterwards, we can retrieve that pointer by using GetProp. Let’s work it out again:

m_hWnd = CreateWindow(…);
SetProp(m_hWnd, “THIS_POINTER”, (HANDLE)this); // Ah ha!

What we did was to link the HWND with the this pointer. The window procedure will look like this now:

static LRESULT WINAPI WndProc(HWND hWnd, UINT message, WPARAM wparam, LPARAM lparam)
 Window* pThis = (Window*)GetProp(m_hWnd, “THIS_POINTER”); // Some magic?
 if (pThis != NULL) return pThis->WndProc(…); // Forward the call to the correct instance.
 return DefWindowProc(…);

 Well, as for the code here, I don’t handle errors, and I use C casts, so sue me :). I merely wanna show you the mechanism. And if you really wanna get dirty, you will have to RemoveProp when you get WM_NCDESTROY, etc…

After I got this code really working, I still was wondering how ATL does this binding. So I took a look at their code… It seems to have a global linked list with all instances of the windows that ATL created. And then when the global window procedure is get called, it looks it up on that list. In reality it is much more complex then my explanation, since they need to synchronize accesses among threads, make sure the window belongs to the same thread, etc… All that for only the first time call of the window-procedure. Then it sets the REAL ‘window-procedure’ method of the instance itself, and there it uses Assembly, muwahaha. That will be covered next time.

BTW – SetWindowLong cannot work since all you can do is changing the window-class fields. Although, maybe there is some undocumented field you can play with to store anything you like. Never know? :)

C++ Singletons

Monday, October 29th, 2007

One of the first rules you learn when programming is not to use global variables. Sometimes it’s possible and sometimes it’s not. I believe that every rule has an exception, <– this too. But the thing is that if you code in C++, you say to yourself, let’s encapsulate it all in a class. How nice, huh? Thing is that from the beginning you knew that those variables should be global, to something. Everything is in relation. Certainly not all functions will use the globals. The real example I encountered was to use the AllocConsole API for creating a console screen for my process. The system allows for every process to have at most one console, so obviously wrapping it in a singleton class is a good move. That class will contain also some variables which hold the state of the console. Let’s spare the gross details for now…

So having the variables inside the class as a namespace led me to touch the variables as:

void MainClass() 
 Console::m_staticVariable = ... 

Then I found myself accessing that variable from the MainClass, and I understood that I should move some code from MainClass to the Console class. Hey, you can say that I designed the whole thing wrong from the first moment. But believe me, sometimes you just have that piece of code which might lie in both classes. Eventually you have to decide where it fits better. Even though after some coding I was satisfied with my code, all the methods were static as well, otherwise I can’t access the so called globals. Although, this time the globals are in a namespace, that’s a start. Noticing that all Console’s methods were static, I got disgusted at my own code. Seriously, that happens to me too ;) As long as you don’t commit the code, you are allowed to go all the way until you are satisfied and the code is to your liking. At least this is what I think.

So… singleton was my answer, of course.

The “standard” basic pattern for a singleton would be to make the constructor private and have a getInstance method which will return the one and only instance of the singleton class in the system. It looks something similar to:

class MyClass {
MyClass() { … }

static MyClass& getInstance()
 static MyClass instance; // This is all the trick.
 return instance;


Speaking technically the way the static is implemented in Assembly is just setting a boolean with true when you create the object the first time and even register its corresponding destructor to the _atexit CRT function. I found it interesting.

Here it is in a nutshell:

static MyClass& getInstance() 
 static bool isInitialized = false; 
 if (!isInitialized) { 
  isInitialized = true; 
 return g_MyClassInstance; 

 Static variables are not magic, you have to check whether they are already initialized or not. The generated code, is no brainer, and uses a boolean to check it out as well.

So off to the way I went, changing a few bits of my code to become a singleton. While testing my code again, I got a crash when the program was finished. Now quickly thinking, there’s something wrong with a “destroy” code, either destructor or something similar doesn’t function well. Well, looking at my MainClass dtor I noticed that I have to control the death of the Console class. Note that when calling the getInstance method the first time of a singleton it will only then get initialized. So you are guaranteed when the singleton-instance is constructed but you don’t know when it will be destructed. Doh.

Well, let’s go to business, implementing a dynamic singleton. To be honest, I have no idea how that’s officially called, I’m pretty sure someone already named it with something. Using the dynamic singleton I control both construction and destruction timings.

The first getInstance implementation that comes to mind is something like this:

MyClass& MyClass:getInstance() 
 static MyClass* instancePtr = NULL; 
 if (instancePtr == NULL) { 
  instancePtr = new MyClass(); 
  // error code for handling bad_alloc... 
 return *&instancePtr; 

Now you need a destroy method:

void MyClass:Destroy() 
 ASSERT(instancePtr != NULL); // No no. 
 delete instancePtr; 
 instancePtr = NULL; 

Aha! Now notice how Destroy access instancePtr which was defined inside getInstance. Therefore, you have to move the pointer to be a static class member, how rude. But no biggy. Of course, you must not call Destroy from the destructor, to avoid recursion and bad stuff happening, in short. It is vital to remember to call Destroy, otherwise you are in big troubles. On the other hand, having C++ on our side, we can extend the code so it will use a sort of smart pointer that will know when to destroy the instance automatically. A static std::auto_ptr<MyClass> m_instancePtr, will certainly do the job.

Now you ask yourself, why the heck should I use the smart pointer mechanism if I want to control the construction and destruction of the singleton. Well that’s a good question, you have to consider multi-threading.

Some problems arise with singletons and multi-threaded applications. Even though my specific application was MT, I didn’t have to worry about the construction of the singleton instance because it was surely done before CreateThread was called. When you cannot be sure about that, you will have to protect the static instance on your own. But you cannot wrap the static declaration with acquiring any sort of a lock. Maybe with a nested anonymous scope? While I’m not really sure, it’s pretty ugly. So that’s why you need the smart pointer mechanism which will destroy the class on its own accord (assuming you don’t really care when) and you are the one who fully control the construction time…

Benny and the jets say hi.


Saturday, July 7th, 2007

Exceptions are one of the most flamed topics in C++. But before I talk about the operator new I want to say a few things in general about them. There are many ways to use exceptions, different approaches. Although, it costs more than error checking in sake of speed, it is pretty convenient and usable. Well, some people use it to replace these return code tests. Others use it in rare cases where something less expected happens. I even saw some justified reasons to why not use it. For instance, you can’t see if a function throws an exception from merely looking at its interface. Every library has its own type of exception base class, CAtlException, std::exception, etc… And you should not let anything slip your catch clause. So sometimes it might be pretty annoying to catch them all, and then you have to multiple your inside-catch-clause-code for handling each different exception. And if you have C++, you won’t dare using goto, even not for a cleanup…Of course, there are good sides also and that’s why most people use them after all.

If we take a look at the operator new, that’s the C++ raw memory allocator, we will see that it might throw an std::bad_alloc in case of failure, which is 100% legitimate, because most of the times you just expect that it will return your a pointer to a valid contigious block of memory. But now, assuming I use my own internal exceptions type for my application; Why do I need everytime to catch this exception and rethrow the converted exception? This is waste of time both in development and in run time. And there are some approaches who believe you don’t have to catch it at all, because if it is thrown, you are dead anyways. Now tell me seriously, if you write a real software for a company, you are not going to catch it? now gimme a break! So catching it you must, and therefore I don’t think every usage of the new operator should be wrapped by its own try and catch if you wrap it anyways with catching your own application’s exception. So eventually, after lots of discussions with my colleagues, we decided it suits us mostly to overload the global operator new function with our own custom function with a single change, that it will throw our exception rather than std::bad_alloc in case of failure. Overloading that operator, requires you to overload the array interface also. Don’t forget, when overloading new you will want to overload delete… :)

Oh Boy, There’s a Bug

Tuesday, June 12th, 2007

Can you spot it?

void p(const CString & str)
char* endPtr = NULL; 
unsigned long x = strtoul(str.Mid(1, 2), 10, &endPtr);
if (*endPtr != ‘\0’) {
// invaild input…


 Using ATL’s CString, you can run this code and nothing will happen – the bug won’t be ‘triggered’. And more than that, everything will work as expected and correctly. But as most developers find bugs, running the software and fixing the crashes, this one didn’t come up to the surface… so you have a bug and you don’t know about it, how not fun. If you are really into C++ business it might be easy for you to spot this bug. But I’m not sure if it’s C++ to blame here, guess it’s not. If you take a look at the Mid method its declaration is as follows:

CStringT Mid(int iFirst, int nCount) const;

 This means it returns a object with the relevant slice of the original string. The destructor of this new object is immediately called, because its scope is a ‘parameter’. So now the endPtr points to freed memory. Yey. And then you access endPtr as you should…even if the memory is freed it is still in memory (because CString dynamically allocates space for its buffers), only AppVerifier forced it to be removed, thus generating an access-violation and then it surfaced up and we fixed it. But, honestly, it was still tricky to spot this one.

 So now that you know the bug and why it happened, I can only say that you should beware of methods/functions that return objects and has a very short scope, if at all. Not mentioning the copy constructor issues… Of course, merely the scope isn’t to be blamed, it’s the mixture of short scope and a stale pointer (and dynamically allocated memory),…To be honest, if the memory was local to the stack there was no way to detect this bug, unless the compiler would use the same stack space for different variables and they were written to between the call to strtoul and the access to the pointer. And even that isn’t reliable, but you could notice some weird mismatches between the input and that input validation…

 Any suggestions for tracking such bugs?