[jr2]

Thought this was interesting - is it real or fake? -jr2

   On the 1st of January, 1998, Bjarne Stroustrup gave
   an interview to the IEEE's 'Computer' magazine.
   Naturally, the editors thought he would be giving
   a retrospective view of seven years of object-oriented
   design, using the language he created. By the end of the
   interview, the interviewer got more than he had
   bargained for and, subsequently, the editor decided to
   suppress its contents, 'for the good of the industry' but,
   as with many of these things, there was a leak. Here is a
   complete transcript of what was said, unedited, and
   unrehearsed, so it isn't as neat as planned interviews.
   You will find it interesting...

   ______________________________________________________________ __

   Interviewer:

   Well, it's been a few years since you changed theworld of
   software design.  How does it feel, looking back?

   Stroustrup:

   Actually, I was thinking about those days, just before you
   arrived.  Do you remember?  Everyone was writing 'C' and,
   the trouble was, they were pretty damn good at it.
   Universities got pretty good at teaching it, too.  They were
   turning out competent - I stress the word 'competent' -
   graduates at a phenomenal rate.  That's what caused the
   problem.

   Interviewer:

   Problem?

   Stroustrup:

   Yes, problem.  Remember when everyone wrote COBOL?

   Interviewer:

   Of course, I did, too.

   Stroustrup:

   Well, in the beginning, these guys were like
   demi-gods.  Their salaries were high, and they
   were treated like royalty.

   Interviewer:

   Those were the days, eh?

   Stroustrup:

   Right.  So what happened?  IBM got sick of it,
   and invested millions in training programmers, till
   they were a dime a dozen.

   Interviewer:

   That's why I got out.  Salaries dropped within a
   year, to the point where being a journalist actually
   paid better.

   Stroustrup:

   Exactly.  Well, the same happened with 'C' programmers.

   Interviewer:   I see, but what's the point?

   Stroustrup:

   Well, one day, when I was sitting in my office, I
   thought of this little scheme, which would redress
   the balance a little.  I thought 'I wonder what
   would happen, if there were a language so complicated,
   so difficult to learn, that nobody would ever be able
   to swamp the market with programmers?

   Actually, I got some of the ideas from X10, you know,
   X windows.  That was such a ***** of a graphics system,
   that it only just ran on those Sun 3/60 things.  They
   had all the ingredients for what I wanted.  A really
   ridiculously complex syntax, obscure functions, and
   pseudo-OO structure.  Even now, nobody writes raw X-windows
   code.  Motif is the only way to go if you want to retain
   your sanity.

   Interviewer:

   You're kidding...?

   Stroustrup:

   Not a bit of it.  In fact, there was another problem.
   Unix was written in 'C', which meant that any 'C'
   programmer could very easily become a systems programmer.
   Remember what a mainframe systems programmer used to earn?

   Interviewer:

   You bet I do, that's what I used to do.

   Stroustrup:

   OK, so this new language had to divorce itself from Unix,
   by hiding all the system calls that bound the two together
   so nicely.  This would enable guys who only knew about DOS
   to earn a decent living too.

   Interviewer:

   I don't believe you said that...

   Stroustrup:

   Well, it's been long enough, now, and I believe most people
   have figured out for themselves that C++ is a waste of time but,
   I must say, it's taken them a lot longer than I thought it would.

   Interviewer:

   So how exactly did you do it?

   Stroustrup:

   It was only supposed to be a joke, I never thought people would
   take the book seriously. Anyone with half a brain can see that
   object-oriented programming is counter-intuitive, illogical and
   inefficient.

   Interviewer:

   What?

   Stroustrup:

   And as for 're-useable code' --- when did you ever hear of a
   company re-using its code?

   Interviewer:

   Well, never, actually, but...

   Stroustrup:

   There you are then.  Mind you, a few tried, in the early days.
   There was this Oregon company --- Mentor Graphics, I think they
   were called --- really caught a cold trying to rewrite everything
   in C++ in about '90 or '91.  I felt sorry for them really, but
   I thought people would learn from their mistakes.

   Interviewer:

   Obviously, they didn't?

   Stroustrup:

   Not in the slightest.  Trouble is, most companies hush-up all
   their major blunders, and explaining a $30 million loss to the
   shareholders would have been difficult.  Give them their due,
   though, they made it work in the end.

   Interviewer:

   They did?  Well, there you are then, it proves O-O works.

   Stroustrup:

   Well, almost.  The executable was so huge, it took five minutes
   to load, on an HP workstation, with 128MB of RAM.  Then it ran
   like molasses. Actually, I thought this would be a major
   stumbling-block, and I'd get found out within a week, but nobody
   cared.  Sun and HP were only too glad to sell enormously powerful
   boxes, with huge resources just to run trivial programs.  You
   know, when we had our first C++ compiler, at AT&T, I compiled
  'Hello World', and couldn't believe the size of the executable:
   2.1MB

   Interviewer:

   What?  Well, compilers have come a long way, since then.

   Stroustrup:

   They have?  Try it on the latest version of g++ - you won't get
   much change out of half a megabyte. Also, there are several quite
   recent examples for you, from all over the world.  British Tele-
   com had a major disaster on their hands but, luckily, managed to
   scrap the  whole thing and start again. They were luckier than
   Australian Telecom.

   Now I hear that Siemens is building a dinosaur, and getting more
   and more worried as the size of the hardware gets bigger, to
   accommodate the executables.  Isn't multiple inheritance a joy?

   Interviewer:

   Yes, but C++ is basically a sound language.

   Stroustrup:

   You really believe that, don't you?  Have you ever sat down and
   worked on a C++ project?  Here's what happens: First, I've put
   in enough pitfalls to make sure that only the most trivial proj-
   ects will work first time.  Take operator overloading.  At the
   end of the project, almost every module has it, usually, because
   guys feel they really should do it, as it was in their training
   course.  The same operator then means something totally different
   in every module.  Try pulling that lot together, when you have a
   hundred or so modules.  And as for data hiding, God, I sometimes
   can't help laughing when I hear about the problems companies
   have making their modules talk to each other.

   I think the word 'synergistic' was specially invented to twist
   the knife in a project manager's ribs.

   Interviewer:

   I have to say, I'm beginning to be quite appalled at all this.
   You say you did it to raise programmers' salaries?  That's ob-
   scene.

   Stroustrup:

   Not really.  Everyone has a choice.  I didn't expect the thing to
   get so much out of hand. Anyway, I basically succeeded.  C++ is
   dying off now, but programmers still get high salaries, especial-
   ly those poor devils who have to maintain all this crap.  You do
   realise, it's impossible to maintain a large C++ software module
   if you didn't actually write it?

   Interviewer:

   How come?

   Stroustrup:

   You are out of touch, aren't you?  Remember the typedef?

   Interviewer:

   Yes, of course.

   Stroustrup:

   Remember how long it took to grope through the header files only
   to find that 'RoofRaised' was a double precision number?  Well,
   imagine how long it takes to find all the implicit typedefs in
   all the Classes in a major project.

   Interviewer:

   So how do you reckon you've succeeded?

   Stroustrup:

   The universities haven't been teaching 'C' for such a long time,
   there's now a shortage of decent 'C' programmers.  Especially
   those who know anything about Unix systems programming. How many
   guys would know what to do with 'malloc', when they've used 'new'
   all these years and never bothered to check the return code. In
   fact, most C++ programmers throw away their return codes.  What-
   ever happened to good ol' '-1'?  At least you knew you had an
   error, without bogging the thing down in all that 'throw' 'catch'
   'try' stuff.

   Interviewer:

   But, surely, inheritance does save a lot of time?

   Stroustrup:

   Does it?  Have you ever noticed the difference  between a 'C'
   project plan, and a C++ project plan?  The planning stage for
   a C++ project is three times as long.  Precisely to make sure
   that everything which should be inherited is, and what shouldn't
   isn't.  Then, they still get it wrong. Whoever heard of memory
   leaks in a 'C' program? Now finding them is a major industry.
   Most companies give up, and send the product out, knowing it
   leaks like a sieve, simply to avoid the expense of tracking them
   all down.

   Interviewer:

   There are tools....

   Stroustrup:

   ...Most of which were written in C++.

   Interviewer:

   If we publish this, you'll probably get lynched, you do realise
   that?

   Stroustrup:

   I doubt it.  As I said, C++ is way past its peak now, and no
   company in its right mind would start a C++ project without a
   pilot trial. That should convince them that it's the road to
   disaster.  If not, they deserve all they get.  You know, I tried
   to convince Dennis Ritchie to rewrite Unix in C++.

   Interviewer:

   Oh my God.  What did he say?

   Stroustrup:

   Well, luckily, he has a good sense of humor.  I think both he
   and Brian figured out what I was doing, in the early days, but
   never let on.  He said he'd help me write a C++ version of DOS,
   if I was interested.

   Interviewer:

   Were you?

   Stroustrup:

   Actually, I did write DOS in C++, I'll give you a demo when
   we're through.  I have it running on a Sparc 20 in the computer
   room.  Goes like a rocket on 4 CPU's, and only takes up 70 megs
   of disk.

   Interviewer:

   What's it like on a PC?

   Stroustrup:

   Now you're kidding.  Haven't you ever seen Windows '95?  I think
   of that as my biggest success.  Nearly blew the game before I was
   ready, though.

   Interviewer:

   You know, that idea of a Unix++ has really got me thinking.
   Somewhere out there, there's a guy going to try it.

   Stroustrup:

   Not after they read this interview.

   Interviewer:

   I'm sorry, but I don't see us being able to publish any of this.

   Stroustrup:

   But it's the story of the century.  I only want to be remembered
   by my fellow programmers, for what I've done for them.  You know
   how much a C++ guy can get these days?

   Interviewer:

   Last I heard, a really top guy is worth $80 - $90 an hour.

   Stroustrup:

   See?  And I bet he earns it.  Keeping track of all the gotchas I
   put into C++ is no easy job. And, as I said before, every C++
   programmer feels bound by some mystic promise to use every damn
   element of the language on every project. Actually, that really
   annoys me sometimes, even though it serves my original purpose.
   I almost like the language after all this time.

   Interviewer:

   You mean you didn't before?

   Stroustrup:

   Hated it.  It even looks clumsy, don't you agree?  But when the
   book royalties started to come in... well, you get the picture.

   Interviewer:

   Just a minute.  What about references?  You must admit, you
   improved on 'C' pointers.

   Stroustrup:

   Hmm.  I've always wondered about that.  Originally, I thought I
   had.  Then, one day I was discussing this with a guy who'd written
   C++ from the beginning.  He said he could never remember whether
   his variables were referenced or dereferenced, so he always used
   pointers.  He said the little asterisk always reminded him.

   Interviewer:

   Well, at this point, I usually say 'thank you very much' but it
   hardly seems adequate.

   Stroustrup:

   Promise me you'll publish this.  My conscience is getting the
   better of me these days.

   Interviewer:

   I'll let you know, but I think I know what my editor will say.

   Stroustrup:

   Who'd believe it anyway?  Although, can you send me a copy of that
   tape?

   Interviewer:

   I can do that.

   ______________________________________________________________ __
   ______________________________________________________________ __
   ______________________________________________________________ __

  

