An efficient and simple object factory for PureBasic

Posted by on May 3, 2009

Whenever you deal with structures and what have you it’s obvious that there has to be a better way of doing it. Think about it, you encapsulate your structure-related code in such a way that it becomes clean, nice and tidy — in other words it makes it easy to understand what it does.

However in essence, you end up writing pretty much the same allocate / deallocate, list, etc. code every time you incorporate a new “class” into your project. Why should we?, let’s avoid it all together and focus our efforts in the task at hand rather than in the mundane stuff.

If you open your eyes you’ll see that this is an obvious pattern but what isn’t so obvious is how do you implement a template that deals with it in an efficient and clean way within the current constraints of the language.

Well… Have no fear, EasyObject is here!
First, download it. Secondly, embrace it.

Third, you’re free to post any comments regarding on how to enhance it if you dear to!.

Ok, now let’s describe this thing a little more and leave the marketing speech in the past.

From the “readme”:

EasyObject is an object factory template for PureBasic. It allows you to register any structure as a “class”. With EasyObject you can define constructors and destructors as well as iterators with ease.

The purpose of EasyObject is mainly to encapsulate trivial and redundant code usually regarded to allocation, deallocation and keeping track of the objects. The usage is fairly simple: classes can be registered and unregistered. Once a class has been registered, we can create new objects and delete them at will. If we decide to unregister a class, all of the objects will be freed and their respective destructors will be called.

More from where that came from…

Macros in this case are used as an aid to define templates (like you would in C++ for instance). There are certain limitations that forced me to design the template as it is right now but the usage is very simple. We’re not trying to mimic any language here but rather provide a way of dealing with objects without having to write redundant code all the time. Because overloading doesn’t exist in PB, the constructor will be called twice (once by the template and once by yourself) if you want to define the members using said ctor, just make certain that any dynamic allocations are performed only once or you’ll have a nasty memory leak in your hands.

It’s clear that some limitations are present in the template but for most of the tasks this is a great addition to anyone’s code.

Let me know if you find any bugs!


12 Comments on An efficient and simple object factory for PureBasic

Respond | Trackback

  1. Tenzo says:

    Looks useful thanks. I had no idea you could do this sort of things with macros.

  2. myth49 says:

    awesome! any chance of sharing that sprite atlas lib you were talking about the other day? i could really use some help in that department! right its time to refactor some code now. hopefully it wont be too hard to utilize your evil little template hehe

    • admin says:

      Soon, probably. Right now I’m working on a rectangle packer ( with a nice selection algorithm that takes care of giving the packer the images in the right order both by area and aspect ratio. I haven’t seen a similar packer yet, they all either use area sorting or no sorting at all (some perform width or height sorting but that’s not efficient!).

      • admin says:

        Updated the package. I’m not keeping a change-log this time but basically I just added the possibility to use a parameter with the iterators. Those coming from BlitzBasic will find the template quite interesting since it gives them the same functionality that’s seen on the language (types) with just minor syntactic changes.

  3. tron86 says:

    is it faster than doing it myself? why should i use this instead of just declaring a linked list whenever I need it? it’s not very clear IMO.

    • admin says:

      For one, you must understand the concept before you decide whether it’s useful or not. The idea came from the way BlitzBasic handles structures; it does so in a global way, each “structure” is in fact a structured linked-list, making it easy to work with. Factories are useful in the sense that they handle every object for you. It’s equally fast as if you were doing it yourself, this are just macros that encapsulate the whole pattern. You’d use this to save time in writing mundane repetitive code that won’t get you any further into development but rather delay your progress considerably. At the end of the day I wouldn’t be using PB for anything serious anyway, this is just for fun. I code in C++ mainly. It’s still nice to have an object factory that I can just plug in and use like this one. Try it out and decide whether it’s your thing or not — no strings attached.

  4. [...] this principle you can abstract almost anything, within reason. One good example is my object factory template.  Ideally one would have arrays, lists, etc. Implemented in this very same way, in such [...]

  5. andrew says:

    thanks, the object factory is great; bolted a hash table to it so that i can address the objects by name, yay

  6. andrew says:

    hi i used a shift-add algorithm to generate the hash, and implemented a Get_#_type( name$ ) function that returns the address of the #_type item; it returns zero if it doesn’t exist. the hash collisions are handled through the table (actually an array) with a jump-to index for items with identical hashes

    one thing i found out though DeleteElement should be used with the optional parameter in case the 1st element is being deleted

    • GuShH says:

      You’re right about DeleteElement – I’ll fix it later – I’m not used to PB’s linked-lists mainly because I use my own (I find little use on static lists). Only recently they became faster due to the fact that they’re using a memory pool (afaik) but that’s not the end of the world.

      Eventually I’ll post most of my libs in here.

  7. GuShH says:

    Updated the code, there was a slight bug in one of the examples (number 3) — Thanks to Richard for pointing it out!

    Same link as before:

    I might refactor the code for 4.50 now that dynamic lists are available, but we’ll see when I get the time!