Steve's Tech Talk

Generic Fiddling

Steve Hawley — Fri, 08 Aug 2008 12:34:00 GMT

I spent an hour yesterday playing with generics to get my chops up a little better. After reading Krzystof Cwalina's post on the layout of the generic collections, I came up with this little gem:

public class UniqueCollection<T> : Collection<T> { protected override void InsertItem(int index, T item) { if (Contains(item)) throw new ArgumentException("collection already contains item", "item"); base.InsertItem(index, item); } protected override void SetItem(int index, T item) { T itemAtIndex = this[index]; for (int i = 0; i < Count; i++) { if (i == index) continue; if (itemAtIndex.Equals(this[i])) throw new ArgumentException("collection already contains item", "item"); } base.SetItem(index, item); } }

This is the basis of a simple collection that ensures that all elements (that implement Equals) are unique. At this point you can derive classes from this:

public class UniqueStringCollection : UniqueCollection<string> { }

Note that this implementation is not performant for large collections - there are better ways to guarantee uniqueness, but those depend on the problem domain.

Enjoy.

Multilingual OCR

Steve Hawley — Tue, 05 Aug 2008 12:25:00 GMT

I frequently look back at the code I've designed with an eye toward improvement. Is it all that it can be? Does it do what it says with few surprises? Is it appropriately extensible?

Today, I'll look at the Atalasoft OcrEngine object. This was my first big project at Atalasoft. I designed it and built it to be interfaced as flexibly as possible with any arbitrary OCR engine, and to that end it has worked well. We have gotten prototype or production engines running with seven different OCR engines. That's seven completely different engines with different needs all running under one uniform interface. I'm proud of that - it was no mean feat.

The hardest part, however, is starting the actual engines. Each has different needs in terms of loading/locating DLLs or COM objects or finding resources. That part is pretty painful and sadly that pain gets transferred to our customers. Worse still, I can't really make it much better since those needs are out of my control. When OEM engine manufacturers ask for API feedback, I usually want changes in loading/unloading or licensing. None have made those changes (and why should they?).

Another problem has to do with how the engines express what languages they can recognize. Here's the issue - for any language, there are at least three different dimensions that determine how to recognize it: the alphabet, the lexical structure, and the syntactic structure. It looks like you should be able to bind that up into one neat package (eg, 'English' or 'Portuguese') but does that cover the differences between Brazilian Portuguese or Portuguese spoken in Portugal? What about languages that are written in both Cyrillic and Latin alphabets? What about dialects like Creole or Pidgin Languages?

In the name of expedience and keeping the .NET flavor as much as possible, I chose to use the class CultureInfo to represent the language(s) that an OCR engine can recognize. It covers most of the ground necessary in that it can distinguish between locale-based differences in cultures that share the same language: Arabic-Egyptian is different from Arabic-Jordan. The problem is that many OCR engines have feature creep in their published languages. For example, I know three engines that publish that they recognize Wolof. I won't diminish the language - 7 million people speak it - but I haven't found a way to construct a CultureInfo object that will represent Wolof. Further, I'm pretty sure that none of these engines has a dictionary for Wolof, they just take advantage of the fact that Wolof is printed with a Latin alphabet.

What should really happen is that there should be another object that represents what you really want: alphabet, dictionary or dictionaries, and possibly grammar rules. Therefore, the correct request for any Wolof-like language would be { Latin, null, null }. The problem is that, in theory, one or more of those underlying engines could magically provide a dictionary for Wolof. The problem from my end is how to expose this now. I have no engines that will tell me if there is a dictionary for a particular language - just the open ended white lie that they can recognize Moldovan or Nahuatl. In fact, I have one engine that doesn't use dictionaries ever. So here I am stuck. I know how to represent the request, but
have no engine that can help me fully honor it, so I slink back to CultureInfo and hope it's good enough.

Managed C++ and IDisposable

Steve Hawley — Fri, 01 Aug 2008 13:40:00 GMT

