Steve's Tech Talk

Lou Francos

Steve Hawley — Tue, 06 May 2008 19:25:00 GMT

I was playing with the Product Box Generator and created the following bit of fun:

I love software.

Thanks, Lou, for tolerating me.

When "new" is Too Slow

Steve Hawley — Mon, 05 May 2008 13:46:00 GMT

I was working on some prototype code that needed to be super fast. After getting basic functionality up and running, I found that the biggest chunk of time was getting lost in operator new. In this particular chunk of code, I had some simulated recursion that was making lots and lots of little objects that were being pushed and popped onto a stack. The issue was that these objects are tiny and transient. This means that all the overhead imposed by new and delete will get charged again and again and again.

There are a number of choices available to you when you do this. I'll pass on one that breaks a number of conventional OO design rules, specifically is-a/has-a. In my case, I had some objects that have two purposes in life - to hold data and to live in a stack. If you are a fan of STL, you will probably haul out stack<t> and call it good. In my case, STL's performance was heinous, so I chose to smudge the is-a/has-a line and make my little object into a stack element rather than using a stack element to hold it:

class StackPoint { public: StackPoint(unsigned int x, unsigned int y) : m_next(NULL) { m_pt.x = x; m_pt.y = y; } StackPoint (POINT pt) : m_pt(pt), m_next(NULL) { } virtual ~StackPoint () { } int X() { return m_pt.x; } int Y() { return m_pt.y; } void SetX(int x) { m_pt.x = x; } void SetY(int y) { m_pt.y = y; } StackPoint *GetNext() { return m_next; } void SetNext(StackPoint *next) { m_next = next; } private: POINT m_pt; StackPoint *m_next; };

class MyStack { public: MyStack() : m_stack(NULL) { } virtual ~MyStack(); bool IsEmpty() { return m_stack == NULL; } void Push(StackPoint *item) { item->SetNext(m_stack); m_stack = item; } StackPoint *Pop(); private: StackPoint *m_stack; };

In these snippets, I'm leaving out some of the methods, but they're simple to write. Pop() returns null if the stack is empty, or the top of the stack otherwise, resetting the stack pointer. The destructor rips the entire stack, disposing each element in turn. From these two classes, I can now create an allocator like this:

class StackPointAllocator { public: StackPointAllocator() { } virtual ~StackPointAllocator() { } StackPoint *Alloc(int x, int y); void Free(StackPoint *p); private: MyStack m_stack; };

In this case, the StackPointAllocator has a method called Alloc which will do one of two things. If m_stack.IsEmpty() is true, it will call operator new. If m_stack.IsEmpty() is false, it will pop the top item off, set x and y and return it. In the typical case, there is an item left on the stack and so "allocation" (really recycling), is only a few assignment statements. Note that m_stack is a NOT a pointer, which means that its destructor will automatically get called when the allocator goes out of scope or is deleted.

To give you a sense of the power of doing this, the original problem with allocation was costly because I was allocating tens of millions of these objects, each of which has a very short life span.Even though the individual cost was small, multiplying by 10M added up. I'd rather do 40M assignments. Once the code was refactored (easy), the time for allocation totally vanished from the performance profile.

Now, the real C++ programmer question is "Why didn't I override global operator new for StackPoint?"

Overriding global operator new means that all code that allocates these objects will go through the global allocator - that's a bigger deal. I use this code in other places that shouldn't use this allocator. I end up making the allocators I use stack objects, which means that objects in the free list disappear when they go out of scope.

Classic engineering dilemma: which is more important? performance or OO design? In this case, the API is NOT public, so the dirty little secret is hidden away, making this a perfectly acceptable choice. Performance, FTW. In addition, there were two other considerations - readability and expedience. Readability was not lost at all, and since I could knock this out inside a half hour, I won on expedience too.

Out, Out, Damn Ref

Steve Hawley — Fri, 18 Apr 2008 19:44:00 GMT

What is the difference between the out and ref keywords in C#? Rick and I were discussing this earlier today and I decided that I wanted to find out for real. Inherently, I know what the difference is: ref is passed by reference and out is pass by reference with the added requirement that the parameter must be assigned to.

But this is a very minor semantic difference, so the real question is whether or not the difference is enforced by the language/compiler or by the CLR. For this, we will determine the answer empirically with this chunk of code:

private void SetMyFriend(out int x) { x = 5; } private void TouchMyFriend(ref int x) { x = 3; } private void MyFriend() { int x; SetMyFriend(out x); TouchMyFriend(ref x); }

