[go: up one dir, main page]

0% found this document useful (0 votes)
52 views7 pages

Artima - The Most Important C - Software... Ever

Uploaded by

KinjalKishor
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
52 views7 pages

Artima - The Most Important C - Software... Ever

Uploaded by

KinjalKishor
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

artima - The Most Important C++ Software...

Ever

The Most Important C++ Software...


Ever
Opinion
by Scott Meyers
August 23, 2006

Summary
In this article, Scott Meyers shares his picks for the five most important software
packages in the history of C++, along with why he chose them.

In my first two articles in this series, I named my picks for the most important contributions to C++
in the categories of books and non-book publications:

“The Most Important C++ Books...Ever”


“The Most Important C++ Non-Book Publications...Ever”

In this third installment, I will turn my attention to the most important C++ software...ever.

To write software in C++, you need tools to help you do it. In my view, those tools have been
(and continue to be) the most important software related to C++. One can imagine one or more
blockbuster applications developed in C++ that drove hordes of people to choose the language
for future projects, but I’m not aware of that ever happening. The most important software for the
language has been the bread-and-butter stuff of the software development crowd: compilers and
libraries. Perhaps this is fitting for a language designed more for writing libraries than for writing
applications.

My picks for the five most important pieces of software in the history of C++, ordered
chronologically by first appearance, are:

Cfront by AT&T Bell Telephone Laboratories, 1985-1993. In the beginning, there was
Cfront, the original C++ compiler. It was a true compiler, but it generated C as its object
code, so it was common to think of it as a preprocessor that translated C++ to C. It was
hard not to think otherwise when debugging, because, at least when I started using it in
1988, there were no C++ debuggers. Instead, we grizzled pioneers used C debuggers and
learned to mentally unmangle names (e.g., to recognize that __pl__1Aff in the debugger
referred to some operator+ function in the C++ source code).

The fact that Cfront generated C had two advantages. First, it was fairly easy to port Cfront
to new platforms, because C compilers were ubiquitous. This facilitated the rapid spread of
C++ to many environments. Second, it allowed users to look at the generated code to see
what was going on during compilation. This helped demystify the language at a time when
most people using it were C++ beginners trying to figure out how it worked. It also acted as
a kind of security blanket. You didn’t really have to worry about C++ pulling the wool over
your eyes if everything it did was sitting there in plain sight (or at least sight as plain as
machine-generated C ever gets.)

artima - The Most Important C_ Software...Ever.html[2/7/2022 12:33:12 PM]


artima - The Most Important C++ Software...Ever

Until about 1990, Cfront not only compiled code, it also acted as the de facto language
standard. C++ came from AT&T and Cfront came from the C++ group at AT&T, so
whatever Cfront did had to be correct. For a time, this led to other compiler vendors
adhering so closely to Cfront behavior, they reproduced its bugs, too. When the Annotated
C++ Reference Manual (ARM) was published, Cfront’s role as a reference implementation
gradually diminished, especially when it became clear that adding exception-handling
support to Cfront called for Herculean effort.

The final Cfront release was in 1993, but at least its ghost lives on. Edison Design Group—
a company know for producing the most standard-conformant C++ front ends in the
business—notes in a July 2006 document that they have a Cfront-compatibility mode.
Personally, I suspect that there are a few Cfront implementations being used for embedded
projects on platforms where there’s still no native C++ compiler, but that’s just speculation
on my part.

GCC by the GNU Project, 1987-present. GNU got into the C++ business early, and it
released the first compiler generating native code (in contrast to Cfront’s C++-to-C
translation). Over the years, the GNU compiler has become the preferred choice for cross-
platform use. The fact that it’s a cross compiler has also made it popular for embedded
systems development. GCC itself is a compiler platform supporting multiple front ends (e.g.,
C, C++, FORTRAN, etc.) and multiple back ends (for targeting different platforms); the
version for C++ is known as g++.

In the early days, the driving force behind g++ was Michael Tiemann. I fondly recall the time
I submitted a g++ bug report, and, shortly thereafter, got a reply from Tiemann. He included
a new production for the g++ grammar, along with a request that I add the production,
rebuild the compiler, and see if the problem I’d reported went away. As I recall, the problem
remained, but there’s just something about having the author of a compiler send you a mod
and asking you to install it. Incidentally, Tiemann cofounded Cygnus Support in 1989, and I
believe Cygnus was one of the first companies based on free software. (It’s reported that in
the early days, Tiemann sometimes held meetings at Cygnus in a hot tub.)

g++ is open source, so the C++ community has free access to a C++ front end that is, for
all practical purposes, standard-conformant. Yet I don’t know of any open source tools (e.g.,
lints, refactoring tools, etc.) derived from the g++ code base that parse everything g++
does. There are tools that parse all C++ declarations (e.g., gccxml), but, as far as I know,
none that parse both declarations and definitions (especially function bodies). This says
something about g++’s front end, and though I have no personal experience with it, I doubt
that it’s complimentary. This is unfortunate, because C++ developers could really use a
larger tool set, but the barrier to entry for truly powerful tools is the ability to parse1 C++
source code, and that’s a barrier very few have been able to breach.

Visual C++ by Microsoft, 1992-present. Visual C++ (VC++) has been at once one of the
most important reasons for the success of C++ and one of the most potent forces retarding
its progress. Notwithstanding Bjarne Stroustrup’s assertion that “nobody knows what most
C++ developers do,2” I have little doubt that if you lined up every C++ developer on the
planet and polled them for the compiler or compilers they use for production work, a
majority would mention VC++. For that reason alone, Visual C++ has been and continues to
be important to C++. Furthermore, the flagship Microsoft products (e.g, operating systems
and Microsoft Office applications) are written entirely or primarily in C++ and are compiled
with the Visual C++ compiler. This, too, makes VC++ important in the world of C++. The

artima - The Most Important C_ Software...Ever.html[2/7/2022 12:33:12 PM]


artima - The Most Important C++ Software...Ever

company’s reliance on C++ has led them to develop tools and APIs to support its use, and
that has motivated many Windows developers to adopt the language. By the late 1990s,
C++ was known to many (and to my shock and dismay) as “the Microsoft language.”3
Visual C++ remains a dominating presence on the C++ landscape. For legions of
programmers, Visual C++ is C++.

Unfortunately, there were many years during which Microsoft’s implementation fell far short
of the standard. Up until 1998, this wasn’t a problem, because there wasn’t any standard to
adhere to, and compilers from other vendors had their own share of issues. However,
Visual C++ 6 (VC6) was released in 1998, nearly a year after the C++ standard had been
completed. VC6’s standards-conformance was less than exemplary, but at the time, that
was not a serious problem, because relatively few programmers were using the “new”
features of standard C++. What made it a serious problem was that VC6 remained the
current Microsoft release until 2002 (when VC7 was released), and even then the compiler
itself went largely unchanged. Rather, the primary improvement in standards conformance
came in the form of an upgraded library (e.g., a more standards-conformant
implementations of the STL), something many of us felt should have been done as a patch
release years earlier. The 2003 release of Visual C++ (VC7.1) finally resolved most issues
of standards conformance, but during the six years between VC6 and VC7.1, cross-
platform developers using VC++ had to expend enormous effort to work around VC++’s
failure to support things like partial template specialization, typically through conditional
compilation (i.e., fragmented code bases). Furthermore, many developers continue to use
VC6 even today, and those developers continue to be beholden to the decision the Visual
C++ team made to largely ignore standards conformance for that release. (For such
developers, for example, new doesn’t throw an exception if memory is exhausted, it returns
the null pointer.)

Since 2003, VC++ hasn’t had what I consider to be significant problems with standards
conformance, and I’m convinced that the current leadership takes standards conformance
seriously. Still, because I frequently work with developers whose lives (or at least whose
code bases) were made unnecessarily difficult for the six-year span from 1998 through
2003, I’ve decided that I’m justified in harboring a grudge against Microsoft into 2008—six
years from the time they released a “real” C++ compiler.

The Standard Template Library, originally by HP, 1993-present. That the standard
library for a language like C++ should offer a set of commonly-useful containers and
algorithms is not particularly surprising, though if that were the extent of the STL’s
contribution to C++, it’d probably still make the list. But the STL did far more than that. It
also introduced an architecture for designing containers and algorithms so that each could
work seamlessly with the other by communicating only through iterators. And it
demonstrated how arrays and pointers could be considered containers and iterators, thus
making the line between the language proper and its library blurrier than one might expect.
And it showed how the architecture was extensible by users, allowing for the introduction of
new containers, new algorithms, and new iterators types, each of which work as well with
other STL-conformant components as the STL components themselves do. And it
explained why there was little reason to distinguish between everything in a container and a
subrange of a container. And it did all this with an eye towards efficiency, eschewing classic
object-oriented inheritance-based solutions and relying almost exclusively on templates. It
introduced generic programming to the C++ masses. The end result was a transformation
in the way we thought about designing libraries and library frameworks, yet for people who
were just looking for convenient, portable containers of T, it provided that, too. In Effective

artima - The Most Important C_ Software...Ever.html[2/7/2022 12:33:12 PM]


artima - The Most Important C++ Software...Ever

STL (Addison-Wesley, 2001), I wrote, “In the nearly 30 years I’ve been programming, I’ve
never seen anything like the STL.” It’s now over 30 years, and I still haven’t.

The Libraries at Boost, 1999-present. This selection is a bit of a cheat, because Boost
isn’t a library, it’s an umbrella organization for a collection of libraries designed and
implemented by a variety of people with a variety of design goals and sensibilities. As a
result, the Boost libraries are somewhat scattershot in the functionality they provide as well
as the way they go about providing it. Still, Boost and its libraries have been quite important
to C++, and their influence seems likely to increase in the future. Of the 14 new kinds of
functionality specified in TR1 (of which 13 are now in the draft for C++0x), ten4 are based
on proposals derived from experience with Boost libraries. No other organization can claim
anywhere near that kind of impact on the expanded library functionality to be provided in
the next version of C++.

Boost’s influence in this regard is hardly accidental. Boost was founded with the goal of
acting as a testbed and advocate for libraries that might eventually be added to standard
C++. That most of TR1 is based on work at Boost testifies to the success they’ve had, and
it seems likely that TR2 will also contain plenty of Boost-based functionality.

If you google for “C++ libraries” (without the quotes), you’ll find that Boost is the first hit. It’s
debatable whether this suggests that when people think of C++ libraries, they should think
of Boost, but it certainly demonstrates that Boost has become closely associated with C++
libraries.

Now, software tools have been critical to the success of C++, but in the end, pretty much
everything boils down to people. That’s as true of C++ as of any other human endeavor. In my
next installment in this series of articles, I’ll tell you who I think have been the most important
people—the titans of the world of C++.5

End Notes
1. By “parse,” I mean more than simply building an abstract syntax tree. I also mean performing
implicit template instantiation, resolving calls to overloaded functions, etc. This means I’m
conflating parsing and semantic analysis, but the entry point for many powerful C++ tools is the
results of semantic analysis, and in common parlance, people often refer to that entire process as
“parsing.”

2. Because the community is too large and too diverse to allow meaningful claims about the
behavior of “most programmers.”

3. “The Unix language” was Java. I have no idea what the Apple language was.

4. These 10 components are (in a mixture of my own and TR1’s terminology) reference
wrappers, smart pointers, enhanced member pointer adapters (mem_fn), enhanced binders
(bind), generalized Functors (function), type traits, random numbers, tuples, fixed-size arrays,
and regular expressions.

5. Everyone agrees that titans are powerful, but my wife, a student of classics, can’t help but
remind me that though the titans were strong, they had more in the way of brawn than brain.
That’s why they came in second in their struggle with the gods of Olympus (Zeus and his crew.)
I’ll leave it up to you to determine whether there’s a parallel with C++, and, if so, who or what
plays the role of the Olympians.

artima - The Most Important C_ Software...Ever.html[2/7/2022 12:33:12 PM]


artima - The Most Important C++ Software...Ever

Resources
Part I in this series, “The Most Important C++ Books...Ever”:
http://www.artima.com/cppsource/top_cpp_books.html

Part II, “The Most Important C++ Non-Book Publications...Ever”:


http://www.artima.com/cppsource/top_cpp_publications.html

Edison Design’s July 2006 document that mentions their Cfront-compatibility mode:
http://www.edg.com/cpp_ftrs.html

GCC by the GNU Project:


http://gcc.gnu.org/

Article reporting that Michael Tiemann sometimes held meetings at Cygnus in a hot tub:
http://www.findarticles.com/p/articles/mi_m3514/is_n6_v41/ai_16112996#continue

gccxml:
http://www.gccxml.org/

Visual C++ by Microsoft:


http://msdn.microsoft.com/visualc/

The Libraries at Boost:


http://boost.org/

Scott Meyers is the author of Effective C++, the third edition of which was published in 2005. It is
available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0321334876/

Scott Meyers is also the author of More Effective C++, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/020163371X/

Scott Meyers is also the author of Effective STL, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0201749629/

Scott Meyers’ home page:


http://www.aristeia.com/

Talk back!
Have an opinion? Readers have already posted 18 comments about this article. Why not add
yours?

About the author


Scott Meyers is one of the world’s foremost authorities
on C++; he provides training and
consulting services to clients
worldwide. He wrote the best-selling Effective C++
series (Effective
C++, More
Effective C++, and Effective
STL), designed the innovative Effective C++
CD, is
Consulting Editor for Addison Wesley’s Effective Software
Development Series, and serves on
the Advisory Board for
The C++ Source (http://www.artima.com/cppsource/).
He has a Ph.D in

artima - The Most Important C_ Software...Ever.html[2/7/2022 12:33:12 PM]


artima - The Most Important C++ Software...Ever

Computer Science from Brown University. His web


site is aristeia.com.

Artima provides consulting


and training services to help
you make the most of Scala,
reactive
and functional
programming, enterprise
systems, big data, and
testing.

Artima, Inc.
2070 N Broadway Unit 305
Walnut Creek CA 94597
USA

(925) 394-7298 (Phone)


(925) 394-7299 (Fax)

   
   

Company
About
Contact

Services
Consulting
Training

Products
SuperSafe
Books

Open Source
ScalaTest
Scalactic

SuperSafe
Free Trial
User Guide
License

ScalaTest
Quick Start
Installing
User Guide
At A Glance
Scaladoc

artima - The Most Important C_ Software...Ever.html[2/7/2022 12:33:12 PM]


artima - The Most Important C++ Software...Ever

Scalactic
Quick Start
Installing
User Guide
Scaladoc

Training
Stairway to Scala Applied
Fundamentals
Stairway to Scala
Advanced
Effective Scala
Concurrent Scala

Books
Programming in Scala
Scala Puzzlers
ScalaCheck: The
Definitive Guide
Akka Concurrency
Agile Hiring

Copyright © 1996-2022 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use

artima - The Most Important C_ Software...Ever.html[2/7/2022 12:33:12 PM]

You might also like