I'm writing some code using the new Managed C++/CLI syntax and I ran into this error:

error C2039: 'Dispose' : is not a member of 'System::IDisposable'

the code I started with was this:

image->Dispose(); // image implements IDisposable

which gave me the same compiler error, so I wanted to eliminate a class/namespace error so I rewrote it as this:

((IDisposable ^)image)->Dispose();

Which gave the above error. Yikes!

Here's the fix:

use delete. Managed C++ now hides Dispose() inside the finalizer. Just delete the object, it handles the rest. Freaky.

Giving a Technical Presentation

Steve Hawley — Thu, 31 Jul 2008 17:31:00 GMT

After attending and presenting at IPCV '80, I saw a number of presentations that could've been a lot better. I thought maybe the issue was that there weren't sufficient resources on how to give a technical presentation, so I did a quick google search for "how to give a technical presentation." There are 2.1 million results for that search.

I pored through some of the results and found that they are in line with how I try to approach technical presentations.

I'll break it down into a few things to do and a few things to avoid.

Things to Do

Know your audience and tailor your talk accordingly
Be concise
Plan one or two goals for your audience and work to meet only those goals (in the education biz, they call these "learning outcomes")
Know where you're presenting and what your equipment will be
Share your passion
Practice your talk

Things to Avoid

Reading your slides word for word
Turning your back on the audience
Reading from a script
Giving a wall of math
Skipping around a lot
Overusing gimmicks

The most important point in there is practice. Practice with people who you trust to be appropriately critical. Give your talk with a timer to ensure that you're on target. After the practice, write down all comments immediately (and verify that your understand the comments) and immediately address them. I'm pretty good at talking on the fly, but I'm way better if I've practiced a few times. After my first practice, I had these notes - some from me, some from my peers:

0 talk about outline - don't start talk right away
1 more about why sparse sampling - application info
2 need slide about accuracy
3 more visuals
4 include failing docs?
5 fix typo in in CoordinateGenerator

I addressed these right away. One that wasn't in my list was from Elaine - she told me directly to not read my slides. I made a mental note to work more on flow.

If you practice, you won't ensure success, but if you don't practice you will ensure failure.

If you're giving a technical talk, google says that there are 2.1 million reasons why you can give a good technical talk. Here are three:

A Tribute To Robert Carroll

Steve Hawley — Fri, 25 Jul 2008 14:15:00 GMT

I found out last night that my high school physics teacher, Robert Carroll, passed away very recently.

He was a teacher that was hard as nails and had it in his mind that he was going to push his students closer to their actual abilities rather than to the accepted median.

Here are his standards as I remember them:

