If you decide to work on any of the following, please let Scott know.

Articles or things that could lead to articles:

• Examination of "Big" Open-Source Cross-Platform C++ Systems.. There are now a number of fairly large cross-platform open-source C++ systems, e.g., Rotor, Mozilla, OpenOffice, etc. What does the C++ look like in such systems? What features and techniques are used/avoided? How well do development tools like lint, profilers, memory leak detectors, etc., scale up on such systems? (Several other project ideas focus on tools for C++. In every case, knowing how well such tools handle large bodies of source code would be interesting.)
• Lint-Like Tool Update. In early 1997, Martin Klaus and Scott published a review of lint-like tools for C++. It's well past time for an updated review of such tools, ideally one that tests not only out-of-the-box capabilities, but also the ability of users to write new rules. Furthermore, it would be nice to see some work address the "value proposition" questions Jack Ganssle brings up in his Embedded Systems Programming column.
• Evaluation of refactoring tools for C++. There are now several tools that claim to be able to refactor C++ programs, including Visual SlickEdit, ref++, and Xrefactory. But how well do they work? What can they do? What can't they do? How well do they interact with the preprocessor? How fast are they on big projects? What I'd like to see is a nice, meaty evaluation and review.
• Evaluation and Review of Tools for Understanding Large Code Bases. The ads for Understand for C++ are intriguing. Can it really help you understand badly written million-line programs? But Understand is not the only tool designed to help you do this. Others include Sotograph and Klocwork K7. How well do they work? What are their strengths and weaknesses?
• Boost Under the Hood. Some of the Boost components do what they do in interesting ways. boost::function, for example, can store any callable entity, but it uses no virtual functions. A boost::shared_ptr to a base class can correctly delete a derived class object, even when the base class has no virtual destructor. How are such capabilities implemented, and what general lessons can be learned from the implementation techniques? These questions are particularly relevant for the 10 TR1 libraries that are based on work at Boost.

Software project ideas:

• Lint with autofix. Current lint-like tools are an embarrassment. They do literally as little as possible. You feed them source code, they spit out a list of possible violations. That's it. They should be much more like modern-day spell-checkers, which, when they find a word they don't know, offer a list of suggestions and offer to fix your document for you. Lint and similar tools should do the same thing! For example, instead of saying something like, "You have a class with a pointer data member, but you haven't declared a copy constructor or assignment operator," why not say all that plus "Would you like me to (1) declare those functions private or (2) change the pointer data member into a std::tr1::shared_ptr or (3) change the pointer data member into a std::auto_ptr or (4) do nothing?" Such tools would be much more helpful.
• Detailed Exhibit Information. Places that exhibit things (e.g. museums, zoos, etc.) typically have a small tag with very limited information about an object on display. The tag for a painting, for example, might have the painter, title, and year of creation. The tag for an animal display might have the species, geographic range, whether it's endangered, what it eats, etc. Such limited information is sufficient only for the most superficial interest levels. If you want to know more, you're generally out of luck. But the museum or zoo certainly has more information in its databases (e.g., when they got the item, how much they paid for it, whether it has been restored (museum), whether it has had offspring (zoo), etc.), and for many exhibits, there is a wealth of information available on the Internet, too. It would be nice to have all that additional information available, e.g., via some kind of handheld device, e.g., laptop, palmtop, radio playing back audio versions of web pages, etc. Imagine if each exhibit had some form of passive electronic identification (e.g., RFID tag, GPS-based lookup, whatever) such that when you got to the exhibit, auxillary information was automatically made available to you. For example, when you approached the zoo's exhibit of ring-tailed lemurs, your handheld automatically showed you links to internet pages about them, about Madagascar (where they live), about preservation efforts for them, etc., as well as to zoo-specific pages telling you the names and personal histories of each animal on display, their relationships to one another, their medical histories, etc. That would make exhibitions much more interesting to people who want more than the most superficial overview of what they are looking at. (This would make a great undergraduate project at some college or university.)