Once this is written and compiled, we can pull it up with ildasm and have a look at what the compiler has done.

Here is the IL for SetMyFriend()

.method private hidebysig instance void SetMyFriend([out] int32& x) cil managed { // Code size 5 (0x5) .maxstack 8 IL_0000: nop IL_0001: ldarg.1 // put address of x on the stack IL_0002: ldc.i4.5 // put a 5 on the stack IL_0003: stind.i4 // store the 5 into the address IL_0004: ret } // end of method BasicTesting::SetMyFriend

No surprises - x is passed in as an int32& or a reference to a four byte int - ah, but it has the magic [out] attribute on it as well.

Here is TouchMyFriend():

.method private hidebysig instance void TouchMyFriend(int32& x) cil managed { // Code size 5 (0x5) .maxstack 8 IL_0000: nop IL_0001: ldarg.1 IL_0002: ldc.i4.3 IL_0003: stind.i4 IL_0004: ret } // end of method BasicTesting::TouchMyFriend

You'll notice that except for the [out] in the declaration, it is absolutely identical to SetMyFriend. I won't insert the calling code, but it is precisely the same for both. So the answer to the question is that the compiler enforces it to the degree that it will attempt to determine if the value has been assigned via static analysis. Yet, is this 100% the case because the parameter is marked as [out]. Does the CLR do the verification? The answer is no - if you write the following managed C++ method:

static void DontTouchMe([System::Runtime::InteropServices::Out]int __gc &x) { }

the C++ compiler lets it go by and at runtime, the CLR lets it work too. This is moderately distressing, but not surprising. Lesson: out is only fully honored in C#.

Intraeducation

Steve Hawley — Fri, 18 Apr 2008 12:31:00 GMT

In a previous blog entry, I wrote about the importance of professional development, especially from within. I'd like to briefly underscore this with a double line written in a heavy magic marker.

One of the major goals of education at the high school level (at least it was when I was teaching) is to foster lifelong learning. I am a strong proponent of this and try to live it as best as I can.

It is also important to recognize, as you get older and more experienced, your ability to take new things and put them into a bigger picture in terms of either abstraction or concrete application. Here's an ideal example, Rick has been writing a series about using stack allocation for performance tuning. I had written a blog entry about this a couple years back which got some helpful comments.

Rick came in to ask me a few questions and in true Steve style, I sent him off with about a half dozen new questions that we raised together and a direction for finding the answers, and a spark.

The point is that most of us know more than we give ourselves credit for. If you choose to believe this then you can take advantage of it to help your colleagues learn. I don't mean necessarily shoving knowledge down their throats (guilty!), but rather finding the opportune moment to add a piece to the puzzle to help sort things out or put in a bigger perspective.

Personal perspective adds a lot to the picture as well. I came into the professional from an old school direction. As an adolescent, I (re)invented a lot of the major elements of computer science and software engineering while coding in assembly language. No, really. I wrote code that was procedural before I had been exposed to procedural programming. Later I wrote code that was object-oriented before I had seen C++ because it solved the problems I needed to solve in a terse, uniform, effective way. As a result, when I look at languages like C# or C++, I often find myself thinking of them in terms of how I would write that code in plain C or in an assembly. I do this because I naturally try to spot bottlenecks where code could be (a) made more flexible and (b) be make faster. For example, I demonstrated this to Rick again by showing a traditional C++ code pattern and then showed how it could be implemented in C and with a tiny bit of refactoring would shave a half dozen instructions off an inner loop without losing any of the flexibility. The point there is that I had a perspective that he didn't and by sharing it, I hope I just saved Rick years of work. It took me years, after all, to learn it.

Making Noise

Steve Hawley — Wed, 02 Apr 2008 16:27:00 GMT

I was reading a number of articles about using noise for image generation. I came across this set of web slides by Ken Perlin, who pretty much invented the use of noise for surface texturing and pattern deformation. In addition to some delicious eye candy, it is one of the most succinct and understandable descriptions of the process of noise generation.

Here is Perlin's original source code for generating noise in C and an application that uses his techniques to generate clouds.

More Unit Test Tricks

Steve Hawley — Mon, 24 Mar 2008 12:35:00 GMT

I've posted before about some tricks you can do to play with NUnit and get more out of your testing. Today I'm going to pass in some more tricks I came up with recently to use reflection to verify correctness.

Recently, we had a defect that involved the properties of a Control object that were lacking the appropriate categories. In the VS designer, they all showed up as "Misc". This is not a big deal and is fairly easy to fix, but it is also fairly easy for recidivation on this bug as it is easy to add a new property and forget to add a category.

So let's formally define a property that appears in the UI designer. A complete property in the UI designer is marked with a Browseable attribute and contains exactly one Category attribute.

Given that, we can write predicates for the conditions upon which our definition hinges:

private bool IsBrowsable(object[] attrs)
{
    // returns true if the set of attributes on a Type indicate browsable
    foreach (object o in attrs)
    {
        if (o is BrowsableAttribute)
        {
            BrowsableAttribute br = (BrowsableAttribute)o;
            return br.Browsable;

}

}
return true;
}

In this case, we search the collection of attributes for a BrowseableAttribute. If we find one, we return its setting. Otherwise, without the attribute the property must be browseable so we return true by default.

private bool IsCategorized(object[] attrs)
{
    // returns true if a property has a category
    foreach (object o in attrs)
    {
        if (o is CategoryAttribute)
        {
            CategoryAttribute ca = (CategoryAttribute)o;
            return ca.Category != null &&
                    ca.Category.Length > 0;
        }
    }
    return false;
}

In this predicate, a property is considered categorized if it has a CategoryAttribute, the attribute's Category property is non-null and it's length is greater than zero.

Given that, we can use the following stub to test a UI object:

// get only the props declared by the final object (not base classes) that are public
PropertyInfo[] props =
objectUnderScrutiny.GetType().GetProperties(BindingFlags.DeclaredOnly |

BindingFlags.Public | BindingFlags.Instance);

foreach (PropertyInfo prop in props)
{
    object[] attrs = prop.GetCustomAttributes(false);
    if (!IsBrowsable(attrs))
    {
        // skip if not browseable
        continue;
    }

    if (!IsCategorized(attrs))
    {
        Assert.Fail("property " + prop.Name +
            " is missing category.");
    }
}

Lest I forget - there's a solid why this category of test is useful - with dispassionate calm, it will flag very human, future errors that are easy to make. When you implement a process, write code, etc. Be on the lookout "mandatory" steps that do not cause compile errors. Applying Category attributes is exactly such a step - without it, a control object would not be professional quality, but applying attributes is purely optional. It would be nice if you could flag in a base class rules for the existence of certain attributes in subclasses as well as to mark the error as fatal or non-fatal. This way an abstract class could not only dictate interface, but semantics as well.

In the meantime, unit tests will have to serve.

Parallelism

Steve Hawley — Tue, 18 Mar 2008 12:20:00 GMT

Threading in current programming models is one of the hardest things to get right. It appears to be a fabulous tool waiting to be exploited, but it is instead one of the hardest things to get right. Mike Stall has an interesting take on the combinatorial nature of multithreading and how the possible areas for bugs balloon as the number of threads increase. Similarly Jeff Atwood goes into details about it as well.

Some people say that the solution is in the languages. Fix the languages and then you've fixed the threading problem. I don't know if I believe in that silver bullet. You get some benefit in purely functional languages. When I was in college nearly 20 years ago (eep!), I took a seminar course about functional programming. In the class, we were presented with the graph reduction approach to program evaluation. Essentially, the approach is to represent the code as a graph which can be reduced to a single node. Part of the approach is one that allows for multiple processors/threads to work on the same graph at the same time with a minimum of critical sections. Simon Peyton Jones visited campus as a guest lecturer and honors examiner and talked about this as well. Jones has his hands in a number of interesting technologies, including Haskell.

In DotImage, we added threading into our image processing. To do this, I created a meta-command called ThreadedCommand. This command acts like an ImageCommand but does no image processing. Instead it breaks an image into bands, and throws worker threads at the bands.

Rather than deal with full concurrency, we limited the domain of the problem instead. Not every ImageCommand can be effectively threaded. Instead, we use the following rules. An ImageCommand can be threaded if:

It implements IConeable. We do not use the same command on every thread. Instead, we use clones so as to avoid internal state issues within the command.
It does not modify the source image outside a given scanline and if it does modify within a given scanline, it requires no state outside of a given scanline.
It requires no state calculated from one band for use in another
It implements IThreadableCommand (our interface)

By abiding by these rules, it is possible to thread many ImageCommands without a deep knowledge of threading, which is the way I think it should be.

Now, in implementing this we built a worker thread library and it was far more painful than it should've been. We looked for support code that we could use in our environment (we had to support .NET 1.1 and above) and found nothing usable, which is a crime because our needs are simple: this code needs a set of workers, a queue of jobs, a way to start workers running, a way for them to report completion, and a way to kill them instantly. Every single one of these things was hard to do right, even when we stacked the deck in our favor. That tells me that the underlying threading tools need other support classes on top of them - badly.

Immutability

Steve Hawley — Mon, 17 Mar 2008 15:00:00 GMT

Functional programming is in. There is a lot of buzz around the future of functional programming as applications look to leveraging multiple processors and multiple cores for their tasks. One of the things that makes this easier is to work with immutable data structures. Eric Lippert has written a number of thoughtful blog entries on immutability, in particular this entry on an immutable stack caught my eye.

In essence, if Eric had written this in Scheme (and my scheme is rusty, so bear with me), it would've been something like this:

(define empty-stack '()) (define stack empty-stack) (define stack-push (lambda (a stack) (cons a stack))) (define stack-pop (lambda (stack) (if (eq? stack empty-stack) (empty-stack) (cdr stack)))) (define stack-peek (lambda (stack) (if (eq? stack empty-stack) '() (car stack)))) (define x stack) (define x (stack-push 'a x)) (define x (stack-push 'b x)) (stack-peek x) (define x (stack-pop x))

