Title: ACCU Spring Conference 2001 Roundup

Kevlin Henney opened the conference with a "less is more" keynote speech in which he tried to convince the programmers in the audience to "write less code". His focus was not on minimalism in the feature set, but rather on the need for developers to "omit needless code", and "remove to improve". "There is too much code, and not enough software" he said, pointing out that "there is no code faster than no code" and that "less code, equals less bugs", as the bugs per line of code is constant across this industry, irrespective of the size of the project.

His advice also extended to documentation, saying "if you document everything then nothing is significant", alluding to those people who would comment: i++; //increment i".

He berated both java strings (length or size?) and c++ strings ([i] or .at(i)?) for their inconsistencies, and criticised stl allocators for being complex and "fragile", with very little practical use.

He concluded that design is about embracing constraints, and that we should consider constraints and affordances,and how to reduced the latter.

Andrei Alexandrescu, Development Manager at Real Networks Inc, presented the first heavy weight lecture of the conference, describing policy classes (a technique which should be familiar in concept to those who have read my An introduction to C++ Traits article) and using the implementation of the ultimate Smart Pointer class as an example.

"Design is Choice" he told us, introducing the policy class idiom as a solution to the "evil multiplicity" of real world situations. He showed that large interfaces undermine design by compromising size, efficiency and clarity, and went on to demonstrate the limitations of a Multiple Inheritance solution, which "juxtaposes names, features and vtables", and a Template based solution, which could not specialise structure, only behaviour, and did not scale. He also claimed that the template only based solution placed an unreasonable burden on the user.

Policy based design, he explained, was a way of constructing classes with complex behaviour by combining classes called policies. Policies being a low fat variant of interface based design, and the Template Method pattern, where each policy establishes an interface to a to be implemented policy class.

The policy classes idiom is too large a subject for me to go into here, those of you interested in it might want to check out Andrei Alexandrescu's book Modern C++ Design: Generic Programming and Design Patterns Applied for a more in-depth look at this topic.

ML is a high-level functional programming language with which Gabriel Dos Reis has worked extensively. The essence of his talk was that C++ could benefit from a technique used in ML to constrain types.

He started by talking about compiler error messages: when you get something wrong and templates are involved the compiler will nearly always report an error (good) but the messages you get can be extremely verbose and unhelpful (bad). Often this is because you have more than one template function or template specialisation for a particular name and the compiler does not have sufficient type information to pick the "right" one.

His proposed solution to this problem was to extend the C++ language to allow the definition of signatures. A signature declaration looks like a class declaration except that it starts with __signature__ instead of class. When you declare a class or template class you can specify that it is associated with a particular signature. The compiler uses the signature information to enforce extra constraints on the class or template class (at instantiation time in the case of templates) and thus finds any ambiguity or mismatch problems at an early stage. For example, a method or operator specified in the signature must also appear in the class or template class being declared.

Gabriel Dos Reis is currently implementing a proof of concept of signatures using the gcc codebase and plans to submit a proposal to extend the C++ language later on this year.

In his first lecture, Herb Sutter, CTO of PeerDirect Inc, and Secretary of the ISO/ANSI C++ Standards Committee, addressed the question "Why namespaces?" and introduced the audience to the "Interface Principle". Namespaces were added to the standard after if became clear that the common C practice of prefixing identifiers in a library with a library name has its own C++ equivalent, in enclosing whole libraries in a single class, which was cumbersome, and intrusive to development. We were advised that by using namespaces we could "avoid the pollution of the global namespace", and "avoid accidental name clashes" (such as those that can happen when using libraries from multiple vendors).

The Interface Principle addresses the question: What is 'part of' a class? Consider the following example:

class X { ... };
void foo(const X & ... ) { ... };

Is foo part of X? What about now:

class X {
...
  void foo() const { ... };
};

What's the difference? Herb showed that for X all functions, including free functions, that mention X, and come with X are part of X. This doesn't just apply to C++ - consider FILE in C, and its associated functions as well.

He then went on to talk about Koening Lookup in great detail, which I don't have space to go into here, but is something that all C++ programmers should make themselves familiar with.

Namespaces, and the Interface Principle are addressed in detail in Herb Sutter's book Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions. Herb Sutter's article for Dr. Dobb's Journal "Migrating to Namespaces" is also available online, along with his Guru Of The Week #53 : "Migrating to Namespaces".

In a session billed as "intermediate/advanced", Nicolai Josuttis, C++ Standard Committee member, gave a solid if uninspiring lecture on C++ template techniques. Opening by establishing key terminology (notably "Function Template", not "Template Function", & "Class Template", not "Template Class"), he went on to discuss the problems surrounding header dependencies, and the problem with export not working.

