I enjoy making software. I also enjoy playing with the systems that support making software: for example source control, unit testing, continuous integration, issue tracking. As a result, I have wanted to set up my very own build server to manage personal projects for a while now. As an intermediate step to building my own server, which looks to be a rather large undertaking, I have elected to use bitbucket. Using bitbucket not only provides me with these services while I work on developing my own, it should help to inform the choices I make regarding my own system.
For those who are new to bitbucket, as I am, it is an online service that provides, among other things, Mercurial hosting for your source code. Its use of Mercurial, which is my current source control tool of choice, and its use of ssh keys for simple and secure communication are the two main reasons I have chosen it. Speaking of ssh keys for communication, there are two different ways to access your code once it is on bitbucket: via https using a username and password, or via SSH using public/private keys. I’ve elected to use SSH because using https requires that you enter a password whenever you commit, and I’m too lazy for that. My personal philosophy is to automate as much as possible, and make things as easy as possible long term; even if that requires additional effort up front.
Now that I am back in the world of full-time work, I have begun to think more seriously about my goals. One of my life goals, which I have recently decided are a superset of career goals, is to learn as much as possible. I have also decided that learning as much as possible is also a member of my set of career goals. To alleviate any confusion, I drew a Venn diagram summarising the situation.
As part of my new job, I am programming in C++ for a good part of each day. A consequence of this is that I am constantly learning new methods for writing and debugging C++ code, and programming in general. In an effort to document and share this knowledge, I’m going to start by telling you about
memset are two functions included in the C standard libraries.
memcpy is used to copy a block of memory from a source to a destination, and
memset is similarly used to set a block of memory to a particular value. While quite low level functions, these can both be very useful if speed is critical and you’re not working with higher level containers for whatever reason (yes, I know everyone says to use vectors if you’re not using straight C).
For the really geeky amongst you, here’s a pretty good article explaining some of the issues and approaches relating to floating point comparisons in C/C++.
On a side note, I’m almost done with my uni assignments for this semester. I’m hoping to post a few articles based on stuff I’ve encountered this semester once I get into exam period/holidays.
That is all.
I’m currently planning on a career in games programming and was looking for some beginners’ tutorials in OpenGL using C++ and found a goodun over at code project. It’s a 3 part tutorial, and as I’m writing this the first two parts have been posted, complete with code and Visual Studio project files. As a relative beginner with C++ and a complete beginner with OpenGL I’ve found this fairly easy to follow. The code is pretty well commented, and the tutorial itself explains things clearly and doesn’t take too much for granted aside from a basic knowledge of programming/C++.
A trap for young players, there was a slight error in the code from the first part that caused the program to not shut down and stay in memory after the window had closed. Nobody else seemed to have this problem, and it could have just been me being difficult and using Vista. Nonetheless, if the code for part 1 hasn’t been updated, the fix is in the comments below part 1. Basically the main application loop did not clear the message queue with each iteration, only taking the first message. From what I’ve read on the issue this means that the WM_QUIT message sent from PostQuitMessage() is never received. This is because PostQuitMessage(0) sets a flag on the message queue which tells it to return a WM_QUIT message if the queue is empty. Obviously if the queue is never cleared, this message is never returned when the queue is queried for the next message.
If you have any problems with this, feel free to contact me. Happy coding!