Coding Castles

Automated Image Editing for the Artistically Unskilled

2010-01-28T18:38:00.000-08:00

GIMP is perhaps the poster child for bad open source usability. This may not be entirely fair; the UI is better than it used to be, and GIMP now has excellent docs, so a minute with Google will teach you how to do anything that the UI fails to make clear.

As a software developer, I firmly believe that anything worth doing more than once is worth automating, but scripting was one part of GIMP that remained opaque to me. GIMP's built-in scripting language, Scheme, is one that's unfamiliar to many programmers. And although GIMP extensions offer scripting support for Perl and Python, I've always had inordinate trouble getting those to work. (The Linux distros I've used often omit Perl support, for example, and getting GIMP's Python support to work on Windows requires manually installing several supporting Python libraries, of the correct versions, without any diagnostics if you get any of it wrong, and ideally without messing up existing installations of your Python libraries. YMMV.) I finally decided that all of this futzing with scripting extensions would be harder than just learning Scheme and that I should bite the bullet and learn to script GIMP natively. (Besides, I'm told that learning Scheme or Common Lisp will induce a "profound enlightenment experience", so it must be worth doing, right?)

Learning to Script

GIMP has extensive online documentation and tutorials. Its Batch Mode tutorial includes some scripting examples. There's even a Script-Fu Tutorial that provides a brief introduction to Scheme, for those of us who haven't yet worked our way through SICP.
GIMP also has a built-in Procedure Browser (under the Help menu) for looking up the GIMP-specific functions that you'll use in your Script-Fu scripts. This will be your primary reference after the above tutorials take care of the basics.

Unfortunately, none of the above references have much information on how to do non-image-processing tasks (such as making up filenames for your images) in Script-Fu. For that, you'll need one of the following sources:

GIMP uses TinyScheme as its scripting language. (Older versions of GIMP used SIOD, and there are still a few references to this on the web. Interestingly, GIMP doesn't use GUILE, even though GIMP and Guile are both GNU projects and Guile is the GNU Scheme interpreter.)
TinyScheme follows R5RS (the almost-current Scheme standard). Standard and builtin functions are documented in R5RS. Script-Fu extensions to TinyScheme are documented on the Tiny-Fu Wiki.

Running Your Script

The official GIMP documentation would have you place your script in a GIMP configuration directory, register it, and invoke it from the command line. This is unnecessarily complicated. Redirection from the command line is much simpler:

"c:\Program Files\GIMP-2.0\bin\gimp-console-2.6.exe" -c -b - < gimp-create-disabled-icons.scm

Ignore any wire errors that GIMP outputs at this point; those are harmless issues between GIMP and its various plugins and have nothing to do with your script.

Debugging Your Script

Error reporting from console batch mode is apparently nonexistent. This, combined with GIMP's slow startup times, makes debugging a frustrating experience. One approach is the tried-and-true debugging-via-printf approach using the gimp-message function ((gimp-message "Okay, I made it to line 5\n")).

A better approach is to use the Script-Fu console. To do so, go under the Filters menu, under Script-Fu, and choose Console. Then start typing in commands from your candidate script and seeing how they work out.

If you've poked around in the Procedure Browser at all, you've noticed a lot of procedures that take parameters of type IMAGE, LAYER, DRAWABLE, and so on. These are simply integers (presumably indexes into GIMP's data structures), so trying out these procedures is relatively easy. Consider the following Script-Fu Console session. (My commands are marked with > and comments are marked with > ;.)

> (gimp-image-list)
(1 #( 2 ))
> ; This tells me I have one image loaded, and its number is two.
> (gimp-image-get layers 2)
(1 #( 4 ))
> ; This tells me Image 2 has one layer, and its number is 4.
> ; Each LAYER is also a DRAWABLE, so I can test out whatever commands
> ; I want to now.
> (gimp-drawable-fill 4 WHITE-FILL)
(#t)
> ; (#t) means this command has no particular return value.

Most procedures executed in the Script-Fu console are entered into undo history just like GUI operations, so it's easy to clean up after mistakes.

Additional Resources

The GIMP Plugin Registry has plenty of example code. (Keep in mind that GIMP scripts are probably not the best source for learning good Scheme programming style.)
Samuel A. Rebelsky and Ian Bone-Rundle have put together the "Glimmer Utilities for Gimp". Their float-array procedure is useful for Script-Fu procedures that take a FLOATARRAY parameter.

Putting It into Practice

Automating the creation of the various icon sizes required by Windows Vista and newer is a good idea. The iconify.scm script is an example of this.

Creating proper disabled icons for your desktop application can enhance its look. (The OpenOffice web site has good examples of what disabled icons should look like.) Automating the creation of disabled icons in GIMP involves converting the icon to monochrome then adjusting its shading and/or opacity to your liking.

Open Source License Compliance

2009-12-15T18:45:00.000-08:00

Complying with license agreements for closed source software libraries is pretty straightforward. You pay your money, and sometimes it's a lot of money, and sometimes you have to go through the odious "talk with the salesperson before you even find out how much money it is." Eventually, in spite of these obstacles, you get your requested number of licenses, and as long as you don't exceed that count, and as long as you don't do something stupid like post the licensed source code to your company web site, you're fine. The vendor doesn't usually care about how you attribute their work or whether you statically or dynamically link their code or how you patch it to meet your needs (if they provide source) or what other libraries you're using.

Complying with license agreements for open source software libraries can be significantly more complicated. While a lot has been written about the pros and cons of various open source licenses, their compatibility, their proliferation, and so on, there's relatively little guidance on how to comply, in practical terms, with the licenses of libraries that you use in software development. (Kudos to the Create Commons group for their efforts to make licensing so easy to understand; however, most of their effort focuses on cultural works and not software.) Much of what does cover license compliance focuses heavily on the corporate legal / risk management perspective, such as this article by Bruce Perens:

The law team... has to operate differently than they're used to. They have to be conscious that engineers are scored on meeting a timeline, and can't stop development while they're waiting for an answer from legal. Thus, legal has to be able to take on-impulse calls from engineering, and answer them in a timely fashion.

That's too expensive!, say the lawyers and managers. But it's part of the cost of doing business today. When I learned electronics, engineers built products by soldering together resistors and transistors. But today, the job of engineers is to build derivative works by combining units of intellectual property owned by third parties. That's not what they're trained for, and it's a mine-field of potential litigation for every company that puts software in its products - whether or not that software includes Open Source. Without an effective partnership between legal and engineering, your company walks that mine-field every day.

And while Bruce Perens obviously has a lot of experience in this area, I'm not convinced that it has to be this complicated for the average ISV or in-house developer who's using open source components in his day-to-day work. In a small attempt to reduce the complexity, here's a brief list of the most popular open source licenses, along with what it takes, in practical and oversimplified terms, to comply with each license in developing a closed source application. Of course, since I am not a lawyer and do not speak for my employer, this posting should in no way be construed as legal advice and is in fact quite possibly not worth the metaphorical paper it's printed on. (And metaphorical paper isn't worth much these days.) With that disclaimer out of the way, here's what you need to do:

Regardless of the license, avoid claiming that the entire software application is © You.
If you're shipping code under the Boost Software License: You have no additional obligations (as long as you're only shipping binaries).
If you're shipping code under a BSD-ish, MIT, or X11 license: Include a copy of the code's copyright notice and license.
If you're shipping GPL'ed code (version 2 and version 3): Don't, unless it's a standalone executable and you're merely bundling your app with it.
If you're shipping LGPL'ed code (version 2.1 and version 3): Make sure that you link dynamically rather than statically to the LGPL'ed code. (So in Windows, make sure that you use it as a DLL.) A few LPGL'ed libraries have specific exceptions for static linking under Windows, and if the dynamic linking requirement is particularly burdensome, there are possible workarounds. Also, the LGPL may require that you permit reverse engineering of your application for purposes of compatibility with future versions of the LGPL'ed code; see the full text of the LGPL or consult a lawyer for details.
Extra requirements if you're shipping GPL'ed or LGPL'ed code:
1. Include attribution of the code's origin and its license, and include a copy of the license.
2. Your physical media must either include a copy of the GPL'ed / LGPL'ed source or must be accompanied by a written offer to make the source available.
3. If you distribute your application online, then you must make the source code available from the same download site to whoever can download your application.
4. If you distribute your application online, and if either the GPL'ed or LGPL'ed code is released under version 3 of the GPL or it's released under an earlier version of those licenses with permission to use "(at your option) any later version" of those licenses, then instead of making the source code available yourself, you may provide a link to an upstream server hosting the code. (I find it easier to do #3 than to worry if #4's requirements are met.)
If you're shipping MPL'ed code: Include attribution of the source code and its license. Include information on where to find the source code.
If you're shipping code under the Apache Software License: Include attribution and a copy of the license.
If you're shipping code under the Eclipse Public License: Include attribution and a copy of the license. Include information on where to find the source code. Additionally, you are obligated to release your source code if it constitutes a derivative work of the EPL'ed software. There are no cut-and-dried criteria for what constitutes a derivative work by the EPL; see the EPL FAQ items 25, 26, and 27 for details.
If you're shipping GPL'ed, LGPL'ed, or MPL'ed code that you have modified: You must distribute a prominent description of your modifications (as part of the GPL'ed or LGPL'ed source distribution, and even if you wouldn't otherwise have to distribute MPL'ed source). Check the license for exact details regarding what form this description should take.
If you're using GPL'ed, LGPL'ed, MPL'ed, BSD-ish, MIT, X11, Apache, EPL, or Boost code for internal applications only: All of this is vastly simplified, since licenses like the GPL explicitly do not place any restrictions on internal use, and since many of these licenses' clauses apply only to those to whom the software is distribute. For example, you could likely use a GPL'ed unit test library with closed source software, since the unit tests are only distributed to developers who already have the source.
If you're using GPL'ed, LGPL'ed, MPL'ed, BSD-ish, MIT, X11, Apache, EPL, or Boost code to develop a web site: Again, all of this becomes vastly simplified, since the web site's code is only "distributed" to the web server. Only one or two licenses (like the Affero GPL) have special requirements for web sites.
If software patents are involved: Reread the licenses and ask a lawyer.

Quite a few of these license have some variation on attributing and including a copy of the license. Figuring out the exact attribution format required by each license can be tricky; a handy solution is to see how companies like Google, Sun, and VMware handle it, since their legal departments are much larger than most organizations'.

OpenOffice.org includes the following clause in its EULA: "Third Party Code. Additional copyright notices and license terms applicable to portions of the Software are set forth in the THIRDPARTYLICENSEREADME.html file." Within the third part license readme file, each library gets its own section with wording similar to the following:
The following software may be included in this product:William's Wonderful Widgets; Use of any of this software is governed by the terms of the license below:
Copies of the LGPL and GPL are included at the end.
Google Chrome includes a notice in its Help > About screen: "Google Chrome is made possible by the Chromium open source project and other open source software." "Open source software" here is a link bringing up a credits page that lists each component, its homepage, and its license.
VMware devotes a section of their web site to collecting all of their open source licenses and source code and includes a link to this site in their EULA. Installation directories also include license lists similar to OpenOffice.org's.

Update (12/17/2009):

A few extra resources regarding open source license compliance:

The Software Freedom Law Center has written "A Practical Guide to GPL Compliance,", thoroughly covering GPL (and LGPL) compliance.
The FOSSology open source project can help track the licenses of software components you're using.
In the commercial sector, Black Duck Software can do the same. Black Duck also collects various statistics on open source projects.

The timing of this post occurring shortly after news of a major GPL-related lawsuit was completely accidental.

Standard C++

2009-06-07T20:15:00.000-07:00

I have vague recollections of trying to track down a copy of the C++ standard several years ago. I went to the ISO's web site, went into sticker shock at the several hundred dollars they wanted for a CD or PDF, and soon forgot about it.

Until I came across this discussion on Stack Overflow, I didn't realize that the C++ standard was so easy to acquire. PDF versions are available for $30 from ANSI's web site and from Techstreet. If even $30 is too much, or if you want to read about cutting-edge C++ stuff, then you can download the C++0x draft standard from the ISO committee's web site for free, with the caveat that it is "incomplet and incorrekt." Copies of the C++98 and/or C++03 draft standards are also archived in various places around the web.

With the wealth of C++ information available on the web and in print, there are often more convenient resources than the standard, but topics such as the order in which integral types are promoted seem difficult to come by on the web, and for particularly arcane issues of C++ style, it's nice to have a more disciplined approach than "munging syntax until it works" and a more authoritative source than "whatever my compiler accepts." The C++ standard acts as a grammar textbook for the C++ language, and although the standard isn't exactly thrilling reading, its dialect of standardese isn't nearly as difficult to read as you might think.

Linguists will tell you that a natural language's grammar is descriptive, not prescriptive. In other words, English grammar isn't the list of rules that you find in a high school textbook, it's a description of how people actually talk and write, complete with colloquialisms, various "ungrammatical" speech, and, in the 21st century, emoticons and online acronyms. There's some merit to taking a similar approach with programming languages. Using a programming language effectively requires more than just knowing the language's formal constructs; it involves using the language's community's idioms (using and combining constructs to get things done, as in C++'s RAII) and taboos (aspects of the language that are too obscure or problematic to rely upon, like C++'s exception specifications or the relative precedence of || and &&). Moreover, what ultimately matters is how a language can be used in the field rather than how the standard says a language can be used; it's a small comfort to read that your template metaprogramming technique or C99 construct is permitted by the standard if your target platform rejects it.

The rules of grammar (in the prescriptive high school sense rather than the descriptive linguistic sense) are generally worth following, to promote clarity of communication, but skilled writers know that it's sometimes effective to break these rules, whether to create a particular effect (such as a conversational, informal tone) or because the rules are outdated or never made much sense in the first place (such as the prohibition against split infinitives). Similarly, there are times where it may be beneficial to break the C++ standard. Imperfect C++ gives two examples of this (with caveats as to their use): the "friendly template" technique (declaring a template parameter to be a friend of the template class; technically illegal but very widely supported) and nested or local functors (potentially very useful but rejected by almost all compilers). C99 features such as variable length arrays (supported by GCC) and variadic macros also fall in this category. Obviously, breaking the standard should only be done with full awareness of the consequences (primarily damage to future portability) and is usually a bad idea, but not always. For example, code using variadic macros completely violates the C++ standard, but it's likely much more portable than some of the more advanced uses of templates.

C++ might deserve mention for even having a (well-discussed, reasonably well-implemented) standard. Perl, for example, lacks any official standard; instead, its implementation and test suite serve as the de facto standard, and the need to remedy this may be part of the reason for Perl 6's delays. JavaScript has an international standard and yet continues to suffer from browser compatibility issues, not just in the DOM and event models, but in the language core:

var cmd, valve;
// Perl- or Python-style assignment to an array: legal in Firefox, but 
// rejected by Chrome
[ , cmd, valve ] = /(\w+)_valve_(\d+)/.exec(this.id);

// A C-style trailing comma in an initializer list: creates an array 
// of length 3 in Firefox, but IE creates an array of length 4 with 
// undefined as its last element
var fields = [ 'street', 'city', 'zip', ]

Fred Brooks has more to say about the risks of using an implementation as a standard in chapter 6 of The Mythical Man-Month, but by this point we're pretty far afield of the C++ standard. So, if you're a C++ developer, go download or buy yourself a copy and give it a look.

Comparing Version Numbers

2009-05-17T11:18:00.000-07:00

Comparing version numbers is one of those operations that seems like it ought to be simple but can have a fair bit of complexity under the surface. How would you write an algorithm that gives the correct result for all of the following?

2.10 comes after 2.9
2.11-beta comes after 2.11-alpha
2.11 comes after 2.11-beta
7 comes after 2003
the revision that was checked in on 1/30/2009 and never given a version number comes after the revision that was checked in on 8/1/2008 and never given a version number

The Debian Project deals with more version numbers than anyone - over 30,000 packages over more than fifteen years, each of which must be separately versioned and tracked for upgrade and depedency purposes - so it's no surprise that they've developed a policy and algorithm that can handle all of the above cases. Debian's algorithm neatly handles cases like 2.9 versus 2.10, and it has two main additions over other version comparison algorithms: it states that ~ is sorted before anything, even the empty string, so 2.11~beta comes before 2.11, and it permits the addition of an epoch to "reset" version numbers, so 2003, which has the default epoch of 0, comes before 1:7, which has an epoch of 1. All of this makes Debian's algorithm a good approach for comparing version numbers even if you're not a Debian package maintainer.

I recently needed to compare some Debian version numbers, but the only C or C++ implementations of this algorithm that I could find were GPL'ed, and my target environment wouldn't permit me to simply shell out to dpkg --compare-versions, so I wrote my own implementation. Here it is, under the public domain. Note that, although it's written as a C++ class, the method bodies are in C style to make it easier to reuse them in a non-C++ project.

DebVersion.h:

#ifndef DEBVERSIONH
#define DEBVERSIONH

#include <stdlib.h>
#include <iostream>
#include <boost/operators.hpp>

class DebVersion : public boost::totally_ordered<DebVersion> {
public:
  DebVersion() : mEpoch(0), mUpstream(NULL), mRevision(NULL) {}
  DebVersion(const DebVersion& other) { *this = other; }
  explicit DebVersion(const char *version);
  ~DebVersion();

  int Epoch() const { return mEpoch; }
  const char *Upstream() const { return mUpstream; }
  const char *Revision() const { return mRevision; }

  void Epoch(int new_epoch) { mEpoch = new_epoch; }
  void Upstream(const char *new_upstream) { free(mUpstream); mUpstream = strdup(new_upstream); }
  void Revision(const char *new_revision) { free(mRevision); mRevision = strdup(new_revision); }
  void ClearRevision() { Revision("0"); }

  DebVersion& operator=(const DebVersion& other);
  bool operator<(const DebVersion& other) const;
  bool operator==(const DebVersion& other) const;

protected:
  int mEpoch;
  char *mUpstream;
  char *mRevision;

  static int CompareComponent(const char *a, const char *b);
};

inline DebVersion::~DebVersion()
{
  free(mUpstream);
  free(mRevision);
}

inline bool DebVersion::operator==(const DebVersion& other) const
{
  return Epoch() == other.Epoch()
    && strcmp(Upstream(), other.Upstream()) == 0
    && strcmp(Revision(), other.Revision()) == 0;
}

inline DebVersion& DebVersion::operator=(const DebVersion& other)
{
  mEpoch = other.Epoch();
  mUpstream = strdup(other.Upstream());
  mRevision = strdup(other.Revision());
  return *this;
}

void operator<<(std::ostream& o, const DebVersion& ver);

#endif

DebVersion.cpp:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <ctype.h>

#include "DebVersion.h"

void operator<<(std::ostream& o, const DebVersion& ver)
{
  if (ver.Epoch() != 0) {
    o << ver.Epoch() << ":";
  }
  o << ver.Upstream();
  if (0 != strcmp(ver.Revision(), "0")) {
    o << "-" << ver.Revision();
  }
}

DebVersion::DebVersion(const char *version)
{
  // Extract epoch.  The Debian Policy Manual says that epoch must be
  // numeric, so atoi is safe.
  const char *epoch_end = strchr(version, ':');
  if (epoch_end != NULL) {
    mEpoch = atoi(version);
  } else {
    mEpoch = 0;
  }

  const char *upstream_start;
  if (epoch_end) {
    upstream_start = epoch_end + 1;
  } else {
    upstream_start = version;
  }

  const char *upstream_end = strrchr(upstream_start, '-');
  size_t upstream_size;
  if (upstream_end == NULL) {
    upstream_size = strlen(upstream_start);
  } else {
    upstream_size = upstream_end - upstream_start;
  }

  mUpstream = (char*) malloc(upstream_size + 1);
  strncpy(mUpstream, upstream_start, upstream_size);
  mUpstream[upstream_size] = '\0';

  if (upstream_end == NULL) {
    mRevision = strdup("0");
  } else {
    mRevision = strdup(upstream_end + 1);
  }
}

/**Compare two components of a Debian-style version.  Return -1, 0, or 1
 * if a is less than, equal to, or greater than b, respectively.
 */
int DebVersion::CompareComponent(const char *a, const char *b)
{
  while (*a && *b) {

    while (*a && *b && !isdigit(*a) && !isdigit(*b)) {
      if (*a != *b) {
        if (*a == '~') return -1;
        if (*b == '~') return 1;
        return *a < *b ? -1 : 1;
      }
      a++;
      b++;
    }
    if (*a && *b && (!isdigit(*a) || !isdigit(*b))) {
      if (*a == '~') return -1;
      if (*b == '~') return 1;
      return isdigit(*a) ? -1 : 1;
    }

    char *next_a, *next_b;
    long int num_a = strtol(a, &next_a, 10);
    long int num_b = strtol(b, &next_b, 10);
    if (num_a != num_b) {
      return num_a < num_b ? -1 : 1;
    }
    a = next_a;
    b = next_b;

  }
  if (!*a && !*b) {
    return 0;
  } else if (*a) {
    return *a == '~' ? -1 : 1;
  } else {
    return *b == '~' ? 1 : -1;
  }
}

bool DebVersion::operator<(const DebVersion& other) const
{
  if (Epoch() != other.Epoch()) {
    return Epoch() < other.Epoch();
  }

  int result = CompareComponent(Upstream(), other.Upstream());
  if (result) {
    return -1 == result;
  }

  return -1 == CompareComponent(Revision(), other.Revision());
}

And, because no code is complete without some good unit tests, here's DebVersionTest.cpp, using the excellent Google Test framework:

#include <gtest/gtest.h>

#include "DebVersion.h"

TEST(DebVersionTest, ParsesUpstreamOnly)
{
  DebVersion v("1");
  EXPECT_EQ(0, v.Epoch());
  EXPECT_STREQ("1", v.Upstream());
  EXPECT_STREQ("0", v.Revision());
}

TEST(DebVersionTest, ParsesEpochs)
{
  DebVersion v("1:2.0.1");
  EXPECT_EQ(1, v.Epoch());
  EXPECT_STREQ("2.0.1", v.Upstream());
  EXPECT_STREQ("0", v.Revision());
}

TEST(DebVersionTest, ParsesRevisions)
{
  DebVersion v("10:4.0.1~alpha-4-5");
  EXPECT_EQ(10, v.Epoch());
  EXPECT_STREQ("4.0.1~alpha-4", v.Upstream());
  EXPECT_STREQ("5", v.Revision());
}

TEST(DebVersionTest, ComparesNumbers)
{
  EXPECT_LT(DebVersion("1"), DebVersion("2"));
  EXPECT_EQ(DebVersion("10"), DebVersion("10"));
  EXPECT_LT(DebVersion("9"), DebVersion("10"));
  EXPECT_GT(DebVersion("10"), DebVersion("9"));
}

TEST(DebVersionTest, ComparesEpochs)
{
  EXPECT_GT(DebVersion("2:1"), DebVersion("1:2"));
  EXPECT_LT(DebVersion("10"), DebVersion("1:2"));
}

TEST(DebVersionTest, ComparesAlphas)
{
  EXPECT_LT(DebVersion("alpha"), DebVersion("beta"));
  EXPECT_LT(DebVersion("alpha1"), DebVersion("alpha2"));
  EXPECT_GT(DebVersion("alpha10"), DebVersion("alpha2"));
}

TEST(DebVersionTest, ComparesTildes)
{
  EXPECT_LT(DebVersion("3.0~beta1"), DebVersion("3.0"));
  EXPECT_GT(DebVersion("3.0~beta"), DebVersion("3.0~~prebeta"));
  EXPECT_LT(DebVersion("3.0~beta4"), DebVersion("3.0~rc1"));
}

TEST(DebVersionTest, ComparesRevisions)
{
  EXPECT_LT(DebVersion("3.0-2"), DebVersion("3.0-10"));
}

Minding Your Manners

2009-05-11T19:20:00.000-07:00

I recently went to a book sale where shoppers could browse countless bins of completely disorganized books and buy as many as could fit in a box for $30. I quickly learned that the only way to navigate a sale like this was to disregard my traditional short list of topics and authors that I follow, grab anything remotely interesting, and sort it out later. One of my finds was New Rules @ Work, by Barbara Pachter and Ellen Coleman.

The book's subtitle sums up its contents: "79 Etiquette Tips, Tools, and Techniques to Get Ahead and Stay Ahead." It covers topics such as greeting people, navigating social gatherings, corporate attire, and communications skills (whether face-to-face or by phone or email). For me, at least, the tips presented are an odd mix of the very obvious (stand up when shaking a guest's hand), the rather irrelevant (how to sample wine at restaurants fancier than my humble software developer's expense account would cover), and the desperately needed (how to mingle at a social gathering). Even though many of the suggestions fell in the first category for me, the book is a quick read and is interspersed with plenty of amusing anecdotes about various etiquette blunders to keep it interesting.

All of this has little to do with coding, but there's a lot more to software development than just coding:

gathering requirements
managing the infrastructure (version control, build system, continuous integration)
documentation (developer docs if not end-user docs)
testing
release management and deployment
customer support (possibly indirectly, depending on the size of your organization)

And there's a lot more to a career in software development than just software development:

teamwork
networking (the social kind, not the TCP/IP kind)
time management (Getting Things Done if you like an overarching system, Time Management for System Administrators or Johanna Rothman's articles if you prefer individual pieces of advice)
stress management (avoid burnout; remember that your job is just a job; take a vacation and don't check your email)
continuing education
business acumen

And, of course, workplace etiquette. New Rules @ Work emphasizes the effects that etiquette (or the lack thereof) can have on your career, and it seems to present etiquette primarily as a tool for advancing your career. Considering the book's focus, this is probably okay, but it seems a bit utilitarian to me. I've always preferred Brendan Frasier's character's explanation in the movie Blast from the Past:

Good manners are just a way of showing other people we have respect for them... A lady or a gentleman is someone who always tries to make sure the people around him or her are as comfortable as possible.

Etiquette is a way to serve others.

As software developers, it can be our tendency to focus too much on the technology. We want to try out the latest development tools or techniques even if they're not best for the job; we pursue certain standards or ideals even if they don't make business sense; we see a technical challenge and try to solve it even if it's not the right problem to solve. As a remedy to this, we're told to focus on delivering business value. This is good advice, but it raises the question, why pursue business value? The standard answer is "profits," but as Max De Pree says, "Profits are like breathing. Breathing is not the goal of life, but it is pretty good evidence of whether or not you are alive." The goal of business - the reason that business can exist, the way that business makes profits - is service: meeting people's needs by offering goods or services.

There's a story that, during the initial development of the Apple Macintosh, Steve Jobs complained that it booted too slowly. He argued that shaving ten seconds off of the boot time, multiplied by millions of users, would save several lifetimes. My software may never save a lifetime, but every feature that I add, every bug that I fix, every UI interaction that I streamline means that users can do their jobs a bit faster, a bit easier, with a bit less stress.

Software development is about serving users. Etiquette is just a way to do in the small what our businesses and our careers do in the large.

Memberwise Visitation

2009-05-03T13:16:00.000-07:00

This code was the original impetus for my postings on template template parameters and multi-paradigm programming, but those didactic digressions grew into articles of their own. I don't know how helpful such digressions are - I'm learning that truly effective teaching requires the patience to develop good examples and an awareness of where your target audience is, and I'm not sure that I possess either, at least in this format - but at least they're out of the way...

C++'s object-oriented and generic programming each offer a lot of capability, but they can be combined for even more power. Consider, for example, the following code:

#include <iostream>
#include <boost/ptr_container/ptr_vector.hpp>
#include <boost/shared_ptr.hpp>

template <typename Class>
class ClassVisitor {
public:

  class MemberVisitor {
  public:
    virtual ~MemberVisitor() {}
    virtual void Visit(Class& instance) = 0;
  };

  template <typename T>
  class MemberVisitorImpl : public MemberVisitor {
  public:
    MemberVisitorImpl(T Class::*ptr) : mMember(ptr) {}
    void Visit(Class& instance) {
      // Sample visitor method.  You can define whatever member-specific
      // behavior you want.
      std::cout << instance.*mMember << ' ';
    }
  private:
    T Class::*mMember;
  };

  template <typename T>
  ClassVisitor& Declare(T Class::*ptr);

  void Visit(Class& instance);

private:
  typedef boost::ptr_vector<MemberVisitor> MemberVisitorList;
  MemberVisitorList mMemberVisitors;
};

template <typename Class>
template <typename T>
ClassVisitor<Class>& ClassVisitor<Class>::Declare(T Class::*ptr)
{
  mMemberVisitors.push_back(new MemberVisitorImpl<T>(ptr));
  return *this; // supports a fluent interface
}

template <typename Class>
void ClassVisitor<Class>::Visit(Class& instance)
{
  for (typename MemberVisitorList::iterator i = mMemberVisitors.begin();
       i != mMemberVisitors.end();
       i++) {
    i->Visit(instance);
  }
}

struct Annotation {
  const char *mMessage;
  int mX;
  int mY;
};

int main(int argc, char *argv[])
{
  ClassVisitor<Annotation> def;
  def.Declare(&Annotation::Message)
    .Declare(&Annotation::X)
 .Declare(&Annotation::Y);

  Annotation annotation;
  annotation.Message = "Note this";
  annotation.X = 10;
  annotation.Y = 20;
  def.Visit(annotation);
  return 0;
}

This code offers one approach to visiting each member of a class with a client-specified operation. Generic programming is used MemberVisitor subclasses handle members of any type, while OOP's polymorphism is used to let different types be handled at runtime. (Normally templates can only be applied at compile-tyime.) The example code simply dumps member variables' contents to screen and ends up being merely an overcomplicated operator<<(std::ostream&, const Annotation&), but MemberVisitor instances can contain additional information about their member variables and can define more than one Visit operation. In my current code's memberwise visitor implementation:

MemberVisitor instances contain member variables' descriptions, defaults, and constraints (minimum, maximum, etc.).
Copy constructors, operator=, and default constructors can be implemented by iterating over the list of member variables and default values that the MemberVisitor list provides.
MemberVisitors' information is shared by visit operations: per-member serialization and unserialization use members' types and formats, constraints are used during unserialization to check for corrupt archives and at runtime to check design by contract-style invariants, member descriptions and defaults can be used to report errors and reset to a known good state if a corrupt archive is encountered during deserialization, and the class can easily be dumped one member at a time to a human-readable format for inspection and debugging.
A second set of visitors handles binding members to a form's fields: loading form fields from a class instance, checking whether a form is dirty, validating a form, and saving form fields to a class instance are each implemented as Visit operations, and information such as MemberVisitor constraints can be used when a form is loaded to configure the UI widgets and before a form is saved to check for validity.

The result is that the MemberVisitors offer some introspection/reflection capability for C++ as well as something like a database schema for each class, similar to what would be provided by most frameworks' database support, but not tied in to a database backend. This multiparadigm (OO-and-generic) combination is only one approach to implementing this functionality; other implementations could use more of a pure template metaprogramming approach or could rely on preprocessor macros, code generation via an external tool, or reflection (via vendor extensions or a third-party library). Each implementation offers its own tradeoffs for complexity, portability (template metaprogramming often runs into compiler bugs; reflection is often vendor-specific), and build system support (in the case of code generation and reflection).

I'm still playing around with different approaches trying to find the best balance of tradeoffs and trying to figure out the best way to take advantage of C++'s multiparadigm support without overcomplicating my code. Are there other examples of code that directly leverages C++'s multiparadigm support? Are there preexisting implementations of this kind of member schema functionality for C++? Would there be any interest in a (cleaned up and open-sourced) member schema library, or is that functionality adequately covered by database libraries? Comments welcome.

A Plethora of Paradigms

2009-04-13T20:10:00.001-07:00

paradigm - a pretentious and overused term for a way of thinking (Bjarne Stroustrup, "C++ Glossary")

C++ is frequently described (by Stroustrup and others) as a multi-paradigm programming language, which simply means that it lets you use more than one programming paradigm (such as procedural or object-oriented) and freely switch between or combine paradigms. When I was first introduced to this concept of multi-paradigm programming languages, I thought that it was an incredibly cool trait of C++. Then I read on Wikipedia that the multi-paradigm label can be applied to many more languages than I'd realized and that C++ is a relative lightweight at only three paradigms. (The current record holder, supporting eight Wikipedian-recognized paradigms, is a language I've never heard of called Oz.) However, C++ is probably still the best known example of this sort - there are even ">books about it - and has some of the most practical multi-paradigm applications. A quick overview of C++'s paradigms:

First, of course, is the structural or procedural programming paradigm. Procedural programming's pretty passé, so there's not much to be said here, except to note that C++'s multi-paradigm nature lets you incrementally migrate a procedural app to an OO design.

Second is object-oriented programming. When OO first went mainstream, it was billed as a way of achieving reuse in software development. This doesn't seem to have quite worked out as advertised; creating truly reusable software is hard regardless of the technology you're using, and while OO design is critical to frameworks from MFC to RoR, framework development isn't where most programmers live. Even if its ability to grant reuse per se is limited, modern OO design is quite good at permitting software to be flexible, extensible, and stable in the face of change. "Modern OO design" means taking full advantage of guidelines like the SOLID principles and the Law of Demeter rather than just applying the basic OO techniques of encapsulation, inheritance, and polymorphism. It also includes knowing when to bend those guidelines if circumstances call for it.

C++'s third paradigm is generic programming. I find this to be harder to get a handle on... It's much less commonly taught than object-oriented programming, and although I've worked in C++ for years, it's only been in the last year or two that I've really started to "get" generic programming. (A good test to see how well you understand generic programming is to browse the Boost libraries and see how many of them you think you could, in theory, implement.) Generic programming makes the STL possible; it makes it possible to add features like dimensional analysis, lambda expressions, and callbacks to C++; it's a major component in adding user-defined types of all sorts. It also creates some rather heinous error messages...

However, generic programming isn't just for STL containers and the metaprogramming wizards at Boost; it overlaps with and can partially replace OO techniques. OO programming is known for permitting software components to be loosely coupled (such that they can be freely combined and freely changed, within limits, without the effects of those changes rippling out to other components), through polymorphism and interfaces. Generic programming also permits loose coupling, except that it's handled entirely at compile time, with no runtime overhead, and it doesn't require that objects be related through an inheritance hierarchy. The Curiously Recurring Template Pattern is probably the simplest and best known example of this (and is even referred to as compile-time or static polymorphism), but it's far from the only example. Most of part four, for example, of Imperfect C++ contains different applications of generic programming techniques to simulate what might require inheritance, interfaces, or (C#) extension methods in the OO world.

For even more power, the generic and OO paradigms can be combined. And because C++ is such a flexible language, you're not limited to the "officially supported" paradigms. I've already touched on Boost's support for functional programming; as another example, reflection (which is available through vendor extensions, like C++Builder's or the .NET Framework's and through third party libraries like CERN's Reflex) can also promote flexible, extensible software. Having three different techniques from three different paradigms that can be used individually or in various combinations offers incredible power: power to shoot yourself in the foot by creating an overcomplicated, obtuse rat's nest of code, or power to write robust, extensible software. Now if I could only figure out which category my code falls in...

Things I Didn't Know about C++: Template Template Parameters

2009-04-07T18:31:00.000-07:00

Continuing my series on things I didn't know about C++...

I knew about templates, and I knew about parameters to templates, but I did not know about template template parameters, which are useful when dealing with containers and policies and, if nothing else, are worth learning about for having such a "pleasingly repetitious name" (in C++ author Stephen Dewhurst's words).

A template template parameter is simply a template parameter that is itself a template. Dewhurst gives the example of a Stack template that can be customized to use a particular underlying storage container:

template <typename T, template <typename> class Cont>
class Stack;

Stack<int, List> stack_of_ints;

Without template template parameters, the base type (int in this case), which hampers readability at best and could be a source of errors at worst:

template <typename T, typename Cont>
class Stack;

Stack<int, List<int> > stack_of_ints;
Stack<double, List<int> > stack_of_doubles_badly_truncated_to_ints;

Template template parameters can be used anywhere you need to let the caller customize an algorithm or class for a particular container, policy, or similar:

A stack or other higher-level container can be instantiated using any lower-level container, as in Dewhurst's example.
A class or function can be customized with a policy template. Andrei Alexandrescu gives an example of this in section 1.5 of Modern C++ Design. (His example is also summarized in this Stack Overflow post.)
Template template parameters can be used when you need to know both the type of a template and how that template was instantiated, although this comes up less often than you might initially think, because there are often better ways to find the types involved. For example, there's no need to declare template <typename T, template <typename> class Cont> void ProcessContainedObjects(Cont<T>& cont) to let ProcessContainedObjects know what T is when any well-written container will define the Cont::value_type typedef.

Template template parameters are a useful addition to the C++ template programming toolbox, alongside techniques such as partial template specialization, type traits, concepts (also in C++0x), and C++0x's variadic templates (which can be simulated in C++03 to some extent by using default template arguments or by using Boost Preprocessor to create overloads of every arity from 1 through a #define'd limit).

Floating Point Exceptions

2009-03-15T18:25:00.000-07:00

As further evidence that floating point math is stranger than you think, consider the following code:

#include <stdio.h>
#include <math.h>
#ifdef __unix__
#define _GNU_SOURCE   // gives us feenableexcept on older gcc's
#define __USE_GNU     // gives us feenableexcept on newer gcc's
#include <fenv.h>
#else
#include <float.h>
#ifndef _EM_OVERFLOW
#define _EM_OVERFLOW EM_OVERFLOW
#endif
#endif

int main(int argc, char **argv)
{
    float a, b;

#ifdef __unix__
    feenableexcept(FE_OVERFLOW);
#else
    _controlfp(0, _EM_OVERFLOW);
#endif

    // gcc will compute these expressions at compile-time (which is
    // actually kinda cool, but it ruins the example) if we just do
    // pow(10.0, 50) and fabs(-13).
    int exponent = 50;
    a = pow(10.0, exponent);

    puts("1e50 is too big for a float, but we got this far,\n"
         "so we must be okay, right?\n");

    b = -13;
    b = fabs(b);

    puts("You'll never see this, because we just got an overflow trying\n"
         "to process a really small number!  How can this be!?!?\n"
         "The world is coming to an end!\n");

    printf("%f %f\n", a, b);

    return 0;
}

By default, at least on x86 systems, floating point exceptions are usually masked ¹, but I've been enabling them as part of my attempt at hairshirt programming or fail fast programming; exceptions such as overflow or division by 0 probably indicate logic errors or algorithmic limitations within the software, and I'd like to know about such problems as soon as possible. That led me to this problem: the pow call generates the exception, but it's not raised until the fabs call, completely confusing the poor programmer. Section 8.6 of the Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 1 (hereafter IASDM) explains how this behavior comes to be:

Because the integer unit and x87 FPU are separate execution units, it is possible for the processor to execute floating-point, integer, and system instructions concurrently. No special programming techniques are required to gain the advantages of concurrent execution. (Floating-point instructions are placed in the instruction stream along with the integer and system instructions.) However, concurrent execution can cause problems for floating-point exception handlers.

Intel's manual provides more details; to summarize, exceptions generated within the FPU are flagged within the FPU's status register but not raised until the CPU executes the next floating point operation. In practice, this should rarely be a problem: if the exception is generated during an operation, it will be raised when the results of the operation are written back to memory, and if the exception is generated when the results are written to memory (due to truncating to a smaller precision), it will be immediately raised as long as you immediately use the result that you just stored. So as long as you're not storing a low-precision value for later use and immediately going on to something else, you ought to avoid the confusing behavior described here.

If you do suspect that something like this is happening, then using C99's fetestexcept functions can help pinpoint the culprit:

    int exponent = 50;
    a = pow(10.0, exponent);

    if (fetestexcept(FE_OVERFLOW)) {
        puts("Warning; doom is impending.");
    }

    b = -13;
    b = fabs(b);

Or you can use C99's fegetenv and the undocumented internals of its fenv_t parameter to examine the entire x87 FPU state - its status word (including pending exceptions), its control word (including the current exception mask), and so on. If your environment doesn't provide an implementation of these fenv.h functions, you can borrow the MinGW runtime's (after adjusting the syntax for your compiler); the implementation is extremely simple (a few lines of assembly per function), and the MinGW runtime is in the public domain.

As an aside, this particular problem would not have happened if the code used doubles throughout instead of floats. Using floats at all is probably a mistake, but I've had some difficulty finding detailed information on the tradeoffs of floats versus doubles. Here's what I've been able to find so far:

Doubles take up twice as much memory as floats, although the extra memory usage is rarely an issue.
The x87 FPU always operates on 80-bit long doubles internally, as described in the IASDM (volume 1, section 8.2). For this reason, doubles are usually no slower than floats.
As a small exception to the previous statement, some builtin functions like pow that offer both float and double versions seem to run faster in their lower-precision versions.
As a larger exception to the previous statement, the performance SSE is entirely dependent on the size of the data it's operating on, so floats are twice as fast as doubles. On the other hand, if you're doing the kind of graphics, scientific, or gaming development that would most benefit from SSE, you probably already know more than I could tell you about the kinds of performance issues you'll face.
Floating point precision has a few historical oddities in C and C++; particularly old compilers promoted floats to doubles while doing calculations, and floats are promoted to doubles when given as arguments to variadic functions. (Since pointers can't be promoted, printf and scanf are asymmetrical: printf("%f", f); will work whether f is a float or a double, but scanf("%f", &f); requires that f be a float.)
The IASDM says (volume 1, section 8.2) that doubles should be used "as a general rule" but notes that "the single-precision format is useful for debugging algorithms, because rounding problems will manifest themselves more quickly in this format" and that 80-bit long doubles can be used "when an application requires the maximum range and precision of the x86 FPU."
If you're using Microsoft Visual C++ (as of MSVC++ 2008), you can't use 80-bit long doubles. Sorry.

If there are other pros and cons involved in selecting a precision, please let me know. Of course, if you or your predecessor designed your C/C++ code right, all of this is controlled by a single typedef, so it would be very easy to test for yourself. (If you do have the pleasure of working on such well-designed code, feel free to post a comment and gloat over those of us stuck maintaining legacy apps.)

1. Specifically, the x87 FPU disables all floating point exceptions by default, as described in section 8.1.5 of the Intel 64 and IA-32 Software Developer's Manual Volume 1. Microsoft follows suit (unless you set a compiler option), and apparently Linux does too, but CodeGear C++Builder only masks underflow, denormal operand, and inexact result exceptions as part of its startup code.

Things I Didn't Know about C++: Local Classes

2009-02-22T13:58:00.000-08:00

C++ is a complex language, and although I thought I knew it pretty well, I'm continuing to find areas of the language that I either didn't know or didn't understand well enough. So, on the (possibly narcissistic) assumption that others may not know enough about them too, here's a brief series of postings about them.

First up are local classes, which are not the same thing as nested classes.

class imitation_string {
public:
  // This is a nested class.  Other code can then use imitation_string::iterator.
  class iterator {
  public:
    iterator& operator++();
    iterator& operator--();
    char& operator*();
  };
};

void string_tokenizer(const imitation_string& in, std::vector<imitation_string>& out)
{
  // This is a local class.  It can only be used from within this function.
  class token {
    // Insert class definition...
  };
}

Local classes are closely related to nested (local) functions, which are not permitted in C++.

// Not valid C++.
int f()
{
  int i = 0;
  void g()
  {
    // A nested function has access to its enclosing function's variables.
    i++;
  }
  g();
  return i;
}

The position of local classes within the design of C++ seems very awkward to me. "True" nested functions require special implementation from the compiler, due to the requirement that they be able to access their enclosing functions' stack frames, and calling a nested function (via a function pointer) after its enclosing function has exited is a quick way to crash a program. This might be reason enough to omit them from the C++ language, but it didn't stop the GNU C Compiler from implementing them as an extension. Stroustrup dismisses local functions by saying that "most often, the use of a local function is a sign that a function is too large," but that didn't stop local classes from being permitted (with the same "too large" caveat). Nested functions occupy a much more comfortable position in other languages; Pascal (and therefore Object Pascal and Delphi) have supported them for ages, they're a key development technique in Javascript (used for everything from closures to jQuery event handlers), lambda expressions offer equivalent functionality in languages which support them, and so on.

Even ignoring their awkward position, local classes in C++ have some odd traits. First, they can neither be used as template parameters (so no smart pointers to local classes). Local class templates and local template methods are likewise prohibited. Second, although local class methods cannot access the enclosing function's variables (unlike a nested function), they can access static local variables within the enclosing function.

// Valid C++!
int f()
{
  static int i;
  class g {
  public:
    static void Execute() { i++; }
  };
  g::Execute();
  return i;
}

Similarly, local classes within a class method can access static members (even protected and private static members) of the enclosing class, and such access is implicitly scoped. They can also access protected and private members of friends of the enclosing class.

class F {
public:
  DoStuff();
private:
  static int i;
};

int F::DoStuff()
{
  class G {
  public:
    static void Execute() { i++; }
  };
  return i;
}

Various workarounds have been proposed for local classes' inability to access local variables of their enclosing functions. Herb Sutter gives a rundown of the various options in GotW #58. His final solution is worth mention; in an bit of C++ judo, he turns the enclosing function into a class, whose constructor contains the function body and which is implicitly convertible to the desired return value. The function's local variables become member variables, and the local functions / nested classes become class methods that can access these member variables.

Local classes have two main uses. First, they can be used to augment the regular control flow of a function. For example, Boost's new ScopeExit library lets you write arbitrary code to be executed whenever a code block exits (whether it exits by finishing, an explicit return statement, or throwing an exception). It implements this by defining a local class whose destructor executes the code RAII-fashion. The Google C++ Testing Framework offers another example of augmenting control flow with local classes. A unit testing framework needs both a way to abort the current test if a test assertion fails and (ideally) a way to signify that certain failed assertions are expected. The standard way to do this is to have failed assertions handled by throwing exceptions, and expected failures can be caught and handled. However, a design goal of Google Test is to avoid requiring the use of exceptions for maximum portability. Failed assertions are handled by a simple return statement. Expected assertions are wrapped in a local class method so that the return statement doesn't abort the entire function.

static int i = 1;
// This asserion:
ASSERT_EQ(1, i);
// expands to code vaguely resembling this:
if (1 != i) {
  ReportFailedAssertion(1, i, "ASSERT_EQ(1, i)", __LINE__);
  return;
}

// This assertion:
EXPECT_FATAL_FAILURE(ASSERT_EQ(2, i));
// expands to code vaguely resembling this.  Note the local class scoped to
// a dummy do/while block.
do {
  class GTestExpectFatalFailureHelper {
  public:
    static void Execute() {
      if (2 != i) {
        ReportFailedAssertion(2, i, "ASSERT_EQ(2, i)", __LINE__);
        return;
      }
    }
  };
  GTestExpectFatailFailureHelper::Execute();
} while(false);

Second, local classes can be used like any other class or function, as a mechanism for reusing and refactoring code. If you have code that appears in more than one place within a function, but is too specific to be used outside of that function, then following the principles of information hiding (if you prefer the dry CS term) or Spartan programming (if you prefer classical historical allusions or gratuitous Frank Miller references), you can use a local class to keep the code scoped as narrowly as possible. Personally, I've very rarely found code that's repeated within a function but is so specific that it will never be used outside of that function. However, this could simply be a case of my available tools determining how I solve problems. For example, Delphi permits local functions, and Delphi developers seem to find them moderately useful; the latest incarnation of Delphi's Visual Components Library, consisting of roughly 11,000 methods across 220,000 lines of code, uses about 190 local functions. Walter Bright, the creator of the D programming language, gives several examples of how nested functions can be used. He concludes,

Lack of nested functions is a significant deficit in the expressive power of C and C++, necessitating lengthy and error-prone workarounds. Nested functions are applicable to a wide variety of common programming situations, providing a symbolic, pointer-free, and type-safe solution.
They could be added to C and C++, but to my knowledge they are not being considered for inclusion. Nested functions and delegates are available now with D. As I get used to them, I find more and more uses for them in my own code and find it increasingly difficult to do without them in C++.

The Problem with the Web

2009-02-15T18:02:00.000-08:00

In "Why Chrome is Shiny," Jonathan Edwards does a wonderful job of articulating the vague misgivings that I've had about the current rush of interest in web applications:

I have realized that Internet browsers are a dead end, much like MS-DOS was... Some examples of these problems:
No multithreading

Reference counting GC, causing memory leaks

Only 2 outgoing TCP sockets, and only to same site as URL

Whole-page rendering, making dynamic layout changes unpleasant

DOM incompatibilities

Event firing and handling incompatibilities

Limited standard libraries, and poor support for large-scale programming
All of this reminds me very much of MS-DOS. Like the browser, it was essentially a toy that was not originally intended to be used for anything serious or intense. Hackers came in and discovered they could do all sorts of things beyond those original intentions, and that they could get rich in the process. In the resulting gold rush there was no time to worry about fixing the platform. MS-DOS willfully ignored the existing body of knowledge about how to design an operating system.

Javascript has its good parts - prototypes, first-class functions, JSON - but it has plenty of problems too. People are expending prodigious effort finding solutions or workarounds for those problems - for example, the V8 and TraceMonkey teams' efforts to improve Javascript's performance - but I can't help but wonder if that effort would be better spent on a language that was, you know, designed for the purpose for which it's being used.

And Javascript is only one problematic aspect of current web development. Web security, for example, is awful; Jeremiah Grossman estimates that 90% of sites have vulnerabilities, and he and his team can generally find a vulnerability in under two minutes. (And he writes some great war stories about doing so.) Security for web development is roughly where security for network server development was twenty years ago: it's possible to write secure code, but only if you know what you're doing, and only if you never make a mistake. Twenty years ago, that meant never overflowing a buffer, never using sprintf/strcpy/strcat, and being very careful how you used the nonintuitive strncpy/strncat. Now, it means never building an SQL query from user data, always HTML-escaping text before outputting it, blocking CSRF, and so on. Development on the desktop and in network services is finally advancing from "secure if you try really hard" to "secure by default", thanks to training and awareness efforts by SANS and others, more secure (harder to misuse) C libraries such as Microsoft's and OpenBSD's, the selective replacement of C and C++ with higher-level languages that eliminate the possibility of memory allocation or buffer overrun errors, and vendors (primarily Microsoft) finally embracing the principle of least privilege. Web development has yet to make this transition from "secure if you try hard" to "secure by default." Unless there have been advances that I'm not aware of? The most intriguing idea I've read is to use a strong type system, such as Haskell's, to distinguish between unsanitized and sanitized data.)

In spite of all of the problems with web development, it's the best (only?) method we've found of writing cross-platform, zero-deployment, sandboxed apps that can share data where needed and access data from anywhere. These are valuable features.

What should be done about the problems with web development? Silverlight might have the right idea, but I prefer my web without vendor lock-in. One approach (apparently favored by Edwards in "Why Chrome is Shiny") is to use a platform like the Google Web Toolkit or haXe to build on top of the current web platform and (hopefully) hide many of its shortcomings. At the very least, I figure we should be aware of the problems of the current technology craze and be a bit cautious of jumping on the bandwagon. That's good advice for technology in general.

Edit: I don't feel like I communicated very well... What seems strange about much of web development - what seems surreal about so much of software development in general - is that none of it has to be this way. It's not like other fields of engineering where are solutions are constrained by the laws of physics or by the chemical properties of the substances we're working with or similar; it's all, as Fred Brooks says, "castles in the air, [built] from air." It's largely an accident of history and of market forces that this combination of HTML and CSS (incompatible between vendors and often done improperly on web sites), Javascript (rushed out the door by Netscape and saddled with some bad design decisions), and XHR. And now, developers have spent prodigious effort making this concoction work, and with so much brains and sweat put into it, it often works amazingly well. But it's a place no one would choose to start from if they could have a choice.

Floods, Recessions, and Other Forces

2009-01-30T20:14:00.000-08:00

I found out today that a friend of mine was getting laid off.

I make computers obey me for a living. I consistently try to improve my skills, and I'd like to think that I'm pretty good at what I do. I tend to assume that I can master any problem or challenge that comes my way. But today was a reminder that there's still a great deal that I can't control. Professionally, I can't control my boss, my coworkers, vendors, or customers; in the broader realm of life, I can control even less.

As Dennis Bakke said in Joy at Work, when there's a hundred-year record flood, it doesn't matter how well your house is built.

It was an important reminder.

A Simple Essay

2009-01-27T21:41:00.001-08:00

Like many developers, I sometimes over-complicate my code, whether in an attempt to generalize and future-proof it or to just test out some new technique. In theory I know that over-complication is bad, but trying to do this in practice raises questions that I don't know how to answer. So, following a time-honored blogging tradition, I'm going to provide quotes from better known, more insightful people who address the topic, and I'll intersperse a few thoughts of my own so that I can act like I'm adding something to the discussion. (Each of the linked articles and papers is recommended reading for more treatment of this topic.)

“Controlling complexity is the essence of computer programming.” - Brian W. Kernighan (source unknown)

“Complexity is the business we are in, and complexity is what limits us.” - Frederick P. Brooks, The Mythical Man-Month, chapter 17

The main reason for pursuing simplicity is our own limitations:

“Programming is a desperate losing battle against the unconquerable complexity of code, and the treachery of requirements... A lesson I have learned the hard way is that we aren’t smart enough... The human mind can not grasp the complexity of a moderately sized program, much less the monster systems we build today. This is a bitter pill to swallow, because programming attracts and rewards the intelligent, and its culture encourages intellectual arrogance. I find it immensely helpful to work on the assumption that I am too stupid to get things right. This leads me to conservatively use what has already been shown to work, to cautiously test out new ideas before committing to them, and above all to prize simplicity.” - Jonathan Edwards, “Beautiful Code”

Edsger Dijkstra made a similar point over thirty-five years ago:

"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague." - Edsger W. Dijkstra, "The Humble Programmer"

Part of Djikstra's remedy, as I understand it, was to push for radical simplicity in programming languages, on the belief we must be able to easily and entirely understand “our basic tools.” The trend has instead been to push more and more complexity into our tools in hopes that it will make our applications manageably simple: languages continue to sprout new features, optimizing compilers rearrange our functions and variables behind our backs, garbage collection makes resource reclamation non-deterministic, and environments like the JVM and CLI become massive projects in their own right.

Accommodating human frailty is the philosophical reason for simplicity, but there are practical benefits as well:

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan and P. J. Plauger, The Elements of Programming Style, p. 10.

(A well-known quote, but have debugging advancements like IDE integration, VM playback, and omniscient debugging and techniques like TDD changed this?)

One reason for [Extreme Programming's encouragement of simplicity] is economic. If I have to do any work that's only used for a feature that's needed tomorrow, that means I lose effort from features that need to be done for this iteration... This economic disincentive is compounded by the chance that we may not get it right. However certain we may be about how this function works, we can still get it wrong - especially since we don't have detailed requirements yet. Working on the wrong solution early is even more wasteful than working on the right solution early. And the XPerts generally believe that we are much more likely to be wrong than right (and I agree with that sentiment.) The second reason for simple design is that a complex design is more difficult to understand than a simple design. Therefore any modification of the system is made harder by added complexity. This adds a cost during the period between when the more complicated design was added and when it was needed.” - Martin Fowler, “Is Design Dead?”

Although simplicity has many benefits, complexity is often unavoidable:

“The complexity of software is an essential property, not an accidental one. Hence descriptions of a software entity that abstract away its complexity often abstract away its essence. Mathematics and the physical sciences made great strides for three centuries by constructing simplified models of complex phenomena, deriving properties from the models, and verifying those properties experimentally. This worked because the complexities ignored in the models were not the essential properties of the phenomena. It does not work when the complexities are the essence.” - Frederick P. Brooks, “No Silver Bullet: Essence and Accident in Software Engineering” (as printed in The Mythical Man-Month)

Brooks gives other reasons for complexity being an essential property of software: communication, the number of possible states, and interdependencies all scale nonlinearly, and unlike other human constructs, no two parts of a program are identical.

“I find languages that support just one programming paradigm constraining. They buy their simplicity (whether real or imagined) by putting programmers into an intellectual straitjacket or by pushing complexity from the language into the applications.” - Bjarne Stroustrup, “The Real Stroustrup Interview”

This is one of the few “pro-complexity” quotes I've been able to find. Stroustrup is arguably biased, considering the complexity of his most famous creation, but his point is valid: some complexity is unavoidable and sometimes the best you can do is to push it to the language or the libraries so that the applications can (hopefully) avoid dealing with it. This is why I think that, e.g., the Boost libraries are a good thing, despite or because of their complexity.

Complexity is a major risk to software projects.

“What is the most common mistake on C++ and OO projects? Unnecessary complexity – the plague of OO technology. Complexity, like risk, is a fact of life that can't be avoided. Some software systems have to be complex because the business processes they represent are complex. But unfortunately many intermediate developers try to “make things better” by adding generalization and flexibility that no one has asked for or will ever need. The customer wants a cup of tea, and the developers build a system that can boil the ocean [thanks to John Vlissides for this quip].” - Marshall Cline et al., C++ FAQs, Second Edition, p. 36

“What's the Software Peter Principle”? The Software Peter Principle is in operation when unwise developers “improve” and “generalize” the software until they themselves can no longer understand it, then the project slowly dies.” - Marshall Cline et al., C++ FAQs, Second Edition, p. 37

The term “Software Peter Principle” was coined in C++ FAQs, but it's at least spread enough to get its own Wikipedia page with some added discussion. “Avoid Death by Complexity,” by Alan Keefer, covers the same subject matter and is too long to quote here; just go read it.

Development methodologies can help in the pursuit of simplicity:

I suggest: Exploiting the mass market to avoid constructing what can be bought. Using rapid prototyping as part of a planned iteration in establishing software requirements. Growing software organically, adding more and more function to systems as they are run, used, and tested. Identifying and developing the great conceptual designers of the rising generation. - Frederick P. Brooks, “No Silver Bullet”

Popular perception often views “No Silver Bullet” and The Mythical Man-Month as pessimistic, but Brooks argued that the essential complexity could be steadily reduced; his approach of rapid prototyping and iterative organic growth anticipates some the agile development techniques.

“Do the simplest thing that could possibly work.” “You Aren't Gonna Need It.” - Extreme Programming maxims.

Keep in mind, though, that XP practices reinforce each other; YAGNI and “do the simplest thing” won't work unless you're also practicing unit tests (to find out if your simplest thing actually does work, and to permit refactoring) and refactoring (to keep your design clean as your “simplest” and “not needed” code necessarily grows).

As I try to figure out the balance between simplicity and complexity, I was encouraged to read that someone as experienced as Martin Fowler seems to struggle with some of the same questions:

“So we want our code to be as simple as possible. That doesn't sound like that's too hard to argue for, after all who wants to be complicated? But of course this begs the question "what is simple?" ... [One major criteria for XP is] clarity of code. XP places a high value on code that is easily read. In XP "clever code" is a term of abuse. But some people's intention revealing code is another's cleverness... In his XP 2000 paper, Josh Kerievsky points out a good example of this. He looks at possibly the most public XP code of all - JUnit. JUnit uses decorators to add optional functionality to test cases, such things as concurrency synchronization and batch set up code. By separating out this code into decorators it allows the general code to be clearer than it otherwise would be. But you have to ask yourself if the resulting code is really simple... So might we conclude that JUnit's design is simpler for experienced designers but more complicated for less experienced people?...Simplicity is still a complicated thing to find. Recently I was involved in doing something that may well be over-designed. It got refactored and some of the flexibility was removed. But as one of the developers said "it's easier to refactor over-design than it is to refactor no design." It's best to be a little simpler than you need to be, but it isn't a disaster to be a little more complex. The best advice I heard on all this came from Uncle Bob (Robert Martin). His advice was not to get too hung up about what the simplest design is. After all you can, should, and will refactor it later. In the end the willingness to refactor is much more important than knowing what the simplest thing is right away.” - Martin Fowler, “Is Design Dead?”

Of course, this struggle between simplicity and complexity is hardly new with or specific to programming.

'Tis the gift to be simple, 'tis the gift to be free...” - Joseph Brackett Jr., “Simple Gifts,” 1848

No Boost for Google

2009-01-17T17:45:00.001-08:00

I recently came across the Google C++ Style Guide, and since the folks at Google are geniuses, I thought it would be worth a read. Among the various sound practices, sage advice, and sensible conventions which it laid out, I found this surprising requirement:

Use only approved libraries from the Boost library collection... Some Boost libraries encourage coding practices which can hamper readability, such as metaprogramming and other advanced template techniques, and an excessively "functional" style of programming... In order to maintain a high level of readability for all contributors who might read and maintain code, we only allow an approved subset of Boost features [consisting of roughly five and a half of Boost's nearly one hundred libraries]...

I confess: I love the Boost libraries. I curse my compiler for not supporting Pointer Container. I gaze in awe at the metaprogramming that makes Units and Accumulators possible. I use Format, despite its documented performance problems, because it's so darn convenient. I painstakingly craft Lambda and Preprocessor expressions, in spite of their unforgiving syntax and obtuse error messages, just to have code that's a bit less repetitive and a bit more extensible. (It's truly amazing that the Boost devs have figured out how to add preprocessor-based code generation and lambda expressions to C++.)

But is my approach really best? As already mentioned, the folks at Google are geniuses; maybe they're on to something here? The core goal of the Style Guide authors in restricting Boost seems to be to promote simplicity, which is often in short supply as a software project develops. Some of a project's increase in complexity is unavoidable, as it gains features and adapts to handle real-world problems. Some of a project's increase in complexity is the natural result of entropy and is best handled by a healthy regimen of refactoring. Some of it, though, can only be staved off by a radical commitment to simplicity, as the folks at Google (seem to) suggest, but this raises a number of questions and tradeoffs. For example, is the simplicity of straightforward, somewhat repetitive boilerplate code better or worse than fully generic C++ template wizardry? Is boilerplate code better or worse than depending on a DSL or scripting language to generate code? What about code that's simple to an experienced developer but complex to a novice (or vice versa - code that's simple for a junior developer to write but fails to use simple-to-maintain techniques that a senior developer would know)? To what extent is it okay to make a class's internals complicated if it makes the class simpler to use? Do I use Lambda and Preprocessor because they're the best tools for the job, or do I use them because I find wrapping my head around them to be a more interesting challenge than maintaining the legacy code base I'm working on? Are the benefits (to my productivity and to future extensibility) of adding a dependency on yet another external library worth the costs to my coworkers and future maintainers of having to understand yet another library before they can work on my code?

At this point in my career, I'm not sure how to answer these questions. I suspect that the approach advocated by the Google C++ Style Guide is flawed; if simplicity is the goal, it's difficult to see how rolling your own IPC or threading library could be simpler than using Boost's, and even small classes and functions like optional and lexical_cast can make code simpler and more readable. However, I suspect that my approach is flawed too; much has been written about the fact that even relatively simple programs are too complex to hold in your head at once, and pursuing the design goals of elegance, extensibility, and robustness without also remembering simplicity can too quickly land you in architecture astronaut territory.

Like I said, I love the Boost libraries. But I've been revising some code I wrote six months ago to no longer use Lambda. It's just simpler this way.

Floating Point Reference

2009-01-04T17:37:00.000-08:00

"Fractions are your friends." This was my high school algebra teacher's standard response when students complained about the sometimes tedious math that they could require. Many years later, I'm finding that while floating point math, while not tedious, is still rather more involved than it appears at first; here's my attempt to summarize issues that may come up.

Floating point data types

In C on an x86 system:

A float is 32 bits.
A double is 64 bits.
A long double is compiler-dependent. A long double in gcc contains 80 bits of data, although it's stored as 128 bits (16 bytes) to maintain word alignment. Visual C++ treats a long double as 64 bits, just like a double (and has been criticized for doing so; see here and here). I had been under the impression that long doubles were nonstandard or were a recent addition to the standard, but as far as I can tell, they've been around since before C99.

Selecting a floating point data type

See this portion of another post.

Floating point storage

This is covered on many sites; the most concise and thorough description I've found is in chapter 2 of Sun's Numerical Computation Guide.

NaNs and Infinity

See my previous post.

Comparing floating point numbers

A simple equality comparison (such as a == b) will often fail, even for values which you would expect to be equal, due to rounding errors (especially rounding introduced by converting between binary and decimal). (Do any compilers or static code analysis tools emit warnings if you try to do a naive equality comparison?)

The simplest solution is to check if two floating point numbers are within a small developer-chosen epsilon value of each other; this is the approach used by the CUnit and CppUnit testing frameworks, but it has the disadvantage of requiring you to choose an epsilon value yourself and make sure that it's appropriate for the data being compared.
"Comparing Floating Point Numbers," by Bruce Dawson, discusses this absolute epsilon approach as well as more sophisticated approaches such as comparing using a relative epsilon and comparing based on the number of possible floating point values that could occur between the two operands.
The simplest good approach, provided by CERT, is to compare using compiler-provided absolute epsilons. (As I understand it, CERT's approach should be equivalent to Dawson's approach with a max ulps of 1.)

Greater than / less than comparisons generally require no special handling, although at the assembly level, a comparison may return a result of "unordered" if NaNs are involved, and one of the compilers I tested (CodeGear C++Builder) fails to account for this and so may return incorrect results when comparing NaNs.

Handling floating point exceptions

See this post.

Low-level floating point calculations

If you need to do floating point work at the assembly level, use Intel Software Developer's Manuals as a reference. Volume 1 has some background on the FPU; volume 2A contains most floating point instructions (since they start with F).

Example code

Rather than simple math, the following code covers manipulating floating point numbers' bit representations, handling NaNs and infinities, and so on.

This earlier post has several code snippets.
The Google C++ Testing Framework has a FloatingPoint class template in include/gtest/internal/gtest-internal.h and an associated FloatingPointTest test fixture in test/gtest_unittest.cc. Although FloatingPoint is intended for use by the framework, it should be general enough to be useable elsewhere.

For further reading

In no particular order...

"What Every Computer Scientist Should Know About Floating-Point Arithmetic," by David Goldberg et al. Very thorough and math-intensive. Despite the title, I haven't finished reading this paper.
"Lecture Notes on the Status of IEEE Standard 754 for Binary Floating-Point Arithmetic," by W. Kahan. Kahan is the primary architect of the IEEE 754 floating point standard; the section entitled "Ruminations on Programming Languages" is particularly interesting.
"Comparing Floating Point Numbers," by Bruce Dawson. Also referenced above.
The Floating Point Arithmetic section of the CERT Secure Coding Standards. Primarily a list of "gotchas" which experienced programmers hopefully already know to avoid.
Wikipedia's article on floating point and linked articles. Honestly, I've found Wikipedia's coverage to be a bit sprawling; hence my attempt at a shorter, more targeted list.

EDIT: (3/15/2009) Added sections on "Selecting a floating point data type" and "Handling floating point exceptions."

NaNs, Uninitialized Variables, and C++

2008-12-08T18:15:00.000-08:00

I've become a big fan of fail fast programming, or what Matthew Wilson colorfully refers to as "hairshirt programming." In other words, if I make a mistake in my code, or if I use a piece of code in a way that violates the assumptions under which it was written, I want to know as soon as possible. C++ is fairly good at doing this at compile time, thanks to a static, reasonably strong, extensible type system, and thanks to add-on features like BOOST_STATIC_ASSERT. For problems that can't be detected at compile time, the liberal use of assertions can help enforce preconditions and postconditions, and classes like std::string and boost::array add error checking over C-style strings and arrays. When I first read about signaling NaNs, I thought that they would be a wonderful addition to this fail fast toolbox. As documented, a signaling NaN is basically magic value that, when assigned to a floating point variable, would cause any attempt to use that variable to throw an immediate exception. This could be an immensely useful tool for tracking down uninitialized variable use and for tracing the operation of legacy code (to answer questions such as, "Is this variable really unused along this code path?"). Unfortunately, signaling NaNs don't work nearly as well as advertised. But first, some background... NaNs are used in the IEEE 754 floating point standard to describe indeterminate forms such as 0/0, ∞ - ∞, 0 * ∞, and so on. NaNs are not the same thing as infinity (either positive or negative infinity). Attempting to do arithmetic on a NaN (almost always) results in another NaN. So if 0/0 is not a number, then 0/0 + 1 is also not a number, and 0/0 * 100 is not a number, and so on. Under some circumstances, this NaN propagation may be what you want; under other circumstances, you may want to catch NaNs as soon as possible (to invoke error recovery, or to launch a separate calculation path, or whatever). Presumably to accommodate this, IEEE 754 distinguishes between quiet NaNs (which quietly propagate when used) and signaling NaNs (which throw exceptions when used). NaNs are represented by storing certain bit patterns in place of a "normal" floating point number. For details, see here. Interestingly, many of the bits in a NaN encoding are unused. (I.e., a NaN can be represented by many different bit patterns.) I've seen suggestions that the unused bits could be used to encode a line number or module number, although I've seen no code that takes advantage of this. C++ supports quiet and signaling NaNs through its std::numeric_limits class template. For example:

#include <limits>
#include <iostream>

int main(int argc, char *argv[])
{
  if (std::numeric_limits<double>::has_quiet_NaN) {
      double d = std::numeric_limits<double>::quiet_NaN();
      std::cout << "The bit pattern of a quiet NaN on your platform is 0x"
           << std::hex << *((long long int*)&d) << endl;
  } else {
      std::cout << "You do not have a quiet NaN for doubles" << endl;
  }
}

Similarly, std::numeric_limits<double>::signaling_NaN() returns a signaling NaN. Unfortunately, as far as I can tell, this feature of the Standard C++ Library is completely useless:

If floating point exceptions are enabled, then processing a signaling NaN raises an exception. std::numeric_limits<double>::signaling_NaN()'s returning a signaling NaN counts as processing it.
If floating point exceptions are disabled, then processing a signaling NaN transforms it to a quiet NaN.

You can store a signaling NaN to a variable by directly assigning the appropriate bit pattern:

void set_snan(double& f)
{
  *((long long*)&f) = 0x7ff0000000000001;
}

Or, depending on your C++ library implementation, you might find it simpler to steal its signaling_NaN() implementation:

// Assign a signaling NaN using Dinkumware's implementation; works in MSVC
// and C++Builder.
void set_snan(double& f)
{
  memcpy(&f, &_Snan._Double, sizeof(f));
}

Even after you take care of assigning a signaling NaN, making sure that it actually signals is non-trivial:

It appears to be somewhat compiler-specific which actions actually raise an exception. Assigning the value of one variable to another does not raise an exception in CodeGear C++Builder but does in Visual C++. The rule seems to be that "anything involving the FPU" can raise an exception if signaling NaNs are involved, and assignment may be done through the FPU or may be done as a memory copy.
Raising an exception only occurs if "invalid operation" exceptions are enabled, and there is no portable way of controlling floating point exceptions. C99 specifies the fetestexcept family of functions, at least some of which are also specified in TR1, but of the compilers I tested, only gcc (but not Apple's version!) supports fetestexcept. Visual C++ provides _control87 and _controlfp, which is rather low-level for my taste. CodeGear C++Builder provides Math::SetMaskException, which uses Object Pascal-inspired sets instead of C-style bitmask manipulations but is completely nonportable. If all else fails, you'll have to set the FPU's control word using inline assembly; see here.
The floating point exception mask is, as best I can tell, part of the per-thread CPU state. This means that third-party code which your code uses can change it, violating your expectations of which floating point operations will raise exceptions.

To summarize:

There is no portable way to assign a signaling NaN.
Even if there were, there is no portable way to make sure that performing an operation on a signaling NaN actually signals.
It is not entirely straightforward which operations will cause a signaling NaN to signal.
Even if you get all of the above right, third-party code may go and mess it up.

So, to conclude, signaling NaNs are probably not a good approach to handling uninitialized variables for the "fail fast" toolbox. In fact, I don't know what practical use signaling NaNs have in the C++ standard at all. Is there a good solution for catching uninitialized variable use? I haven't yet had time to test out options against my code base to see what would work for me, but a few possibilities come to mind:

Compiler warnings help, although code complexity can easily exceed a compiler's ability to track uninitialized variables. GCC suffers an additional disadvantage; its uninitialized variable detection depends on its code flow analysis, and code flow analysis is only enabled if optimizations are enabled, so you often won't see these warnings in debug builds.
boost::optional works, although that's not a drop-in replacement
Never have an uninitialized variable again: use STLSoft's must_init by appending _init_t to all of your fundamental data types (int → int_init_t, double → double_init_t, etc.). Invasive, but an interesting idea...
When I asked this question on Stack Overflow, this class was suggested as one possible answer.
Signaling NaNs are perhaps the easiest approach and remain an option, in spite of their shortcomings.

Finally, for anyone who's persistent enough to have read this far, here's a complete test program for playing with the various issues raised in this posting. Tested on Visual C++ 2008 and Debian 4.0's g++.

#include <float.h>
#include <iostream>
#include <sstream>
#include <limits>
#include <iomanip>

#if defined(__unix)
#include <fenv.h>
#endif

#if defined(_YMATH)

// (Ab)use Dinkumware's implementation if found.

void set_snan(long double& f)
{
 memcpy(&f, &_LSnan._Long_double, sizeof(f));
}

void set_snan(double& f)
{
  memcpy(&f, &_Snan._Double, sizeof(f));
}

void set_snan(float& f)
{
  memcpy(&f, &_FSnan._Float, sizeof(f));
}

#else

// Add some type safety to our evil, non-portable bit-flipping.
#include <boost/static_assert.hp>
BOOST_STATIC_ASSERT(
  sizeof(long double) == sizeof(long long) + sizeof(long)
  && sizeof(double) == sizeof(long long)
  && sizeof(float) == sizeof(long));

void set_snan(long double& f)
{
  *((long long*)&f) = 0x0000000000000001LL;
  *((long*)&f + 2) = 0x7fff;
}

void set_snan(double& f)
{
  *((long long*)&f) = 0x7ff0000000000001LL;
}

void set_snan(float& f)
{
  *((long*)&f) = 0x7f800001L;
}

#endif

// Return a string containing p's raw bits, in hex value.
// Assume little endian.
template<typename T>
std::string ascii_bits(const T& p)
{
  std::ostringstream o;
  o << "0x" << std::setfill('0');
  for (int i = sizeof(p) - 1; i >= 0; i--) {
    o << std::hex << std::setw(2)
   << int(reinterpret_cast<const unsigned char*>(&p)[i]);
  }
  return o.str();
}

using namespace std;

int main(int argc, char* argv[])
{
  typedef double TYPE_TO_TEST;
  TYPE_TO_TEST f, g;

  // Enable exceptions.  A real app would be more selective and may
  // need to save the previous mask.
#if !defined(__unix)
 _control87(0, _EM_INVALID);
#else
  feenableexcept(FE_ALL_EXCEPT);
#endif

  f = std::numeric_limits<TYPE_TO_TEST>::quiet_NaN();
  cout << "Has quiet NaN?  "
       << std::numeric_limits<TYPE_TO_TEST>::has_quiet_NaN << endl;
  cout << "Quiet NaN is printed like this: " << f << endl;
  cout << "Bit pattern for quiet NaN:      "
       << ascii_bits(f) << endl;

  set_snan(f);

  cout << "Has signaling NaN?  "
       << std::numeric_limits<TYPE_TO_TEST>::has_signaling_NaN << endl;
  cout << "Bit pattern for signaling NaN:  " << ascii_bits(f) << endl;

  g = f;

  cout << "Depending on your compiler, you may see this." << endl;

  g = f + 1;

  cout << "You should never see this." << endl;

  return 0;
}