He discussed the difference between declaration and definition and suggested that one solution to compile time problems was to #include a header containing the template declaration, and instantiate the template for specific types in a separate cpp file, observing that this technique only works when you know which types will be used in which headers, you avoid inline functions, and are prepared to accept the inevitable proliferation of files.

Debugging issues and compiler support where discussed, and Nicolai observed that with some implementations of the STL a map of strings to strings can result in symbols tens of thousands of characters long!

Nicolai 's talk finished on a light note, with a limerick which appears in the C++ ISO Standard:

So who says the C++ Standard Committee doesn't have a sense of humour!

Subtitled "Miss Conceptions", Herb Sutter opened the second day of the conference by outlining the 13 main mistakes that the software development industry makes, which in his opinion where:

Concluding that it all comes down to a Failure To Communicate.

Herb Sutter's began his third talk by asking the audience the question he ultimately aimed to answer: How do you optimise a C++ Program? He then went on to explain that it all depends on what you mean by "optimise". You could be optimising for space efficiency, in which case, would that be the space taken up by the program code? The data? The working set? Or perhaps you want to optimise for speed/time efficiency, in which case, would that be start up time? Worst case time? Best case time? Average time? Which operation? On what platform or processor? Or perhaps you wanted to optimise stability, or compile time efficiency, or time to market, or your profit margin! The point being, when you say that you will, or you are asked to, optimise a program, there are more questions that need to be answered before you continue.

That said, Herb went on to say that today he would be looking at micro optimisation (the small stuff that you should do automatically, at no cost to code clarity), improving build times, the inline keyword, and the Copy On Write 'optimisation' in a multi threaded environment.

Having pre-warned the audience that optimisation is the last thing you do ("make it clear, make it right, cut the fat"), and even then only when you have to ("1st Law of optimisation - Don't optimise. 2nd Law of optimisation - Don't optimise yet."), that by using the stl containers and algorithms you would get most of what he was about to explain for free, and that there was no substitute for profiling, he went on to focus on the standard techniques for avoiding temporary objects in C++, i.e., prefer ++i to i++, pass by reference, and avoiding implicit conversions (use explicit!).

He then moved on to the inline keyword which he explained, could do anything, including making you code faster, slower, bigger, and smaller, among other things.

Following that Herb explored build time optimisations, the key points of which were:

The discussion then moved on to the issues surrounding optimising multi threaded apps, and Copy On Write. There isn't space to go into it here, but Herb Sutters article Optimizations That Aren't (In a Multithreaded World) is available online.

The panel of C++ Standard committee members introduced this session by explaining that the C++ Standard is split into two parts, "core" and "library", and that this talk would focus on "library". It should be noted that there is a possibility that core and library, which are both currently covered by one ISO standard could be split into two separate standards in the future.

There were 300 issues submitted to the standard committee, 125 have been accepted as defects in the standard. Only 2 or 3 of these defects are real problems, most are typos and errors in examples. 16 issues were duplicates. 58 issues submitted to the committee were not defects. For example, compiler vendors sometimes submit a defect report stating that a feature of the language is "not implementable", which has actually been implemented elsewhere. There are (at time of writing) 41 new issues that have not been considered by the committee, and 25 open, that is, they have been looked at, and need to be considered further. It should be noted that missing components are not considered to be defects.

Of the defects in the standard, there are two that stand out, and these where given significant discussion time by the panel. The first of these revolves around std::vector<bool>, the second around valarray.

The subject of std::vector<bool>, is a controversial one. There are several problems with this part of the library, and they are compounded by the fact that it is in real world use (a show of hands in the room revealed one developer out of about 50). The main problem with std::vector<bool> is that it has a different interface to std::vector< ... >, that violates the stl container requirements, and that for std::vector<bool> v;, v[i].flip(); is undefined. This situation came about because the STL was a relatively late addition to the standard, and while Stepanov had intended to include proxy reference types, there was no time and they were removed, all except the one used by std::vector<bool>.

The problems with valarray, are less controversial. It simply does not work. The solution is more complex, the committee have to decide to fix it, or deprecate it. The problem with fixing it is that it may be broken on the conceptual level, and even were the standard to be fixed, it would be very hard to get vendors to support it fully, and to regain the developers' trust it. The problem with deprecating it is that deprecated features stay broken, and never really go away. In addition to this, the possible inclusion of the restrict keyword from C99, in combination with the OO Numerics/Blitz++ library, would solve most of the problems that valarray tried to.

The panel closed with a discussion with the audience on the subject of future extensions to the standard library. Those of you interested in this should note that the boost library (described later in this document) is going to be the focus for change in the future. Other libraries of interest are ACE for multi threading, and the SGI container extensions to the STL.

