5 posts tagged with "c++"

I've recently been working with Performance Co-Pilot (PCP) - specifically, creating some PCP add-ons (known as PMDAs) for exposing custom application metrics to PCP.

While doing so, it became pretty clear to me, that although PCP's PMDA C API is very efficient, a good quality C++ wrapper could significantly cut PMDA development and maintenance time (for people like me, at least), while also increasing runtime safety by building-in all of the checks and balances that most PMDAs (should) perform, in a generic reusable manner.

This sounded like a bit of fun, and suited my present hunger for some more advanced C++ API design work, so went about implementing such a library.

Now, there are no official binary PIAs for Exchange Server 2000 / 2003. However, Microsoft does provide such PIAs in "source" form (not really source code as such... but we'll get to that) that you can download and compile yourself. There is an MSDN article that explains how to use the Exchange Server PIA wrappers, however I strongly recommend you download the code and read the included "Writing Managed Sinks for SMTP and Transport Events.doc" file instead - it is far more up to date than the MSDN article in areas that are quite significant (such as the actual build process).

I've been experimenting with QtSvgDialGauge in a personal project, and so far, I like it a lot! :)

For those who don't know, QtSvgDialGauge is nice SVG-based dial/gauge widget, which is part of the Qt Embedded Widget demos. You can see it (and several other embedded widgets) in action in the Qt Embedded Widgets Catalog and Qt Patient Care Demo applications. And you can download the source for both applications here.

With most non-trivial Qt projects that I create, I like to include a pre-pre-build command in the qmake project file. I'll explain why as we go, but first off, let's look at what I mean by "pre-pre-build" (it is not at all a standard term).

The typical build process (as performed by make looks something like this:

1. For the given target, check if any of the target's dependencies have been updated since it was last (re)built.
   1. If no dependencies have changed, do nothing - we're done ;)
   2. If one or more dependencies have changed, then:
      1. Build each dependent target.
      2. Build this target.
      3. If appropriate, link this target with its dependencies.

That is, of course, a gross oversimplification... but it will do the purpose of this post.

I had a strange problem recently... occasionally, one of my FastCGI programs would go into a near-infinite loop (actually, just looping approximately 18 x 10¹⁸ or 18 billion billion times!!). It was easy to trace the problem back to an fwrite() call returning ULONG_MAX (18446744073709551615 on this particular 64-bit server).