He assigned homework practically every night and accepted nothing late without a doctor's note.
All work was turned in with a uniform heading on the paper. Anything that deviated was not graded.
All problems had to be done in given/find/solution form with the final solution boxed in. Anything that deviated was penalized heavily.
No erasing was allowed. Work that was considered to be incorrect could be crossed out with a single line. Anything that deviated was penalized.
Labs were recorded in a bound, unlined lab book. He transitioned you into labs where you wrote out the entire lab (procedure, data, conclusions), neatly and legibly. He collected lab books at random times.
Definitions for units were boilerplate: <x> is the <fundamental/derived> unit of <time/extension/volume/capacity...> in the <standard> system <defined as/based on> ... (Ex: A Newton is the derived unit of force in the MKS system, defined as 1 (kg m)/s2.

He made it clear that this was a class in which physics was used to teach us procedure. He established the procedures and made it clear what it would cost us to step outside the bounds. The first quiz that he gave was nearly impossible to pass because of the amount of detail. In fact, there were routinely students who lost more points on the quiz than were available. He graded on a curve and that was a survival mechanism. He insisted on using the ironically titled book "Modern Physics" by Charles E. Dull (and others) published in 1955. He also scheduled a mandatory test on senior skip day. And if you did something exceptionally stupid/ill-advised/dangerous you would be given the "Dufus Award" (a rebranded cheerleading trophy) for the class period - his version of a dunce cap.

In the process he did something that few other teachers did: he taught us how to study, how to solve problems, how and when to attend to detail, how to be responsible for our actions or inactions. He demanded good work and accepted little else. A lot of his students went to hardcore engineering programs and had the tools in hand to succeed. Although I did not ask him for this, he wrote honest, top-notch recommendations for college applications.

Out of frustration, my friend Mark Hamm would draw an elaborate caricature of him on the blackboard most mornings. Without missing a beat, Mr. Carroll would look over the work, erase it and deftly draw a cartoon pig with an enormous ass, with an arrow pointing it out (ie, the ham). No spite - he could dish it out and take it.

My oldest brother and his peers formed a group called the Honors Physics Consortium as a coping mechanism and went to the trouble of (eventually) self-publishing a book about their exploits.

Mr. Carroll had a very long career as a teacher: 38 years. That's 38 years of students who went through his class or roughly 800 students in his honors class that were affected by him. While not everyone agreed with his methodology, I believe his method had strongly calculated purpose and prefer to believe that the other 799 students, like me, have come to recognize the benefits of the purpose.

Rest in peace, Mr. Carroll.

Debugging Code in the GAC - the best thing since sliced bread

Steve Hawley — Thu, 24 Jul 2008 19:07:00 GMT

I've been playing around with writing a VS Project Template that includes a Wizard implemented in C#. I had done something similar many years ago when the only choice was C++, and boy have things gotten way better.

Before doing anything else, I read a lot and one thing that caught my eye was that any assembly that is to be used as an add-in needs to be signed and installed in the GAC. This is troublesome as I always assumed that debugging code built this way was going to be, well, a pain in the GAC.

Some googling time later, I found several people who had succeeded, but again with pain - I assumed that this was my lot too. Then I found this blog entry. Run. Don't walk there and read. It is step by step instructions on how to set up VS to debug code installed in the GAC. It works and it works well. Thanks Doug, for figuring this out and making it available.

This is only half the picture though - to make this a really smooth experience, I added the following to the post-build step in the "Build Events" pane.

"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil" -I "$(TargetPath)" /f

This works for Visual Studio 2005, since it has the path to gacutil built-in. The line basically means "forcibly install the assembly I've just built into the GAC".

The final bit of icing is to change the Start Action in the Debug pane to "Start external program" and set the path to:

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe

When you "run" your assembly, it will fire up a new instance Visual Studio and that will allow you to debug your IWizard derived class at the source level.

I'm so pleased at the incredible lack of pain I'm feeling. The pain was all in figuring out how to win the trivia contest before I began.

WorldComp and IPCV 08 Day 4 - Wrap Up

Steve Hawley — Fri, 18 Jul 2008 15:31:00 GMT

Day 4 was the last day and for me it was a blur. There were a number of sessions that were missing half their speakers, and my eyes were starting to glaze over from some of the talks that featured a 'wall of math'. One talk that stood out was a math professor who was spearheading an effort to create open source code to cleanly and efficiently process images from ultra low-cost CCD cameras. He explained the problem domain very well. It really made it clear as to why most cheap camera output looks like garbage. I did my presentation in the last slot on the last day. I can't say I was happy about the timing, but you gotta dance with them what brung ya. I tried to make the best of it by bringing candy to the talk and to put as much energy into it as possible. My thought was that the people who stuck through this should get rewarded, not punished for sticking with it. I felt the talk went well and I think I'll put together several blogs about how to present a technical paper. I can't say that I'm an expert, but having taught middle and some high school, I did get some good experience explaining the technical to those who were on the edge of understanding.

WorldComp and IPCV 08 Day Three

Steve Hawley — Thu, 17 Jul 2008 13:53:00 GMT

The length of the conference is certainly taking its toll. Between the long days, my body has been trying wake me up in a different time zone. Day three was dedicated to multimedia and compression. There were a number of talks that were beyond my attention span but looked worth investigating more. We also cross-pollinated a little more and looked at conferences outside of imaging, including research to try to read emotion from spoken words. There was one talk that was short and sweet which was a small bit of research to determine if compression of data for transmission is worth the cost in energy. I found it in triguing that for a particular class of processor the cost of an ADD instruction is 85 nanojoules. The idea is to determine if the cost of battery power used in running the code to compress and subsequently transmit the data is less than the cost of transmitting uncompressed data on its own. Rick and I had a nice talk with him afterwards.

WorldComp and IPCV Day 2

Steve Hawley — Wed, 16 Jul 2008 13:47:00 GMT

Day two had a great deal of work concerning feature extraction. Yesterday seemed to be about putting things into images and today was getting things out. A few things that caught my eye were some segmentation and classification work, hand tracking and identification, face tracking with pose estimation, automatic location of cracks in a highway, location of crosswalks for the blind, circle detection, and detection of pollution. One thing that is particulrly striking about this conference is its extensive multiculturalarity. I seen attendees and presenters from Spain, Italy, France, UK, Japan, Korea, China, Vietnam, India, and so on. It's quite a melange of language and culture and is a great reminder of how important it is to write culture neutral software. It's also a strong reminder of the inherent biases towards English in pretty much every accepted programming language. Thinking about this makes me think about the parallels of Latin and English for the publication of scholarly work. English is a fairly terrible language (yet some how millions of children a year manage to become conversant in it), and it must be a tremendous strain for a presenter to have to field questions in it. But it still makes me wonder if 17th century and earlier scholars faced the same challenges in communication. And lest I forget, the gender diversity is also a welcome change when coming from an industry that is traditionally male dominated.

WorldComp and IPCV 08 Day 1

Steve Hawley — Tue, 15 Jul 2008 13:43:00 GMT

I'm blogging from the road in Vegas and posting this from my phone. I'm using Opera on a WM6 device and it seems to work admirably. Our flight was delayed on the outbound side so we ended up getting 4 hours of sleep in a hotel in Milwaukee before heading on to Vegas. After a few hotel snafus, we got in to catch the last keynote about reconfigurable computing. Nifty work. A few notes in no particular order: * It's nice to see such a diverse crowd. This is truly an international conference. * The material has been fairly fascinating and there are some interesting topics. I can totally see how to create digital watermarks in images based on one of the talks, so if you need that as an Atalasoft customer, let me or sales know. * Saw some interesting work on fingerprint recognition that would apply to document binarization. * Found myself asking critical questions in nearly every session. It's good to geek out. * At the conference dinner, Rick and I picked our table and companions more or less at random and had some good partners. Time to clean up for day 2.

Off to IPCV08

Steve Hawley — Fri, 11 Jul 2008 17:47:00 GMT

Next week Rick and I will be in Las Vegas at IPCV08, part of WorldComp. In addition to being a huge industry conference with a lot of interesting sessions, I'll be presenting a paper on accelerating the Hough Transform. My session is on Thursday July 17, 4:40 in Ballroom 7 of the Monte Carlo Resort.

In the meantime, here's an app with source that I will touch on in my talk.

Don't Be Stupid (like me)

Steve Hawley — Thu, 10 Jul 2008 15:29:00 GMT

I had a frustrating situation last week. I was trying to debug some unmanaged code through a managed project and discovered that something had happened to my system such that it was impossible to start up a project with unmanaged debugging turned on. If you had it switched off, any project would run fine in the debugger. If you had it switched on, the app would crash hard with an ExecutionEngineException before entering Main.

I can't tell you what changed on my system to cause this. I had a few suspicions, but nothing that I could act upon. I reinstalled VisualStudio hoping that would solve the issue, but no go.

After losing two days, I chose to have my machine nuked from orbit. I made a checklist of all the apps that I would lose and copied my documents (stored in My Documents) to an external hard drive. I made one very stupid mistake. I assumed that source control was my friend (more so than any reasonable person should) and neglected to make a back up of my source tree. When my machine was nuked it took out all the files I had checked out. Was it really 93? Yikes. Most of those were files that I was conditionally compiling out of the existing code, so some 80 or so of those were easy to recreate by breaking the locks and redoing the work of adding in

#if USE_OLD_CODE_LIBRARY
...
#endif

Fortunately, all the "hard" work I had done had been checked in and I lost only a small amount of that code. What I had lost was mostly managed code, for which I still had copies of the compiled dll's in test rigs on my backup. I pulled those and used .NET Reflector to get back an approximation of my original code. In two days, I was back to where I was and in better shape, as I fixed one bug along the way just from reading code (and it turns out, fixed the bug I was looking for when managed debugging went away).

In total, this situation cost me four days and my stupidity cost me two of those. Hindsight tells me that I was not scrupulous enough in making a checklist of things to do before nuking a machine. "What about my source?" should have been number one on my list.

It occurs to me as well that this is exactly something that a tightly integrated source code system like tfs should be able to manage for me. Tfs knows when I save a file locally. Couldn't it also shadow my changes into the server as well? In this way my code is one save away from recovery instead of one check-in or shelve.

How to Build a Managed/Unmanaged Library

Steve Hawley — Wed, 02 Jul 2008 13:55:00 GMT

If you are tasked with exposing an unmanaged library through managed code, there are several approached that you can take. The approach you take will depend upon what format your unmanaged code is in.

If you are given an unmanaged dll, it is sensible to simply use P/Invoke to expose the functionality. This will work and will get you going quickly, but it leads to a problem of how to make sure that the dll you have is loaded. If you leave it to the OS, this means that the unmanaged dll needs to live in the same folder as the calling assembly or in the system folder. You can also change the path that is searched for loading a dll by calling a P/Invoke of SetDllDirectory, or you can manually load the dll in your own code. If you do that, your dll loader needs to be called before the first P/Invoke into the dll.

Using P/Invoke works, but may be costly in the marshaling, especially if you have to call the routine repeatedly.

What I prefer to work with is an unmanaged static library. With that, you can build a managed C++ wrapper that exposes the functionality that you need. The C++ compiler does some fairly amazing things in terms of knowing when to do unmanaged/unmanaged transitions, but sometimes it does some surprising things that will cost.

Let's assume that you are a good developer and have built a customer management API using STL collections. You might expose a method like this:

public __gc class CustomerRelations {

public:

    bool IsCustomerAvailable(String *name)

    {

        StringAdapter cstringName(name);

        vector<Customer *> customers = GetCustomers(); // lib call

            for (int i=0; i < customers.size(); i++) {

            if (cusomters[i]->MatchesName(name))

                return true;

            }

            return false;

    }

};

The problem here is that the API is chatty - it's nice to have the interface right to the metal of the vectory, but the question is, when this is compiled and linked, will the STL code be managed or unmanaged. Worse than that, if the compiler generates a managed version of one of the STL routines, it will use it in all the unmanaged code as well. In other words, code that you thought was supposed to be pure unmanaged will be doing very granular transitions between managed and unmanaged calls, and that will be be pretty much out of your control.

One way around this is to make sure that all code that is touching unmanaged APIs is also unmanaged. This can be handled by writing classes or top level functions that are themselves unmanaged and less chatty.

This works, but is prone to error - if you screw up, you may inadvertently tank your performance. I found this out, by the way, by stepping into an unmanaged library routine with unmanaged debugging off. The debugger kept executing code until it hit the next unmanaged frame, which was in the middle of deep library code in STL.

Here's the flawless solution - make the exposed API as chunky as possible. It's really tempting to give direct access to collections, but this is problematic. It's far better, if you can, to use managed collections to hold your unmanaged objects.

One approach to make sure that you don't expose anything is to use the old-school C trick of making your API completely opaque. You can do this by making two header files, one public and one private. The public one defines opaque types:

// public API

#pragma managed(push, off) namespace StupendoCustomer { typedef struct t_CustomerStruct *t_CustomerHandle; extern t_CustomerHandle GetCustomerByName(wchar_t *name); extern bool IsCustomerAvailable(wchar_t *name); extern INT32 GetCustomerCount(); extern void GetCustomers(t_CustomerHandle *arr, INT32 startIndex, INT32 count); } // namespace

#pragma managed(pop)

// private API - in a different file namespace StupendoCustomer { const UINT32 kCustomerMagicNumber = 0x00C5708e6; // arbitrary typedef struct t_CustomerStruct { UINT32 m_magic; CustomerObject *m_customer; }; } // namespace

In this case, managed code will see nothing more than an anonymous struct for the customer, whereas unmanaged code gets the actual definition of the struct. The m_magic field is a trick to put in a sanity check so that if the lower level API gets passed a pointer to something other than the real structure, it can be checked quickly.

The GetCustomerCount/GetCustomers pair is a way to show how you can hide the collection code by letting the caller allocate space for the array and then fetch elements from it. The calling code, presumably managed, would most likely wrap the objects in its own class and make a collection of those objects.

Beware that you understand who owns the pointer to the struct and who is responsible for disposing it (might also be a job for smart pointers). Chances are that if you're writing a managed wrapper for the customer object, it will have to implement IDisposable.

A Geek Chooses Lunch

Steve Hawley — Wed, 25 Jun 2008 13:55:00 GMT

Not so much on programming, but on geekery.

One local lunch spot faxes us a list of daily specials and I decided that I wanted pizza, but the question was whether to choose the $6.25 10" two topping pizza with a 12 ounce soda or split a $9.45 16" one topping pizza with a 2L birch beer. I love birch beer, so that's not a deciding factor.

What I did (and iteratively adjusted it with Elaine) was to normalize the meals into units of price per food, where the food units were square inch-liter-toppings.

So in this case you take the price divided by the area of the pizza x toppings x volume of soda. Ignoring the egregious mixing of metric and English units, this is fairly reasonable. I did the math with a calculator, but for this blog, I popped this into a spread sheet and got the following results, using πr² for area of the pizza:

The personal 2-topping pizza meal is 10.61 cents/in2-L-topping, whereas the large pizza is 2.35 cents/in²-L-topping. This is normalized, so the value of the larger pizza is clearly greater. In addition, the area of the personal pizza is 78.54 in², whereas the area of the large pizza is 201.06 in², therefore my share of the large is greater than the whole small. The soda is similar a better deal.

Rick and I shared a large with Buffalo chicken as the topping and there are left-overs for today. In addition, we answered the trivia question about encephalitis and got free garlic bread sticks. It was a good lunch. And yes, we really are that geeky.

Woo-hoo! Compiler Bug!

Steve Hawley — Fri, 13 Jun 2008 15:26:00 GMT

I just finished tracking down a Visual C++ compiler bug. This bug exists in the optimizer in VC 2003 and 2005. It does not exist in VC 2008. It only happens with optimization turned on (ie, Release build).

Finding this bug was interesting in that we had a defect reported from a customer that caused an exception to be raised when trying to load a particular image. This image had an error in it and was causing a throw deep within the codec. This looked like an easy bug to find. Unfortunately for me, unit tests would pass on my machine, but not on the build server. This turned a routine bug into a nightmare bug - the debugger was not likely to help me. What I ended up doing was taking the library that (most likely) contained the bug and built it release, and used that in the debug build on my machine. This allowed me to reproduce the bug (and proving that it was a release bug). Using divide and conquer, I found where the exception was being thrown and to my great surprise, where the catch was being totally missed.

The bug is this:

if you have a try/catch block in C++ that only calls "pure" C code, the optimizer sees an opportunity to remove the catch block as C can't throw. If however, the C code calls back into C++ and that code throws, the exception will blow past the handler.

It is arguable that C++ code called from C should never throw without catching before returning to the caller. If the catch block is outside the C, it could cause memory or resource leaks. In this particular case, the function being called was a function pointer acting as an event handler. Basically, it was signaling to the caller, "something bad has happened - I've cleaned up, now it's your turn".

To illustrate how this happens, I've created a minimal code example to reproduce it. This code is a simple C++ app that calls a C function, PerformOperation with a C++ callback. PerformOperation prints a message than calls the callback if it's non-null. The C++ implementation of the callback throws an empty class to signal a failure. The calling code should catch this error and report failure. In debug, you get correct behavior. In release, you get an unhandled exception.

File - Perf.h - a header describing an external operation in C:

#ifndef _H_Perf #define _H_Perf #ifdef __cplusplus extern "C" { #endif typedef void (*fPerformer)(); extern void PerformOperation(fPerformer pf); #ifdef __cplusplus }; // _cplusplus #endif #endif

File - Perf.c - an implementation of the function PerformOperation

#include "Perf.h" #include "stdio.h" #ifdef __cplusplus extern "C" { #endif void PerformOperation(fPerformer pf) { printf("Performing operation..."); if (pf) pf(); } #ifdef __cplusplus }; #endif

File - OptimizerBug.cpp - calls the performer from C++ with a C++ callback that throws

#include <iostream> #include <tchar.h> #include "Perf.h" using namespace std; class PerfError { }; static void CPPPerform() { throw PerfError(); } int _tmain(int argc, _TCHAR* argv[]) { bool fail = false; try { PerformOperation(CPPPerform); } catch (PerfError) { fail = true; } cout << (fail ? "fail." : "pass."); return 0; }
Here's what happens - in a debug build, you will see "Performing operation...fail." - this is correct output. In a release build, the code will crash with an unhandled exception. I need to also stress that the function PerformOperation needs to live in its own file. If it lives in OptimizerBug.cpp, the optimizer goes even further and notices that PerformOperation can be inlined, and since it's only being used once, the callback can be inlined too and that it will always throw. It's a nice chunk for call->call optimization, but it makes the bug go away. If the implementation is in a different file, the optimizer doesn't inline.

Here's the assembly output for the release build in VC 2005:

; 20 : bool fail = false; ; 21 : try { ; 22 : PerformOperation(CPPPerform); ; ; Here's the call to PerformOperation ; push OFFSET ?CPPPerform@@YAXXZ ; CPPPerform call _PerformOperation ; 23 : } ; 24 : catch (PerfError) { ; 25 : fail = true; ; 26 : } ; 27 : ; 28 : cout << (fail ? "fail." : "pass.");

; ; and here's the call to cout, operator << - you'll notice ; that the fail = true is not here. ;

push OFFSET ??_C@_05MFHHNNDH@pass?4?$AA@ push OFFSET ?cout@std@@3V?$basic_ostream@DU?$char_traits@D@std@@@1@A ; std::cout call ??$?6U?$char_traits@D@std@@@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@PBD@Z ; std::operator<<<std::char_traits<char> > add esp, 12 ; 0000000cH ; 29 : ; 30 : return 0; xor eax, eax

There is a workaround - the most basic is to refactor to never throw in a C++ callback called from C. Where this is not possible, the routine with the catch block needs to be surrounded by:

#if NDEBUG
#pragma optimize("", off)
#endif

#if NDEBUG
#pragma optimize("", on)
#endif

This bug is NOT fixed by changing the catch to catch(...) - the optimizer will take out the handler no matter what.

On a more meta level, I want to talk more about bugs that happen only in release and not in debug. These are among the most frustrating bugs as it looks like you have to shed your main tool for tracking them down - your debugger. In my case, I was able to isolate the behavior and build that particular component with release. You can still use the debugger in release, but it's not as useful as you might think since the optimizer may shift the order of operations of things and you will see some truly bizarre behavior. For example, I watched the execution of an if (condition) statement where condition was false - and the debugger stepped into the block (!!). This was because a lot of the method had been optimizer rearranged to reduce size and increase speed. I find it easier to use the Disassembly window in VisualStudio so I can better see what the compiled code is. While doing this, I spotted the missing catch block - quite the WTF.