Also-Ran Solutions

[Previous] [Next]

I wish I could say that the idea for LIMODS came to me fully formed in a dream and wrote itself. In reality, the road to "discovering" a solution to the problem of easily limiting trace statements included quite a few twists and turns. My initial thought was to recommend conditional compilation so that each source file had a #define associated with it. To see the trace statements for a particular file or set of files, you'd just need to set the #define and compile. Although the conditional compilation technique would work, I certainly didn't want to recompile every time I turned trace statements on or off in a source file. From what I've seen, developers often use the conditional compilation approach in the real world, but I preferred something more automatic than chugging through different compiles just for different trace statements.

Another possible solution involved unique trace macros. In an effort to solve the too-many-traces problem across a huge development team, I tried this approach. Each subteam received a unique trace macro for its particular section of the project. The Microsoft Foundation Class (MFC) library uses a similar approach with the internal tracing that's turned on with MFC's TRACER.EXE program. MFC's internal trace statements check a global flag variable, and if the bit assigned to a subsystem is active, the trace statements appear in the Output window. On my large team, the unique-macro approach worked for a while but started breaking down because the MFC wizards themselves generated TRACE macros and the developers were forgetting to use their unique macros. I tried to combat this problem by undefining TRACE in the source files to force the developers to use the correct macros, but I found it quite annoying to have to fix wizard-generated and third-party code. Another problem with the unique-macro approach is that it's not that extensible. You generally have to spend a good bit of time up front porting the trace macros from project to project. It also becomes a pain to maintain these macros when the program's architecture changes and when code is moved from one subsystem to another. Moreover, the unique-macro approach doesn't work with Visual Basic.

After realizing that starting from the source code side wasn't working, I tried to step back and think about the problem from an entirely different perspective. I realized that what I really needed was a way to associate a call to a tracing function with the particular source file it came from. I also needed a way to decide whether or not the tracing function call was to go through. Finally, I needed a way to toggle trace statement output from both source files and modules. When I summarized the problem this way, I had my "Eureka!" moment (though thankfully I didn't jump up naked out of the tub and run through the streets).

You might recognize the problems described in the preceding paragraph from other chapters—throughout the book, I've solved each of them independently. To build a system that limits trace statements, I just needed to tie the individual solutions together. As you'll see when I get to the section "Implementing LIMODS" later in this chapter, I was able to achieve the elusive dream of code reuse and nerdvana.



Debugging Applications
Debugging Applications for MicrosoftВ® .NET and Microsoft WindowsВ® (Pro-Developer)
ISBN: 0735615365
EAN: 2147483647
Year: 2000
Pages: 122
Authors: John Robbins

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net