Archive: January, 2007

An insightful blog entry by Herb Sutter on C++ exception specifications and why they’re best avoided.

This website is now also reachable under the pocoproject.org domain. This is the first step in getting the POCO Community Website off the appinf.com domain and server, where it is hosted now. If you want to link to the POCO website, please use the new domain.

Sergei Sokolov examines interesting techniques at Dr. Dobbs Journal, that improve the stability and reduce the risks of errors for C++ programming.

Here a short summary.

Step 1. Use Static Analyis

• Peer code reviews remain the best approach for finding code defects
• using a human brain to read and understand the code, looking for defects with a fresh eye
• about 60 percent of defects can be removed via code reviews
• automated static analysis effectively support this step
• two types of static analysis exists : pattern matching (based on coding practices or coding policy) and dataflow analysis
• Effective application of static analysis goes beyond buying the appropriate tools; it also requires the careful application and monitoring of processes

Step 2. Establish a Reliable Regression Base

• in average 25 percent of software defects are introduced while programmers are fixing and changing code during maintenance
• first create some regression tests before making any code changes
• There are two approaches to create such a regression test suite. Top-down by identifying the module-under-test’s high-level API and bottom-up by starting from the leaf-level functions and examine the internal paths.
• support this step by tools capable auto-generating API tests and test coverage.
• Once the test suite is in place, its execution must be automated so that it can be run on a regular and frequent basis

Step 3. Develop Unit and Regression Tests

• Once you begin writing code or fixing issues in existing code, there’s no excuse for neglecting to properly test the code you wrote
• If you have fixed a defect, tests have to be created to verify the fix

Step 4. Static Analysis and Code Review

• Once the new code passes all the checks, including a clean bill of health from static analysis and regression testing with sufficient coverage, it should be finalized by a team code review

New year, new POCO release. POCO 1.2.8 is available! This is mostly a bugfix release, although some improvements have been made to the format functions in Foundation.

Changelog:
- fixed SF# 1613906: Util/Application.h and GCC 3.3
- fixed a byte order issue (failed test) in IPv6 address formatting
- fixed SF# 1626640: Poco::Net::SocketReactor bug
- fixed client side chunked transfer encoding handling
- fixed client side persistent connection handling
- fixed SF# 1623536: HTTP Server Chunked Transfer Encoding Bug
- improved HTTP server exception text
- fixed SF# 1616294: KeepAlive HTTPServerSession patch
- fixed SF# 1616296: Trivial Poco::TaskCustomNotification patch
- fixed SF# 1619282: PurgeStrategy bug fix
- fixed SF# 1620855: Format problem
there is a new format specifier %z for std::size_t, as well as a new
flag ? for %d, %i, %o, %x meaning any signed or unsigned integer

If you ever have to code C# in exchange for food and shelter, the free C# book for C++ programmers from Charles Petzold may come handy .

Seriously now, I did not read the whole thing, but it looks like a decent introduction text, it’s free and it comes from the author with good reputation, so I wanted to share the link.

I have prepared a Wiki page containing the POCO development roadmap. There’s not much there yet, but this will for sure change in the coming days and weeks. Just keep those feature requests coming…

A Happy New Year to all friends of POCO. 2006 was a great year for POCO, with the 1.0 release in January, the adoption of the Boost license in July, and the 1.2 release in August. 2007 will be even better! A big thank you to all who contributed to POCO, in the form of code, patches, bug reports or comments!