Alan Lenton, Technical and Creative Director for ibgames, and linux user since v1.0, gave the final keynote speech of the conference on the subject of Open Source, or to be more accurate, he addressed the much asked question: Is your (company's) product suitable for open source?

Before addressing this question directly, he then went on to separate "Open Source" into three conceptual parts:

Which poses the killer question: How do you make money out of open source? A question that is especially relevant in the post dot-com bubble economy. Alan suggests that support services are a valid revenue model, and cited ibgames as a successful example.

He then went on to list what he considers to be the strengths and weaknesses of open source development, listing the production of development tools, and applications that have been done before and are clearly defined as examples of projects that work, and rapid correction of bugs as an other benefit, although he claimed that in practice having the source does not necessarily mean that you can fix bugs yourself.

Making a joke about flameproof pants, he went on to cite what he considered to be the weakness of open source, listing choice, innovation and standards, as the key points. He explained that the problem with "choice" for companies who want to get into open source is that the development "community" has a choice, and that they can choose not to become involved with your project. Innovation within open source was criticised, and Alan suggested that this problem might stem from a clash of egos within the community, where innovative and original ideas might be ignored due to the "not invented here" syndrome. The problem with "standards" he said, was multifold, first of all was motivation to comply to standards, he told us, citing POSIX conformance in Linux as an example, second was the need for some companies to meet ISO 9000, which involves documenting process, which may be difficult with an open source project. The third 'standards' problem that open source projects may meet is that of software patents, and the subversion of standards by third parties.

The final topic covered in the session was that of "Managing your Open Source Project". His main points were getting it out, getting it noticed (SourceForge hosts 18000+ projects), getting people to work with (not for) you, code ownership, managing bug fixes, collective decisions, revision control, negative productivity, and feature creep.

Alan Lenton has posted the document Aspects of Open Source Software Development, which is based on this talk, online.

Template meta-programming is the use of templates to perform operations at compile time: this can improve both the efficiency and the type-safety of a program. Unfortunately template metaprograms are extremely difficult to write and understand; this is because they were not designed into C++, they're only possible because of an accidental combination of C++ features - i.e. template partial specialisation, typedefs and enums with expressions using compile-time constants. In 1995 Todd Verhuizen published an article Template Metaprograms in the May issue of C++ Report and thus the art was born.

Gabriel Dos Reis had an unusual approach to the subject; he started with a program written in Scheme and showed how it could be implemented as a template metaprogram. Scheme is a functional language derived from Lisp and because looping and assignment are not available to template metaprogram writers it turns out that the sort of techniques used to write functional programs are the same as you would use for writing template metaprograms.

For example, a conditional (introduced by if in most programming languages) in Scheme is implemented using a special form called cond, which is followed by one or more condition-expression pairs; the conditions are evaluated in order and the first one which is "true" (non-nil) is selected and the value of the whole conditional is the value of the true condition's expression.

The corresponding construct in template metaprogramming is partial specialisation: you define the template first of all for the general case using a standard (unspecialised) template definition and this contains the code for the "else" branch of your conditional. Then you define one or more specialisations of the template for particular types or integers (depending on what is being passed to the template as parameters) and these correspond to the if and else if branches of the conditional.

Similarly, template metaprograms follow the functional paradigm in that they use recursion instead of looping constructs such as for and while. Variables - at least variables whose value can be changed - are not available either.

Unfortunately, those of you who have no experience of defining template classes/functions will be completely lost by now but there is insufficient space here to go into more detail. I will just re-iterate the recommendation of Andrei Alexandrescu's book that is the best introduction I've found to template metaprogramming.

Boost, Beman Dawes, C++ standard library group committee member, and boost.org webmaster, told us, is a "repository of free peer reviewed portable C++ source libraries which work well with the C++ standard library".

In addition to that, boost is a website, a mailing list, a public CVS service, a public & private FTP service, and a community of volunteers, comprising of individuals, universities, businesses and other organisations. The people behind boost, we where told, have tried to engineer a culture of positivity and inclusion - for example, commercial/proprietary developers are 'included' by placing the libraries under non-restrictive licences. In addition to this, boost is inclusive of other language developers - a C++ to Python bindings library is one of the most popular downloads.

The talk then went on to outline the key points potential users of the library may want to consider. These points where:

So how do you cope with these issues? Beman suggests:

One often asked question about free libraries is: What do I (my company) have to gain by contributing to this library? Beman answered this by saying that the boost community acts as a free QA department to companies that submit a library under a suitable licence.

Boost is worth checking out, it is the future of C++, and many components of it will be up for inclusion in future revisions of the C++ library.