@gongji: Personally, I too think that the check spelling method is overkill. But the HP LaserJet lab made that a rule. And when you are dealing with hundreds of engineers modifying code for the printer, it is a good safety check to have. The reason it is good because if there were a spelling error, trying to find it would be very difficult. After all, how many people first noticed my FAETURE mispelling at first glance? Once I said there was a problem there, people could see it.

@gongji: Test harness #defines should be in a global header file since all files being tested need to be compiled the same way. Debug #defines should probably be in module-level files since people tend to debug just one or a few modules at a time. You don't want to be deludged with a huge amount of debug info that you don't need.

@gongji: Unfortunately, it is the norm that fw works around hw defects. But it doesn't have to be that way. I have tried to combate that with my many Hardware/Firmware Interface courses, articles, and even a book. You can find more on my website, www.garystringham.com.

Where should these debug and test harness defines be placed? I assume it should also be in a global header file, along with product and hardware defines? I am trying to push for a single code for both simulation and product usage.

Totally with you on comments and documentation. I have seen code with many #ifdef 0's and #ifdef 1's. I guess they were used as quick/temporary bug fixes. But people are lazy. They rarely go back to add in more meaningful comments once the fix works. My blood starts to boil whenever I see such code...

@chris.j: No, I have not made changes to the slide deck. However, I have made notes of things I would want to change if I were to give this presentation again. Yes, there were several new things I talked about for which there are no slides, including stuff that came up from the online comments.

@Bob Loy: When you change the IDE, are you expected to now support old products on the new IDE? If so, then just make any necessary changes to accomodate the new IDE and then you can support old and new products on the new IDE. But if you want to support code on both old and new IDEs, then more effort would be required to make it reusable. This is where you could make more feature switches to handle IDE_this and IDE_that. But your main question I think is why is there a problem in the first place with porting code to a different IDE. That would require that all the IDE vendors get together and work out their differences and agree on the same everything, which is unlikely to happen.

Gary, thanks so much. Question: Have you changed any of the presentation slide decks since Monday? I downloaded them all at once but it seems like you've mentioned maybe squeezing a few more topics in here and there. Just want to make sure I have the latest.

Thanks Gary for the info today and last night. The first website last night has been extremely helpful. It has information in it I didn't expect like about __inline__ . I have many errors not accepting that as well.

@marsch: Advantages of run-time switching. Fewer executables to test and manage. Deploy just one binary that will work with multiple products. Allow the customer to upgrade by paying for a new feature, then downloading a new configuration file, then the feature is turned on.

@JCarlson: why not printf (a)?? Printf is a variable-argument function. You can have with one parameter, printf("hello"), and you can have it with four parameters, printf("combo %d, %d, %d", a, b, c), and so on. But CPP macros do not support variable argment lists. So,

#define PRT_DEBUG(a) printf a

makes it so that PRT_DEBUG(("hello")) and PRT_DEBUG(("combo %d, %d, %d", a, b, c)) has only one parameter, a, in both cases.

@Bob Loy Have you not run into situations where strict ANSI C implementation just doensn't address the problem? Almost every place I've worked has run into situations where there were kludges necessary that rendered the code not strictly ANSI-kosher...

Ran into a problem with comments on the preprocessor directive lines in code I was porting from an in-house language to a commercial C compiler. In-house language compiler didn't mind, but C compiler complained bitterly. Had to fix quite a few preprocessor directives to make it work.

I still have a question left unanswered from yesterday:Since C is meant to be portable, why should chainging to a different development environment mean that "you have to hit the reset button on code reuse"?

Seems like everything we've covered in this class so far, with the possible exception of build switches, should still work fine even under a different IDE.

Large complicated code base here. A few make command-line switches (most importantly the model switch) causes our make system to set up about 100 secondary build switches. Each of these build switches also turn on the respective compiler switches.

We use a lot of CPP switches, but perhaps more of the run-time, although the thought with the run-time is to allow a customer to configure the product, not necessarily differentiate products. The overhead is usually too great for that.

Another #if #endif matching trick: for those with editors that do brace matching, include an open brace in a comment on the #if (or #ifdef, or #ifndef), and include a close brace in the comment on the close brace, like so:

#ifdef JUNK //{

...

#endif //JUNK}

Now your brace matching will automatically toggle you between the #if and the corresponding #endif in the pair.

One of the first projects I had where I work was to triage hardware defects across 6 different ASICs from two venders. The code in slide 4 looks very much like what I ended up doing (with about 10 different workaround switches)

-The streaming audio player will appear on this web page when the show starts at 2pm eastern today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.

Yesterday I got called away for "a few minutes" about 1/2 hr before the session started and got back 3 hours later. I got a lot out of the archived session and Gary Stringham answers email wuestions fast.

Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.