So why am I bringing up Scheme? Because Eric's code is starting to look hauntingly like Scheme and not like C#. This is not necessarily a bad thing - there are a lot of great things to learn from Scheme. By the way, here is a Java implementation of Scheme where you can try out that code.

I have an important semantic quibble, though. Eric's Pop is not Pop. Since it violates the Principle of Least Astonishment, it should have a different name. The history of Pop indicates that two things happen - an object gets removed (and I get it) and the stack gets changed (and I get that too). I would suggest Drop instead. I do question the usefulness of this definition, though. Here is some code that I have in production that is run on a stack machine:

private void SetColorRGB() { double c3 = ((Number)stack.Pop()).Value; double c2 = ((Number)stack.Pop()).Value; double c1 = ((Number)stack.Pop()).Value; _g.SetColor(c1, c2, c3); }So this code reads three numbers of the stack and calls a library routine to set the color. My changed code would have to look like this:

private void SetColorRGB() { double c3 = ((Number)stack.Peek()).Value; stack = stack.Drop(); double c2 = ((Number)stack.Peek()).Value; stack = stack.Drop(); double c1 = ((Number)stack.Peek()).Value; stack = stack.Drop(); _g.SetColor(c1, c2, c3); } which is starting to get a little ugly. In reality, it doesn't have to be so bad. In my own case, I don't actually have an unprotected call to Pop in my code. Since this is part of a stack machine, it has protective wrapping to make sure unexpected things happen and handles them with aplomb. Therefore I could hide the lower-level implementation of IStack from the world and use wrapper methods.

