As I was making some adjustments to my I/O last night I ran across a bit of documentation that I never noticed before. Of course, it could be newly added. Anyway, I've found the most convenient way to parse my documents (I have many thousands of them to read and write), is to access them by node-name. For example:

node["location"]["name"] >> mObjectLocation.location;

The information I read last night, however, may convince me to change this behavior.

Apparently, named-node access in yaml-cpp is order-n² complex over the entire document. Put simply, every time you access a node like this the library loops through all nodes looking for a match. Personally, I think a hashed table lookup would have been much faster, and perhaps they'll add that later.

Overall, I wouldn't normally worry about it because my documents tend to only have a few dozen nodes. But I do have 20,000 documents to parse. And to top that off, as they are used they become more complex. And as more items are added, the node size will grow geometrically. I can easily envision a future where a single document contains hundreds of nodes, and it's starting to scare me.

The solution? Well, I can honestly say I don't have a good one yet. I think perhaps if I enforce the order things are written, which already only happens in one way, I can then read in linearly instead of by node-name. The problem with that is if a file is edited by hand and the order is accidentally changed. So by renaming my current solution to readCompatible() and writing a new linear read() function, I should cut down on a lot of extra unnecessary processing.

But I'm still not sure that's the best solution. Any smart people out there have a better idea?

Unfortunately, I still can't seem to get qi::phrase_parse to work right. The problem is that I'm trying to match one of a set of increasingly complicated grammar structures (perhaps starting at the most complicated and working backwards would fix this issue…). So, here is my problem in gruesome detail:

I'm implementing a get command for a MUD, an online text-only game system. Since I'm writing it from scratch, I decided to use some of the most up-to-date tools I could find to do so, and Boost has some terrific libraries that make this possible. As far as I can discern, the get command can come in the following forms:

1. get hammer
2. get 20 nails
3. get hammer 2 (the second hammer)
4. get 20 nails 3 (20 of the 3rd type of nails visible)
5. get hammer from toolbelt
6. get 20 nails from bucket
7. get hammer from toolbox 2 (the hammer from the second toolbox)
8. get 20 nails from bucket 3 (you get the idea)
9. get hammer 3 from toolbox 2
10. get 20 nails 2 from bucket 3

The problem comes when using phrase_parse with an empty space skip-parser. Given the two rules:

bool res = qi::phrase_parse(first, str.end(),
				(
					+qi::alpha
				),
				' ',
				item
);

And

bool res = qi::phrase_parse(first, str.end(),
					(
						+qi::alpha
						>> "from"
						>> +qi::alpha
					),
					' ',
					item,
					container
);

If I check the phrase get hammer from bucket it matches rule one, because after you remove all the spaces from the string it's just one long word! This is an unexpected result, and even if I check rule two before rule one I only match rule one!

And now I'm really lost. I imagine there's a better way to do this, but I can't seem to figure it out. Also, since my allergies are going crazy, I've got to take the night off anyway. Anybody out there know of a solution?

For example, in Spirit classic, I had this rule to handle the most complex rule for my get command. In this case, it handles a command like get 20 items 2 from container 3:

rule6 = int_p[assign_a(mNumberToGet)] >> ' ' >>
			(+alpha_p)[assign_a(mItemToFind)] >> ' ' >>
			int_p[assign_a(mItemNumber)] >> ' ' >>
			str_p("from") >> ' ' >>
			(+alpha_p)[assign_a(mContainerToLookIn)] >> ' ' >>
			int_p[assign_a(mContainerNumber)];

which could be tested by the following code: if(parse(str.c_str(), rule6).full)

Here is the equivalent code in Spirit 2

	std::string::iterator first = str.begin();

	bool r = qi::parse(first, str.end(),
					(
						qi::int_ >> ' '
						>> +(~qi::char_(' ')) >> ' '
						>> qi::int_ 	>> ' '
						>> qi::lit("from") >> ' '
						>> +(~qi::char_(' ')) >> ' '
						>> qi::int_
					),
					mNumberToGet,
					mItemToFind,
					mItemNumber,
					mContainerToLookIn,
					mContainerNumber
	);

	if(r && first == command.end()) {
		return true;
	}

In many ways, the new Spirit 2 library is better, and purports to be much faster as well. The parse function has certainly been made somewhat more convenient. Overall, I'd rather not have had to spend time on this, but the only other option is to lock in with an old version of Boost that may hamper me in the future.

