Saturday, February 12, 2011

The latest with QubLib

Seriously? Months since my last post? Wow, I must be in school or something. Anyways, despite my lack of blog post updates on my cross-platform library, I have not lacked on working on the library itself. Allow me to explain a few of the things that I've been doing in the past few months:

1. Memory Management - This has been a huge undertaking for me. I recently read a book named Effective C++ by Scott Meyers, which I highly recommend to anyone who is interested in C++ development, which talked about overloading the new and delete operators. It was an interesting idea to me, especially when I put it into the context of a smart pointer that would be able to determine if it was pointing to something that was on the stack or not. With a little fancy overloading and some nifty design, I've successfully created a HeapManager that when given any address, it will tell you whether something is one the heap or not. Cool huh? But the fun doesn't stop there! I decided to create an AllocationManager singleton object that wraps the whole memory management process, so anytime you call new or delete, your code will end up running through the AllocationManager. What's in there? Well, for starters there is an IAllocator object that does two things: AllocateMemory() and DeallocateMemory(). The standard one (called StdAllocator) just uses malloc() and free() like the normal un-overriden new and delete operators do, but with a quick call to AllocationManager::SetAllocator() you can implement your own custom allocator and have your program using it in no time. I have future plans for allowing a user to use different allocators for different types, but I haven't quite gotten around to that. It's a possibility though.

2. Design Patterns - After working with a bunch of singleton objects I finally got sick of rewriting the same code over and over again. I refactored out my singleton code into a single class called Singleton which can be inherited to provide default Singleton functionality to any class. Thank goodness for code reuse!

3. IO - I've started working on file and console input and output. It's a little bit of a pain, but it was coming along smoothly until I wanted a FileReader to be able to point to a FilePtrStream that was on the stack in one function and then one that was on the heap in another function. That's when I went off on the HeapManager trip. Hopefully I can get back to IO soon and put it all behind me.

4. UDP - Before my last post I had gotten TCP operations working for networking, but I hadn't quite figured out UDP. I've gotten it to work. As I was working on the before mentioned IO, I realized that I need to cut a lot of my network code and realize that Network sockets are really just fancy streams that a simple Reader or Writer object could interact with. So, my networking stuff will change again, but I'm hoping that this time it will look really pretty.

5. ThreadSafe - Have you ever been working with a data structure and had that sudden thought, "Uh oh... Is this thing thread safe?" Well, let me put your mind to rest! In QubLib, it's not! None of my data structures are thread safe by default. However, lets say that you created an IList in the following way:

IList<int>* intList = new LinkedList<int>();


In order to make this newly formed LinkedList thread safe, all you have to do is wrap it in a ThreadSafe function, like so:

IList<int>* intList = ThreadSafe<int>(new LinkedList<int>());


And tadaa! It's thread safe now. Some of you may be asking why I don't just make it all thread safe by default? The answer is that I want to give people options. There may be someone who really wants to crank out as much speed as possible, and they just can't afford to have those mutex locks in the code. My first question would be why are they using this library then, but that aside, I still want to provide the options.

I'm sure there are some other little things that I'm missing, but those are the big ones that I've been chugging away on. Right now I'm working on converting my data structures to use a NVI (Non-virtual Interface) design so that all of my public interface error checking can occur in the interface level of the data structure and the rest of the implementation can work off of design by contract principles. There's a lot of future plans I hope to do with this (contractual static flow analysis?), but that's a long way off. For right now, it just helps me fix bugs.

Anyways, that's all for now.  Keep coding!

No comments:

Post a Comment