Karl Wiegers

http://www.processimpact.com/

(This article was originally published in Software Development, March 1997. It is reprinted here shared for software developers, architects, managers)

A quarter-century ago, Michael Fagan of IBM developed the software inspection technique, a method for finding defects through manual examination of software work products by a group of the author's peers. Many organizations have achieved dramatic results from inspections, including IBM, Raytheon, Motorola, Hewlett Packard, and Bull HN. However, other organizations have had difficulty getting any kind of software review process going. Considering that effective technical reviews are one of the most powerful software quality practices available, all software groups should become skilled in their application.

This article describes seven common problems that can undermine the effectiveness of software reviews of any type (inspections being a specific type of formal review). I describe several symptoms of each problem, and I suggest several possible solutions that can prevent, or correct, the problem. By laying the foundation for effective software technical reviews and avoiding these common pitfalls, you too can reap the benefits of this valuable quality practice.

Participants Don't Understand the Review Process

Symptoms: Software engineers don't instinctively know how to conduct and contribute to software reviews. Review participants may have different understandings of their roles and responsibilities, and of the activities conducted during a review. Team members may not know which of their software work products should be reviewed, when to review them, and what review approach is most appropriate in each situation.

Team members may not understand the various types of reviews that can be performed. The terms "review", "inspection", and "walkthrough" are often used interchangeably, although they are not the same beast. A lack of common understanding about review practices can lead to inconsistencies in review objectives, review team size and composition, forms used, recordkeeping, and meeting approaches. Too much material may be scheduled for a single review, because participants are not aware of realistic review rates. It may not be clear who is running a review meeting, and meetings may lose their focus, drifting from finding defects to solving problems or challenging the author's programming style. Results from these points of confusion are typically missed defects, frustration, and an unwillingness to participate in future reviews.

Solutions: Training is the best way to ensure that your team members share a common understanding of the review process. For most teams, four to eight hours of training will be sufficient, though you wish to obtain additional specialized training for those who will play the role of moderator in formal inspections. Training can be an excellent team-building activity, as all members of the group hear the same story on some technical topic and begin with a shared understanding and vocabulary.

Your group should also adopt some written procedures for how reviews are to be conducted. These procedures will help review participants understand their roles and activities, so they can consistently practice effective and efficient reviews. Your peer review process should include procedures for both formal and informal reviews. Not all work products require formal inspection (though inspection is indisputably the most effective review method), so a palette of procedural options will let team members choose the most appropriate tool for each situation. Adopt standard forms for recording issues found during review meetings, and for recording summaries of the formal reviews that were conducted. Good resources for guidance on review procedures and forms are Software Inspection Process by Robert Ebenau and Susan Strauss (McGraw-Hill, 1994) and Handbook of Walkthroughs, Inspections, and Technical Reviews, 3rd Edition by Daniel Freedman and Gerald Weinberg (Dorset House, 1990).

Reviewers Critique the Producer, Not the Product

Symptoms: Initial attempts to hold reviews sometimes lead to personal assaults on the skills and style of the author. A confrontational style of raising issues exacerbates the problem. Not surprisingly, this makes the author feel beaten down, defensive, and resistant to legitimate suggestions that are raised or defects that are found. When authors feel personally attacked by other review participants, they will be reluctant to submit their future products for review. They may also look forward to reviewing the work of their antagonists as an opportunity for revenge.

Solutions: When helping your team begin reviews, emphasize that the correct battle lines pit the author and his peers against the defects in the work product. A review is not an opportunity for a reviewer to show how much smarter he is than the author, but rather a way to use the collective wisdom, insights, and experience of a group of peers to improve the quality of the group's products. Try directing your comments and criticisms to the product itself, rather than pointing out places the author made an error. Practice using the passive voice: "I don't see where these variables were initialized, "not "You forgot to initialize these variables"

In an inspection, the roles of the participants are well defined. One person-not the author-is the moderator and leads the inspection meeting. In the review courses I teach, students often ask why the author does not lead a formal inspection meeting. One reason is to remove the confrontational nature of describing a defect directly to the person who is responsible for the defective work product. I have found the best results come when both reviewers and author check their egos (and weapons!) at the door and focus on improving the quality of a work product.

Reviews Are Not Planned

Symptoms: On many projects, reviews do not appear in the project's work breakdown structure or schedule. If they do appear in the project plan, they may be shown as milestones, rather than as tasks. Because milestones take zero time by definition, the non-zero time that reviews actually consume may make the project appear to slip its schedule because of reviews. Another consequence of failing to plan the reviews is that potential review participants do not have time to take part when one of their peers asks them to join in.

Solutions: A major contributor to schedule overruns is inadequate planning of the tasks that must be performed. Not thinking of these tasks doesn't mean that you won't perform them; it simply means that when you do perform them, the project will wind up taking longer than you expected. The benefits of well-executed software technical reviews are so great that project plans should explicitly show that key work products will be reviewed at planned checkpoints.

When planning a review, estimate the time required for individual preparation, the review meeting (if one is held), and likely rework. (The unceasing optimism of software developers often leads us to forget about the rework that follows most quality activities.) The only way to create realistic estimates of the time needed is to keep records from your reviews of different work products. For example, you may find that your last 20 code reviews required an average of 6 labor-hours of individual preparation time, 8 labor-hours of meeting time, and 3 labor-hours of rework. Without collecting such data, your estimates will forever remain guesses, and you will have no reason to believe that you can realistically estimate the review effort on your future projects.

