LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DevelopmentGCC's move to C++The GNU Compiler Collection (GCC) was, from its inception, written in C and compiled by a C compiler. Beginning in 2008, an effort was undertaken to change GCC so that it could be compiled by a C++ compiler and take advantage of a subset of C++ constructs. This effort was jump-started by a presentation by Ian Lance Taylor [PDF] at the June 2008 GCC summit. As with any major change, this one had its naysayers and its problems, as well as its proponents and successes. ReasonsTaylor's slides list the reasons to commit to writing GCC in C++:
The popularity of C++ and its superset relationship to C speak for themselves. In stating that the C subset of C++ is as efficient as C, Taylor meant that if developers are concerned about efficiency, limiting themselves to C constructs will generate code that is just as efficient. Having cleaner interfaces is one of the main advantages of C++, or any object-oriented language. Saying that C++ never requires "uglier" code is a value judgment. However, saying that it supports "cleaner code in several significant cases" has a deep history, best demonstrated by gengtype.
As C does not have any means of reflection [...] gengtype was introduced to
support some GCC-specific type and variable annotations, which in turn
support garbage collection inside the compiler and precompiled headers. As
such, gengtype is one big kludge of a rudimentary C lexer and parser.
What had happened was that developers were emulating features such as garbage collection, a vector class, and a tree class in C. This was the "ugly" code to which Taylor referred. In his slides, Taylor also tried to address many of the initial objections: that C++ was slow, that it was complicated, that there would be a bootstrap problem, and that the Free Software Foundation (FSF) wouldn't like it. He addressed the speed issue by pointing out that the C subset of C++ is as efficient as C. As far as FSF went, Taylor wrote, "The FSF is not writing the code." The complexity of a language is in the eye of the beholder. Many GCC developers were primarily, or exclusively, C programmers, so of necessity there would be a time period in which they would be less productive, and/or might use C++ in ways that negated all its purported benefits. To combat that problem, Taylor hoped to develop coding standards that limited development to a subset of C++. The bootstrap problem could be resolved by ensuring that GCC version N-1 could always build GCC version N, and that they could link statically against libstdc++. GCC version N-1 must be linked against libstdc++ N-1 while it is building GCC N and libstdc++ N; GCC N, in turn, will need libstdc++ N. Static linking ensures that each version of the compiler runs with the appropriate version of the library. For many years prior to 2008, there had been general agreement to restrict GCC code to a common subset of C and C++, according to Taylor (via email). However, there was a great deal of resistance to replacing the C compiler with a C++ compiler. At the 2008 GCC summit, Taylor took a poll on how large that resistance was, and approximately 40% were opposed. The C++ boosters paid close attention to identifying and addressing the specific objections raised by C++ opponents (speed, memory usage, inexperience of developers, and so on), so that each year thereafter the size of the opposition shrank significantly. Most of these discussions took place at the GCC summits and via unlogged IRC chats. Therefore, the only available record is in the GCC mailing list archives. First stepsThe first step, a proper baby step, was merely to try to compile the existing C code base with a C++ compiler. While Taylor was still at the conference, he created a gcc-in-cxx branch for experimenting with building GCC with a C++ compiler. Developers were quick to announce their intention to work on the project. The initial build attempts encountered many errors and warnings, which were then cleaned up. In June 2009, almost exactly a year from proposing this switch, Taylor reported that phase one was complete. He configured GCC with the switch enable-build-with-cxx to cause the core compiler to be built with C++. A bootstrap on a single target system was completed. Around this time, the separate cxx branch was merged into the main GCC trunk, and people continued their work, using the enable-build-with-cxx switch. (However, the separate branch was revived on at least one occasion for experimentation.) In May 2010, there was a GCC Release Manager Q&A on IRC. The conclusion from that meeting was to request permission from the GCC Steering Committee to use C++ language features in GCC itself, as opposed to just compiling with a C++ compiler. Permission was granted, with agreement also coming from the FSF. Mark Mitchell announced the decision in an email to the GCC mailing list on May 31, 2010. In that thread, Jakub Jelinek and Vladimir Makarov expressed a lack of enthusiasm for the change. However, as Makarov put it, he had no desire to start a flame war over a decision that had already been made. That said, he recently shared via email that his primary concern was that the GCC community would rush into converting the GCC code base to C++ "instead of working on more important things for GCC users (like improving performance, new functionality and so on). Fortunately, it did not happen." Richard Guenther was concerned about creating a tree class hierarchy:
It's a lot of work (tree extends in all three Frontends, middle-end and
backends). And my fear is we'll only get a halfway transition - something
worse than no transition at all.
The efforts of the proponents to allay concerns, and the "please be careful" messages from the opponents give some indication of the other concerns. In addition to the issues raised by Taylor at the 2008 presentation, Jelinek mentioned memory usage. Others, often as asides to other comments, worried that novice C++ programmers would use the language inappropriately, and create unmaintainable code. There was much discussion about coding standards in the thread. Several argued for existing standards, but others pointed out that they needed to define a "safe" subset of C++ to use. There was, at first, little agreement about which features of C++ were safe for a novice C++ developer. Taylor proposed a set of coding standards. These were amended by Lawrence Crowl and others, and then were adopted. Every requirement has a thorough rationale and discussion attached. However, the guiding principle on maintainability is not the coding standard, but one that always existed for GCC: the maintainer of a component makes the final decision about any changes to that component. Current statusCurrently, those who supported the changes feel their efforts provided the benefits they expected. No one has publicly expressed any dissatisfaction with the effort. Makarov was relieved that his fear that the conversion effort would be a drain on resources did not come to pass. In addition, he cites the benefits of improved modularity as being a way to make GCC easier to learn, and thus more likely to attract new developers. As far as speed goes, Makarov noted that a bootstrap on a multi-CPU platform is as fast as it was for C. However, on uniprocessor platforms, a C bootstrap was 30% faster. He did not speculate as to why that is. He also found positive impacts, like converting to C++ hash tables, which sped up compile time by 1-2%. This last work is an ongoing process, that Lawrence Crowl last reported on in October 2012. In keeping with Makarov's concerns, this work is done slowly, as people's time and interests permit. Of the initial desired conversions (gengtype, tree, and vector), vector support is provided using C++ constructs (i.e., a class) and gengtype has been rewritten for C++ compatibility. Trees are a different matter. Although they have been much discussed and volunteered for several times, no change has been made to the code. This adds credence to the 2010 contention of Guenther (who has changed his surname to Biener) that it would be difficult to do correctly. Reached recently, Biener stated that he felt it was too early to assess the impact of the conversion because, compared to the size of GCC, there have been few changes to C++ constructs. On the negative side, he noted (as others have) that, because of the changes, long-time contributors must relearn things that they were familiar with in the past. In 2008, 2009, and 2010, (i.e., at the beginning and after each milestone) Taylor provided formal plans for the next steps. There is no formal plan going forward from here. People will use C++ constructs in future patches as they deem necessary, but not just for the sake of doing so. Some will limit their changes to the times when they are patching the code anyway. Others approach the existing C code with an eye to converting code to C++ wherever it makes the code clearer or more efficient. Therefore, this is an ongoing effort on a meandering path for the foreseeable future. As the C++ project has progressed, some fears have been allayed, while some developers are still in a holding pattern. For them it is too soon to evaluate things definitively, and too late to change course. However, the majority seems to be pleased with the changes. Only time will tell what new benefits or problems will arise.
Brief items Quotes of the week
This is the fruit of an 8 hour debugging session. I hate writer.
— Caolán McNamara, commenting on a one-line,
eleven-character commit. (Hat tip to Cesar Eduardo Barros)
There is a lot to lose when you centralize something that should
really be left to the application authors. The app icon is the
app's identity. Sure it's more difficult to convince the upstream
to take your work despite it not being created by an algorithm,
but taking away a project's identity in the name of policing the
aesthetics of the overview is not the right approach.
— Jakub Steiner
Jitsi 2.0 releasedVersion 2.0 of the cross-platform open source softphone application Jitsi has been released. An announcement on the XMPP Foundation blog includes some details, such as: "one of the most prominent new features in the 2.0 release is Multiparty Video Conferencing. Such conferences can work in an ad-hoc mode where one of the clients relays video to everyone else, or in cases that require scalability, Jitsi can use the Jitsi Videobridge: an RTP relaying server controlled over XMPP." Other changes include support for the royalty-free VP8 and Opus codecs, and support for integrating with Microsoft Outlook. Additional details are listed at the Jitsi site.
Ardour 3.0 releasedVersion 3.0 of the Ardour digital audio workstation system has been released. "This is the first release of Ardour that features support for MIDI recording, playback and editing. It also features a huge number of changes to audio workflow, which for many users may be more significant than the MIDI support." See the "What's new" page for details. (Thanks to Andreas Kågedal.)
Systemd 198 releasedVersion 198 of systemd has been released. The long list of changes in this release includes new ways to extend unit file configuration, dynamic runtime control of resource limits, a number of changes to nspawn, and "substantially larger unit test suite, but this continues to be work in progress."
TopGit 0.9 releasedNew maintainer Robin Green announced the availability of TopGit 0.9, the first new release of the patch queue management tool after a lengthy hiatus. The project has also moved to Github. Green notes: "Because it's been 3 years since the last release, there are quite a few patches since 0.8, but most of them are quite minor changes. If you are upgrading from the HEAD of the old TopGit repository, all of and only the patches by me, Andrey Borzenkov and Heiko Hund are new compared to that revision."
Emacs 24.3 availableVersion 24.3 of GNU Emacs has been released. Among the highlights are a new major mode for editing Python, an update to the Common Lisp emulation library, and the addition of generalized variables in core Emacs Lisp.
Newsletters and articles Development newsletters from the past week
Hughes: GNOME Software overall planAt his blog, Richard Hughes outlines his designs for a plugin-capable software installer for GNOME. "Of course, packages are so 2012. It’s 2013, and people want to play with redistributable things like listaller and glick2 static blobs. People want to play with updating an OS image like ostree and that’s all awesome. Packages are pretty useful in some situations, but we don’t want to limit ourselves to being just another package installer." The gnome-software tool Hughes is prototyping is currently alpha-quality, but is available in the GNOME git repository.
Proposals now open for new features for GNOME 3.10Andre Klapper announced that the door is now open to propose new platform-wide features to be added for GNOME 3.10, which is slated for a September 2013 release. New proposals should be added to the GNOME wiki, but Klapper notes that "Proposed features must have an assignee working on them. The proposal period is planned to end in about a month."
Page editor: Nathan Willis |
|||||||||||||