It wasn't terribly complicated, but was subject to constant interruption and upheaval while other projects came along. (FYI in case you don't know, my work requires a great deal of multi-tasking).

My code is compiling fine now, and should be fairly complete. Some more walk-throughs today and testing tomorrow, and it'll be off my shoulders completely. Until testing finds a bug, anyway. And I'll finally be able to say "I've finished it" at my weekly status meeting.

boost::shared_ptr<MySQL_Server> server = boost::shared_ptr<MySQL_Server>(new MySQL_Server("localhost", "user", "password", "database"));

boost::shared_ptr<Query> = boost::shared_ptr<Query>(new Query(server));

query->setQuery("UPDATE table SET var=val");

if(query->execute()) {
  std::cout << query->getNumberOfAffectedRows();
} else {
  std::cout << query->getError();
}

SELECT query results can be stepped through with the following:

for(unsigned int i=0; i < query->getNumberOfResultRows(); ++i) {
  std::vector<std::string> row = query->getNextRow();
  ...
}

I think I'm going to like this new class a lot more than the old one!

Given:

class Room {
  typedef boost::shared_ptr<Room> RoomPointer;
  typedef std::map<std::string, RoomPointer> RoomList;
 ...
}

And in another object, reference it like this:

RoomList mRoomList;
if((Room::RoomList::iterator it = mRoomList.find("name")) != mRoomList.end()) {
   return it->second;
}

I always get error: ‘::iterator’ has not been declared back from the compiler.

If I do this, it works fine:

Room::RoomList::iterator it = mRoomList.find("name");
if(it != mRoomList.end()) {
   return it->second;
}

I ask because Nicolai Josuttis (in The C++ Standard Library) recommends comparing the iterator against the end() condition on the same line because of type conversion of various unsigned types that may be used.

Forget all that old-school variable argument C-style code with the ellipsis(…), boost::format is where it's at!

I thought it quite profound that the error about not finding the function prototype happened on line 404.

FTW!

Turns out I changed the header file but forgot to make it an unsigned int in the cpp file.

Well, with all the Qt I've been writing lately, I thought I'd move it into their API. I have to admit, Qt makes it easy to incorporate OpenGL into your program. Texture loading was really easy, once I realized I forgot to add a call to glEnable(GL_TEXTURE_2D);.

Anyway, tonight I gimped up a quick image to map on to the cube. Here is the result:

The problem was I'm drawing a pie chart and needed to find when the mouse was inside any one of the wedges.

So here's how you find whether a mouse click was inside a wedge of a pie chart:

Given that the circle is inscribed in a bounding box 200x200 pixels and a mouse click happened at (130,50), here's how you check it:

First, check the distance from the center of the circle to the click coordinates. If this distance is greater than the radius of the circle, you need not go any further. This part was easy and I remembered it from high school.

The center of the circle lies at (100, 100). The distance of the click at (130, 50) is:
sqrt((130-100)^2 + (50-100)^2), or the square root of the square of the difference between the x-coordinates plus the square of the difference between the y-coordinates. If this value is greater than 100 (the radius of our circle), the click is outside the circle and no more math is required.

Next comes the tricky part. If the click was inside the circle, you need to find the angle of the click. In the diagram, you should know angles a, b, c, and d because you already drew them. Depending on your API, you may have them in degrees, or sixteenths of degrees like I did.

So you start by normalizing the x and y coordinates. This means translate it to (0, 0), or more simply subtract the x and y value of the center from the x and y value of the click. In my case this means my translated-x (tx) and translated-y (ty) are (30, -50) (130-100 and 50-100).

The tangent of the angle θ is the opposite over the adjacent side, which are your translated x and y coordinates. To find the angle you need to use tan-1 ty / tx, or atan(ty/tx) if you include cmath. This result is in radians. Make sure tx is non-zero or you will have some problems here.

This part is important! If tx was negative, you must add π to the radians to make sure you get the angle into the negative-x side of the graph! If you don't do this you'll have even more problems.

To convert θ to degrees, multiply the radians by 180 / π.

In my API (I'm using Qt), the degrees go in the opposite direction, so I had to invert the angle.

Compare this result to angles a-d and you have your wedge!