Also, while some points are true, the whole interview is fake.

Real interview here: http://www2.research.att.com/~bs/ieee_interview.html

Thanks.  =]

IEEE Computer "Open Channel" Interview with Bjarne Stroustrup

"Any clod can have the facts, but having opinions is an art."
Charles McCabe, San Francisco Chronicle
The Real Stroustrup Interview

The father of C++ explains why Standard C++ isn't just an object-oriented language.

In The Design and Evolution of C++ (Addison Wesley, 1994), Bjarne Stroustrup argued that "a programming language is really a very tiny part of the world, and as such, it ought not be taken too seriously. Keep a sense of proportion and most importantly keep a sense of humor. Among major programming languages, C++ is the richest source of puns and jokes. That is no accident." For the past few months, a hoax interview between Stroustrup and Computer has been making the rounds in cyberspace. While we regret the incident, it offers us a welcome opportunity to have the father of C++ share his insights on Standard C++ and software development in general. We can also attest to his continued sense of proportion and humor-he suggests that the fictitious interview would have been a much funnier parody had he written it himself.

-Scott Hamilton, Computer

STANDARD C++

Computer: ISO approved the Standard C++ in November 1997, and you published a third edition of your The C++ Programming Language (Addison Wesley, 1997). How has C++ evolved over the past few years and what does the ISO standard mean for the C++ community?
Stroustrup: It is great to finally have a complete, detailed, and stable definition of C++. This will be a great help to the C++ community in myriad direct and not-so-direct ways. Obviously, we will get better implementations as compiler providers start shifting attention from catching up with the standards committee to quality-of-implementation issues. This is already happening.

