🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Newsletter #39 - Libraries with Acne

posted in IfThen Software
Published July 16, 2009
Advertisement


News

Overall progress for the Loradon 3.0 Preview has reached 87%!
www.ifthensoftware.net/loradon_online/progress/


From the Programmer
Written by Invisible

I have finally had enough of the mess and have decided to put IfThen Software's engine into libraries. Currently, all the source code for the engine is copied into whatever project needs it. If a change to the engine is required, the changes are made to the engine in the project I am working on at the moment. This wouldn't be too much of a problem if the changes were always made to the other copies of the engine, however that rarely happens. Each project ends up with it's own version of the engine "grown" into it, creating quite a mess.

This is my first "big" attempt to make static libraries, and it is surprisingly easy. The static library is pretty much no different than a normal source code file in your project, it is simply pre-compiled. Of course, there are aspects to static library design that can be a little tricky. Making sure that the user of the library can't see the internals of the library is important, and there are a few possible solutions.

Hiding structures, constants, #includes, and various other parts of the library that are only used internally can be done by creating a public header and one or more private headers. The public header will include what the user of the library needs to use the library. The private headers contain declarations and class/structure definitions that the library uses internally, and does not need to present to the user.

The above solution obviously won't work to hide private members of a public class. In order to hide these details, you can either use a pimpl or an interface and factory.

A pimpl is an object in the public class which contains all of the private members. The pimpl's class definition is located in a private header, so the user never has access to it. Unfortunately, this means that the library will need to dereference the pimpl every time private members need to be accessed, which could happen frequently depending on if the code accessing the private member is part of the pimpl or not.

An interface is a pure virtual class that the library's internal class would inherit from. An instance of the internal class can be accessed through this interface, only allowing the methods in the interface to be access. You cannot create an instance of a pure virtual class, so the library would need to provide a factory to create objects of the internal class and hand back a pointer to it. Since interfaces cannot allow direct access to member variables, this solution would not work well in all cases. Also, there would be overhead every time a method of the interface is called. This is because the object's vtable needs to be checked to find the correct address to call.


Community Spotlight
Written by miotatsu, Arekusandaa and Invisible

We are happy to welcome a new member to the SAO leaderboards, Materger1. Speaking of the boards, it is also interesting that Miotatsu now has the first recorded instance of two separate accounts on the top 10! Also, on the forums Eeevil has been organizing a drawing contest, be sure to check that out!

In the Loradon community the only real activity this week was Jay's discovery that mages can get past level 60.
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement