I've always seen and hated those weird macros that preceded functions of header files. Why couldn't they be clean and simple? I hated them because I didn't know much about them, they seemed arbitrary, prone to error, non-standard, no way of knowing the real motivation behind. 

Not anymore. Today I had to create an intermediary DLL between two different object file formats and I had to go down to the level of dirty and hacky in the quest to make it work. And I stumbled upon this awesome page that has the "ultimate header file" template. I discovered half the things there myself, but it nailed the coffin of problems for me. 

Here are the problems that I had to tackle in general:

hahaha I might not have an iPhone but I have the simulator. I'll edit this and add a screenshot:)

(attached is the screenshot)

Here we go. I formatted my laptop hard drive, wiping away both Windows and Gentoo Linux... It was a tough choice nevertheless, but I had to because (1) my reiserfs partition got corrupted and some config files at my home directory were unwriteable (creating all kinds of fun), (2) my windows partition was too small to do any development on, (3) with the advisor change, I stopped using my laptop at work. I also stopped using Linux at work and entered into the mighty world of Java and Windows, a very positive experience indeed. 

Right now, the binarySearch for collisions stop when the distance for the first contact is within the collision tolerance. For high tolerance values this seems to be ok, but high tolerance creates less accurate simulations.

When the tolerance is low, the while loop in Simulation::binarySearch() actually gets executed and the simulation ends up stepping lower than the real step size. This is easily verified by doing sim->getCollisionDetection ()->setTolerance (0.0001) in CollisionModel.cpp. As the bodies start hitting the ground, the actual timestep varies as can be seen by the time display on the render window. I think this is bad, since most applications would expect the simulation to have the same step size everytime it is stepped. Attached is a patch that forces Simulation::timeStep() not to return till the expected timestep is reached.

http://www.impulse-based.de/phpBB2/viewtopic.php?p=151

Curlpp had a recent release that acknowledged me by name for submitting a patch.

When I'm working on code, most of the time it's really hard for me to sit still and just do it. Most of the time I have to have some other enjoyable thing going on at the same time. I surf, watch videos, listen to music... Sometimes I find a great balance and get a lot done, but sometimes these secondary activities get too distracting and affect my productivity badly. I recently created a nice playlist that could keep my hyperactive side at bay, but after a while the songs got too familiar and started to be distracting.

In quest to find the best working supplement, I started to listen to the in-game musics of Warcraft III. They definitely are composed to supplement some other mind-intensive action, game playing. They are not distracting, but supplementing and feeding with feelings like glory and victory. So far it is working very very nicely and I get a lot done while listening to them. Highly recommended for anybody looking for something to do while engaging in mind-intensive tasks such as coding.

Here is a patch that improves const-correctness in vector and matrix classes of IBDS.

Pointers are the root of all evil when writing a C++ application. You are allowed to point to almost anywhere in the memory address space provided for you. With this huge power in your hands, you try and create objects in the memory, point to them during their lifetime, use them, pass their pointers around and share them, and you are supposed to destroy them when you are done with them. It doesn't matter which class creates an object and which class destroys it, all you know is someone needs to create it, someone needs to destroy it, and in the meantime everybody is allowed to use it. But if anybody tries to use a pointer that is not pointing to a live object, all hell is set loose.

This huge power and the weak creation/destruction restrictions (or lack of them) creates a playground with almost no rules. By definition, this situation invites chaos in the program, and possible disagreements between programming team members over very fundemental design decisions, or disagreement between different parts of code written by the same person. This is unacceptable. The efficiency benefits, if any, of having such a powerful framework is likely to be wiped out completely by the programming/debugging efforts, runtime errors, and memory leaks. This has to stop, noone is meant to have such powers, especially in big projects.

Solutions are many in numbers and the starting point is organization. There has to be a set of agreed rules that guarantee prevention of chaos. Since this can be done in many ways, there is yet another headache we need to worry about, incompatibility. When you try to mix code with different apporaches, you are doomed to be the child between two disagreeing stubborn parents. Which brings me to the importance of standards.

I recently decided to start using Ogre in my research. I was about to write an Ogre widget for Qt before I came across this post on Ogre forums. It was a very nice and clean QOgreWidget, so I had to use it instead of writing one on my own like I did with QOsgWidget for OpenSceneGraph.

The port was simple, I only had to change a couple of little things. This widget has to make its way to the Ogre wiki since the current one is not self-contained and clean like this one.

I'm attaching the patch to this post (linux.patch). It is meant to be applied to the original code in here, which was provided right here.

I'm also attaching the full source (QOgreWidget.tgz) in case you don't want to mess with a patch.

Here are the explanations of the changes I made, with the order as it is in the patch:

1. Semicolon missing, I can see I'm the first person to try it in a platform other than Mac:)
2. In Linuxs, we are case sensitives. (/usr/local/include/OGRE)
3. It would whine when linking that there is no Ogre.
4. I moved that Ogre to the macx section as it seems that's how you do it in a Mac (I have no idea). I didn't want to break it in Mac.
5. Library and include stuff for unix. The code had ../Data/blah.cfg, so the executable had to go to somewhere in build/something. So I made it go to build/bin.
6. Need to give the plugins directory. I hope this does not break Mac. Then again, I'm not sure. I hate the cfg file handling.

http://drupal.org/node/164387#comment-644788