Standards-conforming implementations will prove a boon to tools and library suppliers by providing a larger common platform to build for.

The standard gives the programmer an opportunity to be more adventurous with new techniques. Programming styles that used to be unrealistic in production code are becoming realistic propositions. Thus, more flexible, general, faster, and more maintainable code can be written.

Naturally, we should keep cool and not indulge in orgies of "advanced" techniques. There are still no miracles, and the best code is still the code that most directly matches a sound design. However, now is the time to experiment and see which techniques will suit particular people, organizations, and projects. Much of The C++ Programming Language is devoted to these techniques and the trade-offs they represent.

The most visible aspects of what makes this progress feasible are the "new" major language facilities-templates, exceptions, runtime type information, and namespaces-and the new standard library. The minor improvements to language details are also important. We have had most of the facilities available for years now, but haven't been able to rely on them where we needed portability and production quality. This has forced us to take suboptimal approaches to design and implementation of our libraries and applications. However, soon (this year) all major implementations will provide solid support for Standard C++.

From a language and programming-techniques perspective, the most significant change to C++ is the continuing increase in emphasis on statically verifiable type safety and the increased flexibility of templates. Flexible templates are necessary to make the emphasis on type safety pay off in terms of elegance and efficiency.

Feasibility of new techniques

Computer: You say that "often what an experienced C++ programmer has failed to notice over the years is not the introduction of new features as such, but rather the changes in relationships between features that make fundamental new programming techniques feasible." Could you give some examples of how this might be applicable to Standard C++?

