"The C++ Community" - Are We Divided by a Common Language?

Recent discussions on the WG2 "core" reflector^[1] have involved considerable speculation about the proportions of the C++ community that employ different memory management strategies. While the comparative sizes of their constituencies are unclear it was apparent that both "smart pointers" and "garbage collection" have adherents and also that users of each approach had limited experiences of designs that deploy the other strategy.

Over the last month or so there has also been a newsgroup thread on c.l.c++.m - "Smart Pointers" - where there are clearly parts of the community on both sides of the question "are reference counted smart pointers a useful design option"? (And at the time of writing "garbage collection" isn't one of the alternatives that has been presented.) There is a difference between these discussions - the protaganists on the "core" reflector appear to be intent on learning from each other's experience, those on the newsgroup in evangelising. (Guess which is the more interesting to follow.)

There are many problems that must be addressed by C++ developers and, while the issues faced will vary from developer to developer, memory management is an issue that must be addressed by almost all.

The example set by the "core" working group is too little and too late: that the C++ community is failing to share and to build upon the experience of employing different memory management strategies signifies that there is something wrong.

A passage from "The IT Team" [Lees03], reproduced in Figure 1, illustrates why it matters that developers communicate ideas.

Figure 1 - A Passage from "The IT Team"

"Tuckman (1965) identified four developmental stages for a team to which Tuckman and Jensen (1977) added a final stage of adjourn. The figure provides an adaptation of that model which attempts to illustrate that:-

• A team may spend an undetermined and variable amount of time at each stage

• May not reach all stages

• May regress to previous stages.

"It is estimated that three fifths of the length of any team project, from start to finish, is taken up with the first two stages, Forming and Storming." (Robbins, Finley 1996 p.191).

"As these stages are non-productive the ease with which a team moves through them will have significant impact on the team's productivity."

A project balkanised according to the dialects its codebase is being written in isn't going to run as smoothly or efficiently as one that is unified in its approach. The costs are often hidden - developers may be reluctant to touch "foreign" code, reuse opportunities may be missed, barriers are raised to refactoring - all things that can be attributed to other causes.

I've seen it - in a codebase of only 50KLOC I've seen four date+time classes, three classes for parsing XML and a mass of utilities for converting strings from one implementation to another.

The C++ language deliberately sets out to support a wide range of usage styles, and a number of usage styles are easily identifiable:

Even aspects of functional or generative programming can be tackled, although these are generally deployed to support the above approaches. While this flexibility provides the opportunity to select the most appropriate and effective approach in any given context, it also provides plenty of scope for selecting an inappropriate approach for the problem in hand.

The downside to this wide ranging support for different styles of use is that the developer community has split into groups using distinct dialects. Does this matter? I think it does, because it impacts the ability of C++ users to communicate with one another. While dialects do develop in other languages, C++ seems to be unique in its propensity for them to wreck a project, dividing developers into groups that do not communicate well.

In "Is high-church C++ fair?"[Kelly01] Allan Kelly describes his experience of multiple dialects in the organisation he was working in. Allan describes four dialects (I'm sure we've all seen them) as follows:

Allan goes on to discuss the impact these have on his work.

While these comments focus on only two of the dialects they do illustrate the divisions that can occur between the corresponding congregations Not only does each group have difficulty understanding the other, each also believes that theirs is the correct way to use the language. What is also interesting from this description is the implication that the team in which Allan was working does not seem to have resolved these differences and remains in the "storm" phase of team development.

I hope that I've demonstrated that C++ dialects matter - because they can dramatically reduce the effectiveness of the team. But where do these dialects come from? And why is C++ particularly prone to these problems?

Developers frequently move to C++ from another language and bring with them an approach that fits that language well. By design C++ allows them to do this - and, in doing so, fails to encourage an evaluation of the appropriateness of their approach in C++. As a result the developer works in a creole^[2] formed of these two languages. In the early days of C++ the C/C++ creole was commonplace, but Java/C++ has gained recently.

Even developers coming first to C++ are not immune to this effect - they can inherit it from authors, trainers and colleagues. Kevlin Henney in "The miseducation of C++" [Henney01] identifies three families of C++ dialects and goes on to relate them to the way that C++ is taught.

Despite the implication of a timeline in this classification, the dialects of Early C++ have not been assigned to the dustbin of history. They are still living languages: I've recently had reports of a heavily MACRO based style of C++ in one organisation that sounds as though it belongs to this group.

And "Modern C++" isn't the final, definitive way to use the language: there are also dialects that move beyond the scope of Modern C++ and into generative techniques. These have their place but, like anything else, when seen as a "shiny new hammer" the effect is to introduce complexity that serves only to postpone necessary design decisions and introduce uncertainty.

What the "timeline" does reflect is that there has been an evolution in the thinking regarding effective ways of using C++: the "later" dialects are the result of learning from the use of the earlier ones. As a consequence they generally avoid problems that arise in using the "earlier" dialects and, in consequence, are more capable of handling complexity. Thus resource management is problematic in Early C++ dialects, requiring constant attention, while Classic and Modern dialects incorporate idioms that free the developer from this constant distraction. (While this evolution of the idioms in contemporary usage provides for better solutions to harder problems it also creates a difficulty - a style that was considered "best practice" a few years ago might now be dismissed as misguided or sub-optimal.)

There are also some more superficial elements that contribute to the separation of dialects in C++. Unlike the factors that separate Early, Classic and Modern C++ (or High Church/Low Church C++) these don't have a direct impact on the technical effectiveness of the language - and they can be found in dialects of all eras. But they are highly visible, and present a barrier to communication between their adherents:

I'm sure we all have preferences - mine is for consistency. (As I like to use the standard library and boost, I like to be consistent with the style these adopt.)

The range of C++ dialects is vast - Allan describes four major groupings and Kevlin three, but a closer examination would probably find at least one for every C++ project in the world. If different developers in a team are comfortable with different dialects then these incompatibilities between them can make it very hard for the team to reach the performance levels it would otherwise be capable of.

Later in "Is high-church C++ fair?" Allan addresses one "solution":

Allan returns to the subject in Overload 65: his article "The Developers New Work" [Kelly05] examines a number of non-solutions:

Well, that tells us a lot about what not to do, but in real projects we still need an answer.

Given my metaphor, dialects of spoken languages, I'm sure that my solution won't be a surprise to you. One can learn something of a language from dictionaries and grammars, but the only way to become fluent is to use it to communicate with others. That means reading and writing code - in the appropriate dialect - and discovering if it is understood by other developers.

Allan's answer [Kelly05] is similar:

I've more experience with this approach than Allan appears to have, and there is a problem that he appears unaware of: ten years (or so) ago I introduced my colleagues to elements of the latest thinking on how to use C++ - they were new to the language and I followed the literature. They adopted many of these idioms - things like "smart pointers" to managed object persistence, even some bits of STL. Then I left the organisation.

I'm still in touch with the development group and some of the developers there. Ten years ago "Classic C++" was the best way we knew to use the language, but C++ is a living breathing language and new idioms are being formed all the time. When I left these developers were no longer exposed to the "latest thinking" - like most of the industry they didn't "do books" (DeMarco and Lister - in "Peopleware" - report that the typical developer reads fewer than one technical book a year). They were not motivated to seek out new solutions in a subject where they were not experiencing problems. Nowdays a dialect of Classic/Low Church C++ is deeply entrenched and Modern/High Church C++ has passed them by. By failing to engage them directly in the wider community I left a situation where a local dialect was going to develop over time.

The lesson I take from this is that the goal should be more ambitious than ensuring a lingua franca within the team, more than introducing a contemporary dialect of C++. Developers must be exposed to developing ideas and engaged in the community developing them.

I don't have a magic bullet - I doubt that one exists. The different dialects of C++ have developed in response to genuine circumstances.

However, in the context of an individual project or team there is a range of things that, if employed sensibly, can make things better rather than worse:

Divisions in the C++ community can cost in a number of ways, the most obvious being the inability of team members to communicate in the language. Another cost, that is easier to overlook, is that as techniques are developed to address the problems that developers face, they are not known outside the part of the community that develops them. This can lead to the "re-inventing of wheels" - I've lost count of the different smart pointers I've encountered (most of them with avoidable bugs). Even worse, it can lead to "living with" avoidable problems - the typical C++ program leaks resources despite the fact that RAII (and the techniques for implementing it) have been known to some parts of the community for a long time.

Naturally, everyone that reads this is making an effort to be part of the solution instead of being part of the problem. However, I urge you to make an effort to be more involved and to seek ways to involve your colleagues in the wider community.