Review Meetings Drift Into Problem-Solving

Symptoms: Software developers are creative problem solvers by nature. We enjoy nothing more than sinking our cerebrums into sticky technical challenges, exploring elegant solutions to thorny problems. Unfortunately, this is not the behavior we want during a technical review. Reviews should focus on finding defects, but too often an interesting defect triggers a spirited discussion about how it ought to be fixed.

When a review meeting segues into a problem-solving session, the progress of examining the product slows to a halt. Participants who aren't equally fascinated by the problem at hand may become bored and tune out. Debates ensue as to whether a proposed bug really is a problem, or whether an objection to the author's coding style indicates brain damage on the part of the reviewer. Then, when the reviewers realize the meeting time is almost up, they hastily regroup, flip through the remaining pages quickly, and declare the review a success. In reality, the material that is glossed over likely contains some major problems that will come back to haunt the development team in the future.

Solutions: The kind of reviews I'm discussing in this article have one primary purpose: to find defects in a software work product. Solving problems is usually a distraction that siphons valuable time away from the focus on error detection. One reason inspections are more effective than less formal reviews is that they have a moderator who controls the meeting, including detecting when problem-solving is taking place and bringing the discussion back on track. Certain types of reviews, such as walkthroughs, may be intended for brainstorming, exploring design alternatives, and solving problems. This is fine, but don't confuse a walkthrough with a defect-focused review such as an inspection.

My rule of thumb is that if a problem can be solved with no more than 1 minute of discussion, go for it. You have the right people in the room and they're focused on the issue. But if it looks like the discussion will take longer, remind the recorder to note the item and ask the author to pursue solutions off-line, after the meeting.

Rarely, you may encounter a show-stopper defect, one that puts the whole premise of the product being reviewed into question. Until that issue is resolved, there may be no point in completing the review. In such a case, you may choose to switch the meeting into a problem-solving mode, but then don't pretend that you completed the review as intended.

Reviewers Are Not Prepared

Symptoms: You come into work at 7:45AM and find a stack of paper on your chair with a note attached: "We're reviewing this code at 8:00AM in conference room B." There's no way you can properly examine the work product and associated materials in 15 minutes. If attendees at a review meeting are seeing the product for the first time, they may not understand the intent of the product or its assumptions, background, and context, let alone be able to spot subtle errors. Other symptoms of inadequate preparation are that the work product copies brought to the meeting aren't marked up with questions and comments, and some reviewers don't actively contribute to the discussion.

Solutions: Since about 75% of the defects found during inspections are located during individual preparation, the review's effectiveness is badly hampered by inadequate preparation prior to the meeting. This is why the moderator in an inspection begins the meeting by collecting the preparation times from all participants. If the moderator judges the preparation time to be inadequate (say, less than half the planned meeting time), she should reschedule the meeting. Make sure the reviewers receive the materials to be reviewed at least two or three days prior to the scheduled review meeting.

When reviews come along, most people don't want to interrupt their own pressing work to carefully study someone else's product. Try to internalize the fact that the time you spend reviewing a co-worker's product will be repaid by the help you'll get from your friends when your own work comes up for review. Use the average collected preparation times to help reviewers plan how much time to allocate to this important stage of the review process.

The Wrong People Participate

Symptoms: If the participants in a review do not have appropriate skills and knowledge to find defects, their review contributions are minimal. Participants who are there only to learn may benefit, but they aren't likely to improve the quality of the product. Management participation in reviews may (but doesn't always) also lead to poor review results. If the team feels the manager is counting the bugs found to hold against the author at performance appraisal time, they may hesitate to raise issues during the discussion that might make their colleague look bad.

Large review teams can also be counterproductive. I once participated in a review (ironically, of a draft peer review process) that involved 14 reviewers. A committee of 14 can't agree to leave a burning room, let alone agree on what's an error and how a sentence should be phrased. Large review teams can generate multiple side conversations that do not contribute to the review objectives and slow the pace of progress.

Solutions: Review teams having 3 to 7 participants are most effective. The reviewers should include the work product's author, the author of any predecessor or specification document, and anyone who will be a victim of the product. For example, a design review should include the designer, the author of the requirements specification, the programmer, and whoever is responsible for integration testing. On small projects, one person may play all these roles, so ask some of your peers to represent the other perspectives. It's okay to include some participants who are there primarily to learn (an important side benefit of software reviews), but focus on people who will spot bugs.

I'm not dogmatic on the issue of management participation. As a group leader, I also wrote software, so I needed to have it reviewed (thereby setting an example for the rest of the team), and I was able to contribute usefully to reviews of other team members' products. This is very much a cultural issue, dependent on the mutual respect and attitudes of the team members. A good rule of thumb is that only a first-line manager is permitted in a review, and only if it is acceptable to the author. Managers can never join in the review "just to see what's going on."

Reviewers Focus on Style, Not Substance

Symptoms: Whenever I see a defect list containing mostly style issues, I'm nervous that substantive errors have been overlooked. When review meetings turn into debates on style and the participants get heated up over indentation, brace positioning, variable scoping, and commenting, they aren't spending energy on finding logic errors and missing functionality.

Solutions: Style can be a defect, if excessive complexity, obscure variable names, and coding tricks make it hard to understand and maintain the code. This is obviously a value judgment: an expert programmer can understand complex and terse programs more readily than someone who has less experience. Control the style distraction by adopting standard templates for project documents and coding standards or guidelines. These will help make the evaluation of style conformance more objective. Use code reformatting tools to enforce the standards, so people can program the way they like, then convert the result to the established group conventions.

Be flexible and realistic about style. It's fine to share your ideas and experiences on programming style during a review, but don't get hung up on minor issues and don't impose your will on others. Programming styles haven't come to Earth from a font of Universal Truth, so respect individual differences when it is a matter of preference, rather than clarity.

Any software engineering practice can be performed badly, thereby failing to yield the desired benefits. Technical reviews are no different. Many organizations have enjoyed excellent results from their inspection programs, with returns on investment of up to 10 to 1. Others, though, perceive reviews to be frustrating wastes of time, usually because of these seven deadly sins, not because review are inherently time-wasters. By staying alert to these common problems of reviews and applying the solutions I have suggested here, you can help make your technical review activities be a stellar contributor to your software quality program.

Introduction

Programming neat applications is one thing. But when a user informs you your software has crashed, you know it's best to fix this before adding other features. If you're lucky enough, the user will have a crash address. This will go a long way in solving the problem. But how can you determine what went wrong, using this crash address?

Creating a MAP file

Well first of all, you'll need a MAP file. If you don't have one, it will be nearly impossible to find where your application crashed using the crash address. So first, I'll show you how to create a good MAP file. For this, I will create a new project (MAPFILE). You can do the same, or adjust your own project. I create a new project using the Win32 Application option in VC++ 6.0, selecting the 'typical "Hello Word!" application' to keep the size of the MAP file reasonable for explanation.

Once created we need to adjust the project settings for the release version. In the C/C++ tab, select "Line Numbers Only" for Debug Info.

Many people forget this, but you'll need this option if you want a good MAP file. This will not affect your release in any way. Next is the Link tab. Here you need to select the "Generate mapfile" option. Also, type the switches /MAPINFO:LINES and /MAPINFO:EXPORTS in the Project Options edit box.

Now, you're ready to compile and link your project. After linking, you will find a .map file in your intermediate directory (together with your exe).

Reading the MAP file

After all this dull work, now comes the neat part: how to read the MAP file. We'll do this by using a crash example. So first: how to crash your application. I did this by adding these two lines at the end of the InitInstance() function:

char* pEmpty = NULL;									
*pEmpty = 'x';	// This is line 119							

I'm sure you can find other instructions which will crash your application. Now recompile and link. If you start the application, it will crash and you'll get a message like this: 'The instruction at "0x004011a1" referenced memory at "0x00000000". The memory could not be "Written".' .

Now, it's time to open the MAP file with notepad or something similar. You MAP file will look like this:

The top of the MAP file contains the module name, the timestamp indicating the link of the project, and the preferred load address (which will probably be 0x00400000 unless you're using a dll). After the header comes the section information that shows which sections the linker brought in from the various OBJ and LIB files.

MAPFILE											
											
 Timestamp is 3df6394d (Tue Dec 10 19:58:21 2002)					
											
 Preferred load address is 00400000							
											
 Start         Length     Name                   Class					
 0001:00000000 000038feH .text                   CODE					
 0002:00000000 000000f4H .idata$5                DATA					
 0002:000000f8 00000394H .rdata                  DATA					
 0002:0000048c 00000028H .idata$2                DATA					
 0002:000004b4 00000014H .idata$3                DATA					
 0002:000004c8 000000f4H .idata$4                DATA					
 0002:000005bc 0000040aH .idata$6                DATA					
 0002:000009c6 00000000H .edata                  DATA					
 0003:00000000 00000004H .CRT$XCA                DATA					
 0003:00000004 00000004H .CRT$XCZ                DATA					
 0003:00000008 00000004H .CRT$XIA                DATA					
 0003:0000000c 00000004H .CRT$XIC                DATA					
 0003:00000010 00000004H .CRT$XIZ                DATA					
 0003:00000014 00000004H .CRT$XPA                DATA					
 0003:00000018 00000004H .CRT$XPZ                DATA					
 0003:0000001c 00000004H .CRT$XTA                DATA					
 0003:00000020 00000004H .CRT$XTZ                DATA					
 0003:00000030 00002490H .data                   DATA					
 0003:000024c0 000005fcH .bss                    DATA					
 0004:00000000 00000250H .rsrc$01                DATA					
 0004:00000250 00000720H .rsrc$02                DATA					

After the section information, you get the public function information. Notice the "public" part. If you have static-declared C functions, they won't show up in the MAP file. Fortunately, the line numbers will still reflect the static functions. The important parts of the public function information are the function names and the information in the Rva+Base column, which is the starting address of the function.

  Address         Publics by Value              Rva+Base     Lib:Object			
 0001:00000000       _WinMain@16                00401000 f   MAPFILE.obj		
 0001:000000c0       ?MyRegisterClass@@YAGPAUHINSTANCE__@@@Z 004010c0 f   MAPFILE.obj	
 0001:00000150       ?InitInstance@@YAHPAUHINSTANCE__@@H@Z 00401150 f   MAPFILE.obj	
 0001:000001b0       ?WndProc@@YGJPAUHWND__@@IIJ@Z 004011b0 f   MAPFILE.obj		
 0001:00000310       ?About@@YGJPAUHWND__@@IIJ@Z 00401310 f   MAPFILE.obj		
 0001:00000350       _WinMainCRTStartup         00401350 f   LIBC:wincrt0.obj		
 0001:00000446       __amsg_exit                00401446 f   LIBC:wincrt0.obj		
 0001:0000048f       __cinit                    0040148f f   LIBC:crt0dat.obj		
 0001:000004bc       _exit                      004014bc f   LIBC:crt0dat.obj		
 0001:000004cd       __exit                     004014cd f   LIBC:crt0dat.obj		
 0001:00000591       __XcptFilter               00401591 f   LIBC:winxfltr.obj		
 0001:00000715       __wincmdln                 00401715 f   LIBC:wincmdln.obj		
 //SNIPPED FOR BETTER READING								
 0003:00002ab4       __FPinit                   00408ab4     <common>			
 0003:00002ab8       __acmdln                   00408ab8     <common>			
 entry point at        0001:00000350							
 Static symbols										
 0001:000035d0       LeadUp1                    004045d0 f   LIBC:memmove.obj		
 0001:000035fc       LeadUp2                    004045fc f   LIBC:memmove.obj		
  //SNIPPED FOR BETTER READING								
 0001:00000577       __initterm                 00401577 f   LIBC:crt0dat.obj		
 0001:0000046b       _fast_error_exit           0040146b f   LIBC:wincrt0.obj		

The public function part is followed by the line information (you got this if you used the /MAPINFO:LINES in the Link tab and selected the "Line numbers" in the C/C++ tab). After this, you will get the export information if your project contains exported functions and you included /MAPINFO:EXPORTS in the link tab.

Line numbers for .\Release\MAPFILE.obj(F:\MAPFILE\MAPFILE.cpp) segment .text    	
    24 0001:00000000    30 0001:00000004    31 0001:0000001b    32 0001:00000027	
    35 0001:0000002d    53 0001:00000041    40 0001:00000047    43 0001:00000050	
    45 0001:00000077    47 0001:00000088    48 0001:0000008f    52 0001:000000ad	
    53 0001:000000b3    71 0001:000000c0    80 0001:000000c3    81 0001:000000c8	
    82 0001:000000ff    86 0001:00000114    88 0001:00000135    89 0001:00000145	
   102 0001:00000150   108 0001:00000155   110 0001:00000188   122 0001:0000018d	
   115 0001:0000018e   116 0001:0000019a   119 0001:000001a1   121 0001:000001a8	
   122 0001:000001ae   135 0001:000001b0   143 0001:000001cc   172 0001:000001ee	
   175 0001:0000020d   149 0001:00000216   157 0001:0000022c   175 0001:00000248	
   154 0001:00000251   174 0001:0000025f   175 0001:00000261   151 0001:0000026a	
   174 0001:00000287   175 0001:00000289   161 0001:00000294   164 0001:000002a8	
   165 0001:000002b6   166 0001:000002d8   174 0001:000002e7   175 0001:000002e9	
   169 0001:000002f2   174 0001:000002fa   175 0001:000002fc   179 0001:00000310	
   186 0001:0000031e   193 0001:0000032e   194 0001:00000330   188 0001:00000333	
   183 0001:00000344   194 0001:00000349						

Now we will look up where the crash occurred. First, we'll determine which function contains the crash address. Look in the "Rva+Base" column and search the first function with an address bigger than the crash address. The preceding entry in the MAP file is the function that had the crash. In our example our crash address is 0x004011a1. This is between 0x00401150 and 0x004011b0 so we know the crash function is ?InitInstance@@YAHPAUHINSTANCE__@@H@Z . Any function name that starts with a question mark is a C++ decorated name. To translate the name, pass it as a command-line parameter to the Platform SDK program UNDNAME.EXE (in the bin dir). You won't need to do this most of the time as you might figure it out just by looking at it (here: InitInstance() in MAPFILE.obj).

This is a big step for bug tracking. But it gets even better: we can find out on which line the crash occurred! We need to do some basic hexadecimal mathematics, so people whom can't do this without a calculator: now is the time to use it. The first step is the following calculation: crash_address - preferred_load_address - 0x1000
Addresses are offsets from the beginning of the first code section, se we need to do this calculation. Subtracting the preferred load address is logical, but why do we need to substract another 0x1000? The crash address is an offset from the beginning of the code section, but the first part of the binary isn't the code section! The first part of the binary is the Portable Executable (PE), which is 0x1000 bytes long. Mystery solved. In our example, this is: 0x004011a1 - 0x00400000 - 0x1000 = 0x1a1

Now it's time to look in the line information section of the MAP file. The lines are shown like this: 30 0001:00000004. The first number is the line number, the second number is the offset from the beginning of the code section in which this line occurred. If we want to look for our line number, we just have to do the same thing we did for the function: determine the first occurrence of a bigger offset than the one we just calculated. The crash occurred in the preceding entry. In our example: 0x1a1 is before 0x1a8. So our crash occurred on line 119 in MAPFILE.CPP.

Keeping track of MAP files

Each release had it's own MAP file. It's not a bad idea to include the MAP file with the exe distribution. This way, you can be certain you have the correct MAP file for this exe. You could keep every MAP file with every exe on your system, but we all know this might give some troubles later on. The MAP file doesn't contain any information you wouldn't want the user to see (unless maybe class and function names ?) . A user would have no use with it, but at least you can ask for the MAP file if you don't have a copy yourself.

Acknowledgements

John Robbins for his "Debugging Applications" book

License

About the Author

Quoted from    http://www.research.att.com/~bs/applications.html

C++ Applications

Modified December 2, 2008

Here is a list of systems, applications, and libraries that are completely or mostly written in C++. Naturally, this is not intended to be a complete list. In fact, I couldn't list a 1000th of all major C++ programs if I tried, and this list holds maybe 1000th of the ones I have heard of. It is a list of systems, applications, and libraries that a reader might have some familiarity with, that might give a novice an idea what is being done with C++, or that I simply thought "cool".

Here is a link to a Chinese translation.

I (Bjarne Stroustrup) don't make any guarantees about the accuracy of the list. I believe that it's accurate -- I trust the people who sent me examples, but I have not seen the source code myself. I have a preference of C++style code over code that are called C++ eventhough it is mostly C and try to avoid list C or "almost C" programs. Many of the detailed descriptions are the words of the respective systems' developers and users, rather than mine.

The organization of this list is idiosyncratic. Where a set of applications are clearly associated with a single organization, I list it under the name of that organization, but some systems doesn't fit that pattern.

No, I don't know what all the acronyms mean. Yes, I do list something as C++ even if it relies on non-standard extensions. Yes, I'd appreciate more examples -- especially major applications. If you send one, a URL to a support site would be appreciated. No, I will not list an application, system, or library unless I think the listing will be of interest to a lot of people -- I'm emphatically not trying to make a complete list. No I will not list an application before it is in wide-spread use (sorry); this list is meant to demonstrate major use and as such it would be weakened by including new products. I make no pretensions of "fairness", such as promising to list all competing products in an area if I list one -- this is a list trying to give an overall impression, not a list to help you select a product. I rewrite descriptions as little as possible, but I do remove obvious advertising.

Thanks to all who sent me examples. Suggestions for additions and corrections are welcome.

Other people's lists:

• Who's Using Boost?
• ACE and TAO users
• Major industry applications and tools with evolution path.

Applications clearly associated with a single organization:

• 12D Solutions: Computer Aided Design system for surveying, civil engineering, and more.
• Adobe Systems: All major applications are developed in C++:
  • Photoshop & ImageReady,
  • Illustrator,
  • Acrobat,
  • InDesign,
  • GoLive,
  • Frame (mostly C, some C++)
• Alias|Wavefront: Maya. Maya has been used in the production of just about every major film involving computer-generated effects since its release, including Star Wars Episode I, Spider-Man, Lord of the Rings, Stuart Little, etc. "I love 3d animation".
• Amadeus: running the biggest non-military datacenter in Europe (in excess of 5000 transactions per second, 200000 terminals connected, 24/7 operation) is doing most of its current developments in C++. All Unix-based server applications are completely C++. Some of them:
  • Car reservation
  • Customer profile server
  • Electronic ticketing
  • TCP/IP front end
• Amazon.com: Software for large-scale e-commerce.
• Apple: OS X is written in a mix of language, but a few important parts are C++. The two most interesting are
  • Finder
  • IOKit device drivers. (IOKit is the only place where we use C++ in the kernel, though.)
  Also,
  • AppleWorks
  • the iPod user interface (uses Pixo application framework written in C++)
  • "Of the thousands of Macintosh applications that have shipped I estimate that over half were written C++".
  • Frameworks: There are three major C++ application frame works developed for Macintosh: Apple's MacApp (some MacApp applications), Symantec's Think Class Libraries, and Metrowerks' PowerPlant. There are also a number of smaller (in market share) frameworks that have been developed.
• Arium: Sourcepoint; Hardware debugging and emulation for Intel and ARM systems (incl. multi-processor systems).
• AT&T: The largest US telecommunications provider.
  • 1-800 service
  • provisioning systems
  • systems for rapid network recovery after failure
• Autodesk: A large number of major number of application in the CAD domain.
• BeOS: a multiprocessor multimedia personal operating system.
• BigFix, Inc.: BigFix is a communication system for delivering technical support information to the people for whom it is relevant and timely. It is used by companies such as Autodesk and eMachines to support both software and hardware. All BigFix products are written in C++.
• Bloomberg: Providing real-time financial information to investors.
• Cabot Communications: Portable set top box and digital TV software (incl. ISO MHEG-5).
• Caldera: OpenWBEM open source implementation of the WBEM standard for system management software is written in C++ (www.openwbem.com). This uses more new C++ 98 features than almost any source base I've seen outside of those done by the standards community itself.
• callas Software: software for the analysis, correction and optimization of PDF files: pdfInspektor, Acrobat Preflight and other plug-ins.
• CERN: Data analysis - especially for large high-energy physics experiments - using the ROOT toolset and libraries.
• Codemill:
  SuperDoc: A PalmOS document reader, notable for fast font anti-aliasing.
  • SecurityContext: A Win32 COM component to simplify the querying of the OS security context of the current thread.
  • Map: A Win32 COM component that provides a thread-safe map (as in std::map) of COM Variant data types e.g. for data cacheing within IIS web applications.
• Code Synthesis Tools: Provides XSD, an XML data binding generator for C++ with support for in-memory and stream-oriented processing models. XSD is written in portable C++ and compiles with a wide range of C++ compilers. XSD is used in telecommunications, finance, high-performance computing, and integrated circuit design.
• Coverity: Static source code analysis tool for C and C++ written in C++. Used for finding Linux bugs.
• CoWare: system/chip specification in C++.
• Credit Agricole Indosuez Cheuvreux: uses C++ exclusively for tracking orders on the European stock markets.
• Dantz Development Corporation: Retrospect backup software for Windows.
• D-Cubed: Components for geometric constraint solving, motion simulation, collision detection, hidden line removal and profile management. Our emphasis is on accuracy and speed. Used in the vast majority of CAD applications (e.g. CATIA, SolidWorks, AutoCAD, NX, SolidEdge).
• D E Shaw: Financial analysis and trading software.
• Digiquant: Internet Management System (IMS), infrastructure software fo services over IP-based networks. Some of the C++-based elements of IMS are extendable AAA Server, Service provisioning, Rating Engine, and Port Server.
• Dassault Systems: Catia v5; leading CAD software, on which was conceived all recent Airbus planes (A380, ...). Also, Boeing 787 software. Entirely written in C++, using STL.
• Dutch ministry of transport, public works, and water management: surge barrier control. The BOS control system for the Maeslant Barrier protecting Rotterdam from flooding. This safety-critical system (highest safety integrity level according to IEC 61508) is built using C++, Z and PROMELA. A high level overview with nice pictures can be found here.
• Efficient Networks: (a wholly owned subsidiary of Siemens) has sold more than 8 million licenses worldwide of its PPPoE client software for Macintosh, Windows and Linux systems. Products often are distributed under ISP brand names. New Macintosh development is wholly C++; Windows development is a mix of C and C++. Products using C++ include
  • EnterNet: PPPoE client drivers and settings applications
  • Tango Qualifier: pre-purchase evaluation of user environment
  • Tango Installer: a wizard-like installer program
  • Tango Access: PPPoE client drivers and settings applications
  • Tango Support: user-level network diagnostic tools
• Ericsson:
  • TelORB - Distributed operating system with object oriented
  • distributed RAM database, The base for the TSP application
  • server platform.
  • TDMA-CDMA HLR
  • GSM-TDMA-CDMA mobility gateway
  • AAA server.
• FlightGear: an open source flight simulator, using JSBSim, one of the flight dynamics math models used in FlightGear and by other simulators.
• Geant4: Toolkit for the simulation of particles interaction with matter for use in High Energy and Nuclear Physics experiments, Space, and Medical applications. The Geant4 project is a world-wide collaboration of about 100 scientists participating in more than 10 physics experiments in Europe, Russia, Japan, Canada and USA. It involves the participation of several national and international institutes and organizations. The software is entirely written in C++ and has been developed exploiting Object-Oriented methodologies and tools. It consists of roughly 500K lines of code and includes the implementation of a rather wide set of state-of-the-art algorithms and theoretical models for electro-magnetic and hadronic physics interactions.
• Google: web search engine, etc.
  • Chromium browser.
  • Google file system.
  • MapReduce large cluster data processing.
• Havoc: Real-time physics for animation and games. "Havok, like Guinness, is made in Ireland.
• HP: Here is a tiny fraction of HP's C++ apps:
  • C, C++, Fortran90 compilers, and linker for the new HP IA64 platform (these add to more than 1 million lines of C++ code).
  • SAM (HP's system management utility)
  • Some of the networking libraries in HP-UX
  • Java VM core
  • Parts of Openview
  • Non-stop XML parser (originally from compaq)
• IBM:
  • OS/400.
  • K42: a high performance, open source, general-purpose operating system kernel for cache-coherent multiprocessors.
• Image Systems: TrackEye and TEMA, the world leading motion analysys programs (based on digital image processing). Used by most car manufacturers to analyse the effects of crash tests. Also used by car and aircraft manufacturers to analyse the performance of new models, "in short wherever high-speed sequences are used".
• Intel:
  • Vtune performace analysis software
  • compilers and optimizers
  • lots of chip design and manufacturing software.
• Intuit: Quicken (personal financial software).
• ILOG: At ILOG, we provide libraries written in C++ used for:
  • Visualization. This set of libraries is used to build applications that needs portable GUI's and advanced graphical features.
  • Optimization. This set of libraries is used to build programs that needs constraint programming or/and the simplex algorithm.
  • Rules. This set of libraries is used to build applications that needs a rule engine to fire actions according to events that may happen.
  Here are some customers I'm aware of: Chrysler, EDF, CENA, Nortel, SAP, Alcatel, Renault, Manugistics, Communaut urbaine de Lyon (Traffic regulation in the city of Lyon), Parc Technologies Ltd, Barclays Global Investors (BGI), TLC (Transport, Informatik- und Logistik-Consulting GmbH) subsidiary of Deutsche Bahn, DoD's Joint Operational Support Airlift Center (JOSAC), Telefonica, CISCO, NISSAN, POSCO, Sony Bank, isMobile, Southwest Airlines, Novient, Vodafone TeleCommerce, Sabre Holdings Corporation, France Telecom, Ericsson, Deutsche Telekom, Lucent Technologies, MCI WorldCom, Siemens, First Union Home Equity Bank, Baan, HP, Adonix, Peugeot, ARINC, McHugh.
• JPL (Jet Propulsion Lab, NASA): Mars rover autonomous driving system (incl. scene analysis and route planning). C++ on Mars! Also lots of supporting software "on the ground" (i.e. Earth).
• KLA-Tencor: Semiconductor manufacturing systems.
• Looksmart is predominantly written in C++. All products related to searching and exploring the web are written in C++. Used by well over 5,000,000 unique users per day.
• MAN B&W Diesel A/S: Purveyers of engines for large and very large ships (such as container ships and tankers).
  • Electronic controlled fuel injection and exhaust valve control system for very large (up to more than 100.000 break horse power) two stroke diesel engines. Hard real-time system running on medium size embedded system. Absolutely critical 24/7 operation with distributed, redundant error recovery. Written entirely in high performance, high level C++, except for a few hundred lines of assembler code.
  • Several large support systems for engines and crew running on desktop machines, written entirely in C++.
  • Several internal business critical applications, for engine design calculations and design information storage."
• Medimage: all products: These products range from medical image display systems to custom communications software which move images from one machine to another via modems and TCP/IP. We build our products for both Mac OS and Windows computers.
• Mentor Graphics: Since the 1980s Mentor Graphics has built most of its applications using C++, including:
  • Calibre: software for IC physical verification, manufacturing, and resolution enhancement.
  • Formal Pro: formal verification equivalency checker which enables multi-million gate ASIC and SoC verification.
  • FastScan: automatic test pattern generation tool for ASICs and ICs.
  • FlexTest: test pattern generation for optimizing test coverage.
  • TestKompress: tool suite which reduces ATE memory and time requirements for testing by up to 10 times.
  • MachTA/PA: fast, accurate, high capacity, transistor-level circuit simulation for timing and power analysis of DSM and mixed-signal IC designs.
• Metrowerks is a leading provider of software development tools. The CodeWarrior Integrated Development Environment (IDE), RAD plugins and PowerPlant, our object oriented class library, are all written in C++. Their website has a description of some cool applications, such as 3-D animation, real-time Web conferencing, and satellite control technology.
• Microsoft: Literally everything at Microsoft is built using various flavors of Visual C++ - mostly 6.0 and 7.0 but we do have a few holdouts still using 5.0 :-( and some products like Windows XP use more recent builds of the compiler. The list would include major products like:
  • Windows XP
  • Windows NT (NT4 and 2000)
  • Windows 9x (95, 98, Me)
  • Microsoft Office (Word, Excel, Access, PowerPoint, Outlook)
  • Internet Explorer (including Outlook Express)
  • Visual Studio (Visual C++, Visual Basic, Visual FoxPro) (Some parts of Visual Studio like the Base Class Libraries that ship with the .NET Framework were written using C# but the C# compiler itself is written in C++.)
  • Exchange
  • SQL
  There are also "minor" products like:
  • FrontPage
  • Money
  • Picture It
  • Project
  • and all the games.
• Morgan Stanley: a large chunk of their financial modelling.
• Mozilla: Firefox browser and Thunderbird mail client (open source).
• MySQL: MySQL Server (about 250,000 lines of C++) and MySQL Cluster. Arguably the world's most popular open source database.
• Nokia:
  • Mobile Communications radio-station/internet bridges: FlexiGGSN (Gateway GPRS Support Node) and FlexiSGSN (Server GPRS Support Node).
  • MSC/HLR
• The National Census Bureau of Israel is written mostly in C++, with some components of embedded SQL. It serves millions of transactions per month, starting with birth and death registration, naturalization, passport issuance, visas and so on for 8 million civilians and foreign workers.
• Netopia:
  • Timbuktu Pro -- Remote control, file exchange, and collaborative tools for Macintosh and Windows. Timbuktu Pro is up to about 10,000,000 installed nodes and is in 70% of Fortune 500 companies. The Mac version has won numerous awards over the years and the Windows version just won the 2002 World Class Award From PC World.
  • netOctopus -- Network-based system management for Macintosh and Windows. "4000 sites ... maybe 150 agents (managed systems) are installed at each site, which would make about 600,000 systems.".
  • eSite -- Web site server platform used by several Yellow Pages companies to provide web sites to advertisers.
  • eCare -- Web-based customer support. The Macintosh and Windows clients are in C++.
• Nullsoft: All Nullsoft products are C++ (Winamp, NSI, etc.) and many are open source.
• Programming Research: QAC++: Analysis product for C++.
• Radiometer Medical A/S: Advanced medical instruments and applications handling patient-critical information on daily basis in over a thousand hospitals worldwide.
  • Bloog-gas analyzers: Medical blood analysis instruments running a database-based application. Appart from the GUI, this application is entirely written in C++
  • Blood-gas instruments management system: Distributed data management application written entirely in C++ (using the ACE framework in TAO CORBA), providing monitoring and reporting facilites.
• Rain Bird Corporation: Maxicom2 irrigation control system. A Maxicom2 controls the irrigation for a large commercial site or distributed sites from a single central control PC. Communication with remote distributed controllers is via dialup telephone, cellular, radio, fiber optics, etc. Users include: Major amusement/theme parks, international airports, several colleges, county parks, and corporate headquarters.
• Reliable Software: Co-op, A peer-to-peer version control system.
• Renaissance Technologies: Financial analysis and trading software.
• SAP DB: an "Enterprise Open Source Database" is written in a mix of Pascal, C and C++. But newer parts and rewrites of older parts are implemented in C++: "Release 7.4: 1088 C++ of 3392 source files".
• Scansoft: Dragon Naturally Speaking. An award winning continuous speech dictation system. Originally developed by "Dragon Systems".
• SGI: OpenInventor, a 3D graphics framework and tool kit built on top of OpenGL. Open Inventor serves as the basis for the VRML (Virtual Reality Modeling Language) standard.
• Siemens: Major medical systems (often using ACE for convenience and portability).
• Sophis: Cross-asset, front-to-back portfolio and risk management solutions: "sed world-wide by leading financial institutions".
• Southwest airlines: Their website, flight reservations, flight status, frequent flyer program, etc.
• Sun:
  • The HotSpot Java Virtual Machine is written in C++ (this is the leading edge, high performance replacement for Sun's "classic JVM" which was written in C).
  • Sun's compilers have major components written in C++, in particular the C++ front end, parts of the Fortran 95 front end, and the SPARC back end.
  • Parts of Solaris are written in C++, though the external interface is usually crafted to look like C, for compatibility and stability reasons.
  • OpenOffice "The Open Source Office Suite": "[...] the whole technology is based on a platform-independent approach. Less than 10% of the code is platform dependent. This acts as an abstraction layer for the upper software components. Because of the availability of C++-Compilers on every major platform, C++ is used as an implementation language. This allows to port the OpenOffice.org technology to a wide range of different platforms." "[...] It is a complex application consisting mainly of C++ code employing templates and exception handling and supporting independent language binding for a distributed component based architecture."
• Symbian OS: rationale: "[...] using C++ for all system code, from the kernel upwards." This is one of the most widespread OS's for cellular phones.
• UIQ Technology: UIQ, an open software user interface platform for mobile phones, used by the world's leading mobile phone manufacturers. It is for phones running the Symbian OS. UIQ 3 is used in the Sony Ericsson M600, P990 and W950.
• University of Karlsruhe: L4Ka: pistachio, a microkernel implemented in pure C++.
• Vodaphone: Mobile phone infrastructure, incl. provisioning and billing.
• wxWidgets (formerly wxWindows): Cross platform widget set / toolkit (open source).
• WAM!NET: "Transmission Manager" ISDN and TCP/IP-based data transfer software, formerly known as 4-Sight ISDN Manager - integrates ISDN support with the software to connect to WAM!NET's managed WAN.
• ZeroC: Provides ICE, a distributed object-oriented computing infrastructure with a modern C++ mapping. ICE is written in portable C++ and compiles with a wide range of C++ compilers. ICE is used for games and massive training simulations.

  Application areas and applications not clearly associated with a single organization:

• The CDE desktop (the standard desktop on many UNIX systems) is written in C++.
• Computational Geometry: CGAL Open Source Project, the Computational Geometry Algorithm Library, provides state of the art geometric data structures and algorithms. The major design goals are high performance, robustness and flexibility. To achieve the latter the designers of CGAL opted for the generic programming paradigm, and gave CGAL the look and feel of the STL. It is also commercially available as supported product from the GeometryFactory.
• CORBA ORBs: MICO, omniORB, Orbix, TAO.
• Games: Doom III engine. Sierra On-line: Birthright, Hellfire, Football Pro, Bullrider I & II, Trophy Bear, Kings Quest, Antara, Hoyle Card games suite, SWAT, and too many others to list... Blizzard: StarCraft, StarCraft: Brood War, Diablo I, Diablo II: Lord of Destruction, Warcraft III, World of Warcraft. Quicksilver: Shanghai Second Dynasty, Shanghai Mah Jongg Essentials, Starfleet Command, Invictus, PBS's Heritage: Civilization and the Jews, Master of Orion III, CS-XII. Microsoft: all games. EA: video game engine. Byond: a "world" development platform.
• Interactive graphics:
  • Virtual Harlem (project at University of Illinois at Chicago and Central Missouri State University) is a learning environment that lets students experience the Harlem Renaissance of the 1920s and 1930s as a cultural field trip. Virtual Harlem is built on top of on top of a high-level VR scripting framework called Yggdrasil written in C++ using other C++ Libraries and freameworks:
    • SGI's OpenGL Performer graphics library.
    • CAVElib VR library.
    • CAVEGui is a graphical interface tool that provides interaction with a CAVE application.
    • CAVERNsoft G2 an Open Source C++ ready2ware toolkit for building collaborative networked applications.
    • COANIM (or the Collaborative Animator) is the application for viewing 3D content over AGAVE. The overall concept behind AGAVE is to append a low-cost PC-based graphics workstation to an Access Grid node that can be used to project 3D stereoscopic computer graphics to allow collaborators to share 3D content.
    • Coin is a high-level 3D graphics librarwith a C++ Application Programming Interface. Coin uses scenegraph data structureto render real-time graphics suitable for mostly all kinds of scientific anengineering visualization applications.
    • Agave: Access grid augmented virtual environment.
• KDE from linux is written in C++. K Desktop Environment, is a powerful Open Source graphical desktop environment for Unix workstations. It is one of the leading desktop environments for Linux. It consists of about 300 different packages written in C++, including an office suite, a browser, development tools, games, and multimedia apps.
• a major ballistic missile defense system being done using C++.
• telephone systems: I think it would be almost easier to list the systems which aren't written in C++, at least here in Europe:
  • C++ is the only development language used for Alcatel transmission systems, both for network management (using ILog Views) and the actual transmission equipment. FWIW, the major transmission nodes (Frankfurt, Berlin, Munich, and another somewhere in northern Germany -- Cologne or Hamburg, I think) in Germany are all 100% C++. All telephone calls between different regions in Germany pass through one of these machines.
  • T-Mobile (the largest German cellular operator) uses C++ for both its billing system and for most of its WAP portal -- dynamic allocation of IP addresses, etc.
  Put differently, anyone using a telephone in Germany depends on code written in C++ -- that's a lot of users:-). What counts as a user? The main telephone transmission nodes in Germany (and I'm pretty sure France as well) are written in C++. And I can't imagine anyone in the country who doesn't use a telephone -- does that count as 80 million (140 million with France) users of C++?
• SETI@home Huge collaborative project to analyse data to find signs for extraterrestrial life. Partly written in C++.
• Web development support library Poco. Here is list of poco users.