Stroustrup: It is easy to study the rules of overloading and of templates without noticing that together they are one of the keys to elegant and efficient type-safe containers. This connection becomes obvious only when you look into the fundamental algorithms that are common to most uses of containers. Consider the program segment in Figure 1a. The first call of count() counts the number of occurrences of the value 7 in a vector of integers. The second call of count() counts the number of occurrences of the value "seven" in a list of strings.

// Figure 1a:

void f(vector<int>& vi, list<string>& ls)
{
   int n1 = count(vi.begin(),vi.end(),7);
   int n2 = count(ls.begin(),ls.end(),"seven");
   // ...
}


// Figure 1b:

template<class Iter, class T>
int count(Iter first, Iter last, T value)
{
   int c = 0;
   while (first!=last) {
      if (*first == value) c++;
      ++first;
   }
   return c;
}
Changes in relationships between features can make fundamental new programming techniques feasible: (a) A count algorithm for counting the number of occurrences of the value 7 in a vector of integers, as well as the number of occurrences of the value "seven" in a list of strings becomes (b) a single function that handles both calls using a template.
There are ways of achieving this in every language that allows overloading. Given templates, we can write a single function that handles both calls, as shown in Figure 1b. This template will expand into optimal code for the two calls. This count() is roughly equivalent to the standard-library count() so a user will not have to write it. The count() function itself relies on overloading: Obviously, the equality operator == is overloaded for integers and strings (with the obvious meaning). In addition, * and ++ are overloaded to mean "dereference" and "refer to next element" for the iterator types for vectors and lists; that is, * and ++ are given the meaning they have for pointers.
This definition of count() illustrates a couple of the key techniques used in the containers and algorithms part of the C++ standard library. These techniques are useful, and they are not trivially discovered given only the basic language rules.

Consider a slightly more advanced variation of the count() example shown in Figure 2a. Instead of counting occurrences of a value, count_if() counts the number of elements that fulfill a predicate. For example, we can count the number of elements with a value less than 7 as shown in Figure 2b.

// Figure 2a:

template<class Iter, class Predicate>
int count_if(Iter first, Iter last, Predicate pred)
{
   int c = 0;
   while (first!=last) {
      if (pred(*first)) c++;
      ++first;
   }
   return c;
}

// Figure 2b:

bool less_than_7(int i) { return i<7; }  

void f2(vector<int>& vi, list<int>& li)
{
   int n1 = count_if(vi.begin(),vi.end(),less_than_7);
   int n2 = count_if(li.begin(),li.end(),less_than_7);
   // ...
}
More advanced variation of the count example that (a) counts the number of elements that meet a predicate-for example, (b) the number of elements with a value less than 7.
Generalizing this technique to handle comparisons with any value of any type requires us to define a function object-that is, a class whose objects can be invoked like functions, as shown in Figure 3a. The constructor stores a reference to the value we want to compare against, as in Figure 3b, and the application operator (operator()) does the comparison. In other words, count the number of elements in vi that have a value less than the integer 7, and count the number of elements in ls that have a value less than the string "seven."
// Figure 3a:

template <class T> class Less_than {
   const T v;
public:
   Less_than(const T& vv) :v(vv) {} // constructor
   bool operator()(const T& e) { return e<v; }
};

// Figure 3b:

void f3(vector<int>& vi, list<string>& ls)
{
   int n1 = count_if(vi.begin(),vi.end(),
      Less_than<int>(7));
   int n2 = count_if(ls.begin(),ls.end(),
      Less_than<string>("seven"));
   // ...
}
To handle comparisons with any value of any type, we define (a) a class whose objects can be invoked like functions (function object), with the constructor storing (b) a reference to the value we want to compare against.

It may be worth mentioning that the code generated is very efficient and in particular does not use function calls-or similar relatively slow operations to implement comparisons, fetching the next element, and so forth.

Undoubtedly, this code will look strange to someone who is not a C++ programmer and even to C++ programmers who have not yet internalized the latest techniques for using templates and overloading-and that, of course, is part of the purpose of presenting the examples here. However, the bottom line is that these techniques allow you to write efficient, type-safe, and generic code. People familiar with functional languages will note that these techniques are similar to techniques pioneered in those languages.

Language features are fundamentally boring in isolation and they can distract from good system building-only in the context of programming techniques do they come alive.

The Standard Library

Computer: How was the Standard Library defined and what impact will it have on the C++ community?

Stroustrup: The most novel and interesting part of the standard library is the general and extensible framework for containers and algorithms. It is often called the STL and is primarily the work of Alex Stepanov (then at Hewlett-Packard Labs, now at Silicon Graphics).

Alex worked on providing uncompromisingly general and uncompromisingly efficient fundamental algorithms which, for example, find an element in a data structure, sort a container, or count the occurrences of a value in a data structure. Such algorithms are fundamental to much computing.

Alex worked with a variety of languages and had several collaborators over the years-notably David Musser (Rensselaer Polytechnic Institute), Meng Lee (HP Labs), and Andrew Koenig (AT&T Labs). My contribution to the STL was small, but I think important: I designed an adapter called mem_fun(). It allows standard algorithms to be used for containers of polymorphic objects, thus tying object-oriented programming techniques neatly into the generic programming framework of the standard library.

Somewhat to my surprise, the STL matched the set of criteria for a good set of standard containers for C++ that I had developed over the years. After a year or so of discussing and polishing the STL, the ISO C++ committee accepted the STL as a key part of the standard C++ library. My criteria included

uncompromising efficiency of simple basic operations (for example, array subscripting should not incur the cost of a function call);
type-safety (an object from a container should be usable without explicit or implicit type conversion);

generality (the library should provide several containers, such as vectors, lists, and maps); and

extensibility (if the standard library didn't provide some container that I needed, I should be able to create one and use it just as I would a standard container).

By adopting STL with only minor modifications and additions, we avoided the dreaded design by committee.

Clearly, a group of part-time volunteers (the C++ standards committee) can't provide every library facility that a programmer would find useful. Consequently, a key issue was what to include in the standard library and what to leave to the industry and individuals to provide.

We decided to use "what is needed for the communication between separately developed libraries" as a guide to what to include. Thus, I/O, strings, and containers became the major focus. We included the C standard library and some facilities for numeric computation for historical reasons, but left out lots of potentially useful facilities-such as better facilities for dates and currency, regular expression matching, and graphics. Fortunately, these facilities are available commercially and/or in the public domain.

The standard library saves programmers from having to reinvent the wheel. In particular, standard containers allow both novices and experts to program at a higher level. Consider the simple program in Figure 4, which performs a simple task simply. It does so without macros, without explicit memory management or other low-level language facilities, and without resource limitations. In particular, if some joker presents the program with a 30,000 character "first name" the program will faithfully print it back at him without overflow or other errors.

// Figure 4:

int main()
{
   cout << "Please enter your first name:\n";
   string name;
   cin >> name; // read into name cout
   << "Hello" << name << "!\n";
}
Simple "Hello" program using Standard Library features to perform its task simply.

Using the standard library can and should revolutionize the way C++ is taught. It is now possible to learn C++ as a higher level language. Students deal with the facilities for low-level programming only when needed and only after they've mastered enough of the language to provide a suitable context for discussing low-level facilities. Thus, the standard library will serve as both a tool and as a teacher.

COMPLEXITY, C++, AND OOP

Computer: In The C++ Programming Language, you say "Ordinary practical programmers have achieved significant improvements in productivity, maintainability, flexibility, and quality in projects of just about any kind and scale." Yet some critics maintain that C++, and OO in general, are overly complex and give rise to corrective-maintenance and maintenance problems in large systems. Do these criticisms in any way correspond to your own experiences as a developer of large systems in C++?

Stroustrup: In my personal experience, OO design and OO programming lead to better code than you get from more traditional procedural approaches-code that is more flexible, more extensible, and more maintainable without imposing significant performance overheads. There is not as much hard evidence-as opposed to personal observations-as I would like, but several studies within AT&T and elsewhere support this opinion.

Two factors confound the issue: There is no general agreement on what "object-oriented" really is, and discussions rarely account for experience sufficiently. Much of "the trouble with OO" comes from people with no significant OO experience approaching an ambitious project with some partially understood-yet dogmatic and typically limited-notion of what OO code must look like.

So what is OO? Certainly not every good program is object-oriented, and not every object-oriented program is good. If this were so, "object-oriented" would simply be a synonym for "good," and the concept would be a vacuous buzzword of little help when you need to make practical decisions. I tend to equate OOP with heavy use of class hierarchies and virtual functions (called methods in some languages). This definition is historically accurate because class hierarchies and virtual functions together with their accompanying design philosophy were what distinguished Simula from the other languages of its time. In fact, it is this aspect of Simula's legacy that Smalltalk has most heavily emphasized.

Defining OO as based on the use of class hierarchies and virtual functions is also practical in that it provides some guidance as to where OO is likely to be successful. You look for concepts that have a hierarchical ordering, for variants of a concept that can share an implementation, and for objects that can be manipulated through a common interface without being of exactly the same type. Given a few examples and a bit of experience, this can be the basis for a very powerful approach to design.

However, not every concept naturally and usefully fits into a hierarchy, not every relationship among concepts is hierarchical, and not every problem is best approached with a primary focus on objects. For example, some problems really are primarily algorithmic. Consequently, a general-purpose programming language should support a variety of ways of thinking and a variety of programming styles. This variety results from the diversity of problems to be solved and the many ways of solving them. C++ supports a variety of programming styles and is therefore more appropriately called a multiparadigm, rather than an object-oriented, language (assuming you need a fancy label).

Examples of designs that meet most of the criteria for "goodness" (easy to understand, flexible, efficient) are a recursive descent parser, which is traditional procedural code. Another example is the STL, which is a generic library of containers and algorithms depending crucially on both traditional procedural code and on parametric polymorphism.

I find languages that support just one programming paradigm constraining. They buy their simplicity (whether real or imagined) by putting programmers into an intellectual straitjacket or by pushing complexity from the language into the applications. This is appropriate for special-purpose languages, but not for general-purpose languages.

I have often characterized C++ as a general-purpose programming language with a bias toward systems programming. Think of it as "a better C" that supports

data abstraction,
object-oriented programming, and

generic programming.

Naturally, this support for more than one approach to programming causes more complexity than supporting only one approach. I have noticed that this view-that there are design and programming approaches with domains in which they are the best-offends some people. Clearly, I reject the view that there is one way that is right for everyone and for every problem. People who passionately want to believe that the world is basically simple react to this with a fury that goes beyond what I consider appropriate for discussing a programming language. After all, a programming language is just one tool among many that we use to construct our systems.

The ideal way of resolving the two views would be to have a language that provides a set of simple primitives from which all good programming styles can be efficiently supported. This has been repeatedly tried but not-in my opinion-achieved.

JAVA AND C++

Computer: That same argument for simplicity could conceivably be extended to Java, which might explain the 700,000 Java programmers that Sun claims (compared to 1.5 million C++ programmers). You maintain that Java is not the language you would have designed even if C++ needn't be compatible with C. What else do you have to say after having been asked this question for the thousandth time?

Stroustrup: These days, I'm always asked about Java, and it is very hard for me to respond. If I say something negative, I sound ungracious; if I say something positive, I feed into the commercial hype that surrounds Java and the unfortunate anti-C++ propaganda that emanates from parts of the Java community.

I encourage people to consider the two languages according to their design criteria and not just in the context of commercial rivalries. I outlined the design criteria for C++ in detail in The Design and Evolution of C++, and Java doesn't even start to meet those criteria. That's fine as long as programmers consider Java as a programming language among others and not a panacea. After all, C++ isn't a perfect match for Java's design aims either. However, when Java is promoted as the sole programming language, its flaws and limitations become serious.

Here are a few examples where the criteria applied to developing C++ led to significant differences. Unlike Java, C++ supports

the ability to effectively compose a program out of parts written in different languages,
a variety of design and programming styles,

user-defined types with efficiencies that approach built-in types,

uniform treatment of built-in and user-defined types, and

the ability to use generic containers without runtime overhead (for example, the STL).

I designed C++ so programmers could write code that is both elegant and efficient. For many applications, C++ is still the best choice when you don't want to compromise between elegance and efficiency.

I wonder how people count "programmers." Is a student a programmer? Is every compiler shipped counted as a programmer? I understand the number quoted for C++; it is conservative and plausible. It is a good approximation of the number of C++ implementations sold for real money last year. I wonder if Sun's Java number is as solid. Incidentally, based on the few hard numbers I have found-such as compiler sales, book sales, and C++ course attendance-I estimate that the C++ user population is growing at 10 to 20 percent a year.

And no, I'm not a Java fan. I dislike hype, I dislike marketing of programming tools to nonprogrammers, I dislike proprietary languages, and I like lots of programming languages. On the technical side, Java never gave me the "Wow, that's neat!" reaction that I have had with many other languages. It provides popular language features in a form that I consider limiting.

Java has borrowed much from C++, but not as much as is often claimed and not with as much taste and understanding as one could have wished for. To deliver on some of the key promises made for it, Java must grow. This evolution may compromise Java's claim of being simpler than C++, but my guess is that the effort will make Java a better language than it is today. Currently, Java seems to be accumulating language features and "standard" libraries at quite a pace. I'm looking forward to seeing what the Java version of templates will look like; as far as I know Sun hasn't yet blessed any of the dozen or so dialects.

As Java and its community matures, it will hopefully adopt a sensible live-and-let-live philosophy. This would allow Java to take its place as one language among many in the tool chest of professional programmers.

TOOLS

Computer: In what ways have systems changed over the past few years, and what still needs to be done in the C++ arena and in systems design in general? Given C++'s relative maturity at this point, how would you rate the available C++ development tools and what still needs to be done to improve?

Stroustrup: First, I'd like to see the basic tools such as compilers, debuggers, profilers, database interfaces, GUI builders, CAD tools, and so forth fully support the ISO standard. For example, I'd like to get a database query result as an STL container or an istream of appropriately typed objects. Tool vendors have made a good start, but have much work to do in tools that depend on compilers and other source code analyzers.

My list of basic tools is a partial answer to the question about what has changed: Over the past few years, large numbers of programmers have come to depend on elaborate tools to interface code with systems facilities. These tools are essential to relieving programmers of tedious and error-prone tasks, but come at a risk of the programmers (and their employers) becoming captives of their tool suppliers. Often, these tools are far more complex than a traditional programming language, and there are few standards.

I would encourage nonproprietary standards for tools and libraries. In the short term, say 10 years, many such standards will be industry standards rather than formal ISO or IEEE standards, but it is essential for the software industry's health that key interfaces be well-specified and publicly available. With the increasing importance of standards for system-level objects such as COM and CORBA, it is particularly important that the C++ bindings to those be clean, well documented, and simple to use. Unfortunately, such "standards work"-which is beneficial to everybody-is neglected because it provides short-term competitive advantages to nobody.

I'd rather not specifically "rate" the available C++ tools. They are better than they were, and most often as good or better than any tools for any other language. However, as a programmer, I am naturally impatient for more and better quality tools. Personally, I look forward to better tools for analyzing C++ source code. I also hope that C++ implementation vendors will spend a slightly larger fraction of their budgets on improving the quality and performance of their compilers rather than concentrating too heavily on novelties. Real improvements in compilers are relatively cheap compared to what is spent on a new release of a complete C++ implementation. However, I fear that unless major users start demanding conformance testing and benchmarking, vendors will spend resources on what looks better in an advertisement.

THE FUTURE

Computer: I know you've been heavily involved in the C++ standards process, but what other projects are you involved in currently and how will you continue working to evolve C++?

Stroustrup: I'm suffering from having successfully completed a very large project. The ISO C++ standard is done. The third edition of The C++ Programming Language is there to acquaint serious programmers with what Standard C++ has to offer and how best to use it. And The Design and Evolution documents the design decisions that shaped C++. There is more to be done, but nothing that requires a full-time language designer. Now is the time to enjoy the flexibility and power of C++ by writing code, rather than focusing on possible changes.

Apart from that, I'm taking the opportunity to learn a few things-a couple of new languages and something about how software is used in a large business-and planning some experiments in distributed computing.

Bjarne Stroustrup is head of the large-scale programming research department at AT&T; [email protected]; http://www.research.att.com/~bs/
Editor: Will Tracz, Lockheed Martin Federal Systems, MD 0210, Owego, NY 13827-3998; [email protected]
1998 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

[Thaeris]

I love the nerd-tackular tinge of EVIL!!!

BWAHAHAHARRGGhhhhh

...I happen to like what I've learned of C++, by the way...

[The E]

Also, while some points are true, the whole interview is fake.

Real interview here: http://www2.research.att.com/~bs/ieee_interview.html

[Nuke]

now that i think back it was far easier for me to read parts of the freespace codebase than it was to read pcs2's code. i wonder if some of this article is true. im half tempted to rewrite nukesim in c now.

[Flipside]

Oddly enough, I bought his book, 'C++ Programming - Principles and Practice' a week or so ago, to start getting my foot in the door of C++ to add to my Java

As for the 'only simple programming works first try', well, that's pretty much applicable to every language I've used in the last 20 years, BASIC, Z80, 6502, Pascal, VB or Java.

[Mongoose]

Seriously, once you get beyond "Hello world!", you're just asking for a missing semicolon to kill you somewhere.

[blackhole]

Actually a missing closing right curly bracket will do more damage. I once got something around 3000 errors because of a missing bracket.

[Mongoose]

That may be true, but I once had a missing semicolon fire off segfaults at me for hours in a school assignment before I was able to find it.

[Bobboau]

now that i think back it was far easier for me to read parts of the freespace codebase than it was to read pcs2's code. i wonder if some of this article is true. im half tempted to rewrite nukesim in c now.

were you looking at the file loading/conversion/do something code or the interface code?


I realized this was a joke when I read 'C programs don't have memory leaks'

[Nuke]

i mostly looked at the file loading code, to see if i could understand the pmf file specs.

[jr2]

I tried to learn programming... once.

It was Borland Turbo C++

Pretty much failed... I was supposed to make a program to like, I forget, say hello world or somesuch.

It wouldn't compile.

I copy+pasted from the answer key.

It wouldn't compile.

I gave up. 

[Thaeris]

#include "stdafx.h"
#include <iostream>
using namespace std;

int main()
{
cout << "Hello World! Now, bite my shiny, metal a\a**" << endl;

return 0;
}

There. Complete with sound effects!

 

[portej05]

Thaeris: A few small problems
1) stdafx.h is a visual studio construct (precompiled headers), and won't exist in most cases.
2) main should have its full parameters (even though they're not used)

Code: [Select]

#include <iostream>

int main( int argc, char** argv )
{
  std::cout << "Hello World" << std::endl;
  return 0;
}

Keep in mind that std::endl might return \n or \r\n (or is it \n\r? ) depending on platform and implementation

[Thaeris]

Well, I did learn C++ with VS2008, so "stdafx.h" is fairly common for me to use...

...Also, I'm not sure why I'd need to put parameters into the "main" function, especially when they're not used! 

Lastly, is there any particular advantage to using "std::cout" over just putting "using namespace std;" into the declarations and just being off with it?

[portej05]

'using namespace' needs to be used carefully to avoid symbol clashes

[Thaeris]

Forgive my ignorance, but what does that mean precisely?

[The E]

Assume you are using std::cout. Further assume that some other namespace in your project defines a cout function itself, with the same parameters. If you put "using namespace std;" and "using namespace someothernamespace;" into the same source file, how is the compiler supposed to decide which version of cout he should use?

[Mika]

That "interview" is hilarious from the start!

Here's another one of military budget overruns:
http://www.dau.mil/pubscats/ATL%20Docs/ward_jul-aug09.pdf

Caution:
Sarcasm is strong in this one.