Things that need to be in the definition of stack, however, include some more real-world usage methods:

dup (duplicate the top most entry) - in Eric's definition, this will be return Push(Peek());
Swap (swap the top two items) - in Eric's definition, this is more difficult - you'd need a peek, a pop, a peek, a pop and two pushes.
Depth (returns the total number of items) - this is easy you would have an immutable int which is incremented on push
Index (get the nth item) - you have rip n Pops then a peek

There are some more esoteric ones like Roll, Over and so on. The problem I see is that anything that is beyond the simplest definitions starts to get disproportionately complicated.

Yes, there are clear benefits to the immutability, but we start to get further and further from the world where push and pop were a single instruction and that bothers me. It's also the reason why languages like Scheme even have back doors to allow coders to violate immutability via set!, set-car! and set-cdr!

6.0 Features - Tiff Gets Ready for ECMi

Steve Hawley — Wed, 05 Mar 2008 21:28:00 GMT

DotImage supports TIFF images in a number of different ways. In prior releases we've provided feature-rich tools that allow our users to get at all the nitty gritty details of TIFF images and TIFF files. With those tools you can do just about anything you want to a TIFF, provided that you fully understand the TIFF specification.

For this release, we decided to think about TIFFs at a much higher level. We looked at customer requests, knowledge base articles and sample code and decided that we could solve many customer problems with classes that hide as much of the complexity of TIFFs as possible.

In 6.0, we've added two classes, TiffDocument and TiffPage, that allow easy, efficient manipulation of TIFFs. The things that've gotten better:

Finding information about each page. When you construct a TiffDocument, all the page information is retrieved in one shot, and it's very efficient.
Combining multiple TIFFs into one. This is a one liner now - it's easy to do.
Rearranging the pages in an existing TIFF is now done through the manipulation of a collection
Mixing and matching pages from multiple sources or inserting a page from a new image is, again, just manipulating a collection.

This type of object design is vital for ECMi. If you want to deliver customized documents to your clients on the fly, there is no better way to do it than this.

Imagine an insurance agent who wants to assemble a policy for a customer on the fly - what better way to implement this than to be able to grab stock document pieces, assemble them and then deliver to a web browser with the Atalasoft AJAX Document Viewer?

Check it out in the DotImage 6.0 release. There is also a free Windows App that lets you combine multiple TIFFs and reorder the pages by dragging and dropping thumbnail images. We give you the source, too.

Learn from the Past

Steve Hawley — Tue, 04 Mar 2008 15:26:00 GMT

I was on a Google hunt for a picture of Peter Weinberger (the 'W' in awk) on a water tower and I ran across a book I had seen once many years earlier called "Beyond Photography - The Digital Darkroom". This book is available online in a series of PDF files. In the book it describes the image processing and a little language that can be used for image processing.

There are a number of elements that are built into the language that are fantastic. It has the ability to describe a set of transformations that map pixel values from one or more source images to a destination image as well as to manipulate the image data on the way through.

Transformations can be done in Cartesian or polar coordinates or both.

The language itself has implicit looping, so you never need to worry about that.

In essence, your job is to use the language to write an expression that will be evaluated for each pixel in the image and it does the rest.

There are a number of things in the base implementation that are, well, quaint by today's standards. For example, the image dimensions are compiled into the application and default to 248x248, which is tiny. The language has a hard-coded recursive-descent parser, which is based on a spelled-out grammar. In fact, the chapter which describes the language is an excellent tutorial on how to write a parser.

The program has the facility for JIT compilation to boost performance, and is extensible to include display support.

There are a lot of nice goodies in there including recipes for image processing.

Translating this to .NET wouldn't be too hard - even easier if you used dotImage to do the image reading and writing. I would make an abstract descendant of ImageCommand that includes a method for performing the image processing. The use the expression parser to JIT compile it to CLI and instantiate a new command. This is not trivial work, but it is straightforward. It's actually not that different from the DotImage UserTransform command that lets you do any coordinate transform from one space to another, using a delegate.

Learning to Program

Steve Hawley — Wed, 13 Feb 2008 21:13:00 GMT

Short entry - this blog post is an interesting take on what you should consider doing to become an effective programmer. I agree for the most part. I would add a couple things, though.

Historically, I've discovered that I can learn the syntax/grammar of a typical programming language by reading a book in a weekend. I did it with Java, PostScript, and C#. However, in each case, I had a previous language under my belt that was close enough that I could abstract that capabilities of one language to another.

While I was, in each case, up and writing code after the weekend with the book by my side, the code did not demonstrate fluency. That came by writing code and lots of it.

I remember a guy who had been to a comic book convention and was waiting in an autograph line to meet some prominent artist. He overheard a fanboy ask him the question, "how do you become a comic book artist." The answer was, "get a really big stack of paper and a lot of pencils and start drawing." The same is true for coding or for just about anything else you want to become proficient in.

I would add a couple things to his list of things to do to become a proficient programmer:

Learn a non-trivial file specification. Learn it to the point where you can parse the files by looking at them. You will almost assuredly have to have that depth of knowledge of some spec at some point in your career. Being able to interpret a specification and, better yet, learning how to right one is valuable.
Write an interpreter or a compiler for a little language, or better yet, a complete language. Having an intrinsic understanding of how a language is implemented will improve how you write code.

Never Forget - Floating Point Sucks

Steve Hawley — Fri, 25 Jan 2008 15:28:00 GMT

There are a number things in software engineering that look like great ideas and look like the obvious and perfect solution to a particular problem. Ultimately, they fail in practice.

Floating point numbers are just such an example. It looks like they are a great way to represent elements of the set of Real numbers, so much so that diligent engineers have built silicon devices to perform operations on them in ways that are efficient.

There is a problem, though. Floating point numbers have holes in them. Even though I can write out a constant in C or Java or C# as 1.371, there is no guarantee that the actual number represented in the final executable is actual 1.371. I might get 1.37099999997 or 1.37100000000001 or something else that is very close to 1.371, but really isn't.

So let's say that you're weighting a vector like this:

double final = cx * x + cy * y + cz * z;

let's also say that x, y, and z have a known upper limit k, such that x + y + z <= 3x and each of the three coefficients is greater than or equal to 0 and less than or equal to 1 and that cx + cy + cz = 1

Under these conditions you should be able to say that final <= k

Great. Now lets consider one of the standard formulae for calculating perceptual gray:

gray = 0.299 * r + 0.587 * g + 0.114 * b

the coefficients add up nicely to 1, so this looks like it is a good formula to put into code:

static int Luminance(BYTE r, BYTE g, BYTE b)
{
    return (int)(0.299 * r + 0.587 * g + 0.114 * b); 
}

This works great - we're assuming 8 bits per component in the colors and Luminance gives me 0 for black and 255 for white. The problem happens when you bump up to 16 bit per component color:

static int Luminance(UNS16 r, UNS16 g, UNS16 b)

{

    return (int)(0.299 * r + 0.587 * g + 0.114 * b); 

}

When you apply this to white, you get 65534 not 65535. The problem is that the intermediate result is 65534.999999997 (or something like that). The rules in C for casting to int call for truncation, so that fractional part goes away and you have the wrong answer. So you say, "ah-ha! clearly you should be rounding!". I say this is the wrong solution, primarily for performance reasons, but also because you only really want to round if you need to, but the issue is hardware/type related, so since this is a platform issue, the code should be set up to be conditionally compiled for the platform.

Fixed point, which offers the hope of greater performance, fails. 16 bits of fractional part, the maximum you can use for 16 bit per component color, isn't nearly enough, again due to holes.

I've found that by treating this like a first semester calculus problem, I can get to an more appropriate solution. So I defined an epsilon that when put into the calculation creates a delta that will give us the effect that we want:

Not only that, I can use the compiler to tell me if I even need it:

#define needRgbEpsilon  ((int)(rCoef * 65535 + gCoef * 65535 + bCoef * 65535) < 65535)

Then I change my luminance code to:

return (int)(rCoef * r + gCoef * g + bCoef *b + (needRgbEpsilon ? rgbEpsilon : 0));

and I get the expected results. Now, how about performance? Well - that needRgbEpsilon #define is constant at compile time, therefore that conditional in the return folds to a constant 0 or rgbEpsilon. If it's not needed, the addition doesn't happen. If it is needed, I get the addition and pay the penalty of one additional floating point add - no more. That will be far less expensive than calling round or ceil or your other favorite library routine.

What is my rgbEpsilon? That would be telling.

Hypogastric Joggle

Steve Hawley — Tue, 22 Jan 2008 18:18:00 GMT

I've been very busy tracking down and fixing bugs, but I thought I'd pass this on from the instructions to a radio controlled helicopter:

I'm Special!

Steve Hawley — Fri, 07 Dec 2007 14:24:00 GMT

It was very thoughtful of this company to send me this e-mail, but they spelled my name wrong. Really, if you're going to get null data, handle it gracefully. "To whom it may concern," or "Dear customer," are much better alternatives.

I already know that to the company I'm just an entry in a database. There's no need to rub it in my face.

Disgusting C-ism

Steve Hawley — Mon, 29 Oct 2007 20:27:00 GMT

I wrote some code that makes some assumptions about the length of int when converted to a string. This is in code that is strictly internal and is only ever called by internal code in very controlled circumstances. Still, when I wrote that assumption, it made me a little bit itchy. I asked myself a question I frequently ask, "what can I do to make sure that the compiler will catch an error for me?"

Essentially, what I wanted was to see if sizeof(int) == 4 like this:

#if sizeof(int) == 4
#error Call Steve - his assumption on sizeof(int) was wrong and this code will fail
#endif

Actually - it's better than that - the code has enough information to make it clear how to fix the code, should this arise.

I could do a runtime check wherein I count the number of bits/bytes in an int and use that, but I'd rather make this a compiler check.

I could also use:

#if MAXINT > MY_ASSUMED_MAXINT
#error Call Steve...
#endif

but I found this little gem:

#define CCASSERT(predicate) _x_CCASSERT_LINE(predicate, __LINE__)
#define _x_CCASSERT_LINE(predicate, line) \
typedef char constraint_violated_on_line_##line[2*((predicate)!=0)-1];

This defines a new type which is an array of a length that depends on the value of a predicate and will generate an illegal type on a false predicate. Nice.

the usage in my case is:

CCASSERT(sizeof(int) == 4)

which stops the compiler cold.