Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

C++ Answers From Bjarne Stroustrup

Roblimo posted more than 14 years ago | from the thoughtful-questions-get-thoughtful-answers dept.

Programming 386

Monday we had over 550 assorted questions and comments for and about Bjarne Stroustrup. Excellent moderation (Thanks, Monday Moderators!) helped cull this mass down to 10 extremely high-quality questions Bjarne has kindly answered in amazing depth, for which he deserves a loud round of applause. Update: 02/28 02:12 by R : Bjarne later took the time to dig through all the comments and reply to some of them. The additional material is appended to the end of the original Q&A session.

C++ Answers From Bjarne Stroustrup

1) Has OO run out of steam?
by rambone

After 20-some years, it's obvious that object-oriented programming is not a panacea. What are your thoughts on the future of the OO paradigm? What other paradigms do you see challenging it?

Bjarne:

Well. It was obvious to me 20-some years ago that OOP wasn't a panacea. That's the reason C++ supports several design and programming styles.

If you like long words, you can say C++ is a "multi-paradigm language," but simply saying "C++ is an OOPL" is inaccurate. I wrote a paper about that "Why C++ isn't just an Object-Oriented Programming Language" (download from my papers page). I presented that paper at OOPSLA - and survived.

In the first edition of "The C++ Programming Language," I didn't use the phrase "object-oriented programming" because I didn't want to feed the hype. One of the problems with OOP is exactly that unscrupulous people have hyped it as a panacea. Overselling something inevitably leads to disappointments.

That said, OOD/OOP is my favorite way of approaching design and programming. It just isn't the right style for every program and for every detail of a program. Some good abstractions are best represented outside class hierarchies. Trying to force everything into a hierarchy - especially into a single-rooted hierarchy - can give truly contorted programs.

I use a lot of simple data abstraction (classes without inheritance) and generic programming (templates and algorithms parameterized on types). However, I don't see these as "paradigms challenging OOP." Rather, they are complementary techniques. The key is always to find designs that fit the problems and use the language constructs that best represent the designs in the code.

Combinations of style can lead to very elegant code. For example,

void draw_all(list& lst)
{
for_each(lst.begin(),lst.end(),mem_fun(&Shape::draw));
}

Here, list and for_each() are examples of the C++ standard library's generic facilities. What they are used for is to invoke a virtual function of a base in a traditional class hierarchy.

You can even write a version of draw_all() that works for every standard container type with Shape* elements:

template
void draw_all(Container& c)
{
for_each(c.begin(),c.end(),mem_fun(&Shape::draw));
}

I chose this example to wake up people who still live in the dark ages and think that C++ is C with a few uninteresting additions.

Naturally, the code generated for draw_all() is as efficient as an list traversal code and the polomorphism used to call Shape::draw() boils down to a call of a function through an array of pointers to functions. The mechanism has been used to invoke device drivers.

New "paradigms" are touted every year, but most are not fundamental and few are genuinely new. Probably the most interesting are those based on "components" such as COM and CORBA. I'm undecided whether these constitutes a "new paradigm" or simply a new set of systems-level building blocks. Would we talk of Unix processes as a new paradigm? Anyway, my main concern with such components is that they are still less than perfectly integrated with programming languages, such as C++, and with the various "traditional" programming paradigms, such as OOP and generic programming.

2) C++ for systems programming
by ajs

C has long been the UNIX-world's systems programming language, and still remains that way. I know you don't like to compare languages, so I'll just ask if you feel that there are any core reasons why C++ either does not make a good systems programming language or failed to capture the interest of the systems C programmers.

Bjarne:

It is hard to teach old dogs new tricks.

Unix was first written 25+ years ago (I first tried in in 1973). All of its interfaces are defined in terms of C function calls, arrays, and structs. By the time C++ became available, there were 10+ years of tradition for almost exclusively using C.

There is no good reason for Unix programmers to avoid C++ and several good reasons to use it. However, there are no end of reasons/excuses offered. Let me list a few:

  • C++ is slow
  • C++ generates bloated code
  • There are no good C++ compilers
  • C++ is complicated
  • C++ doesn't offer much to systems programmers
  • "Advanced" C++ features are unsuitable for systems work
  • C++ code isn't portable
  • C++ doesn't have an ABI.
These are all either flat wrong or largely irrelevant. Some of these reasons make some sense on other systems (say on a minute embedded system without proper C++ tools), but not on Unix/Linux. Let me briefly try to explain why. Naturally, a complete discussion would take hundreds of pages because it is not possible to prove a negative. That is, it is not possible to prove that there isn't some problem that could be unsolvable for somebody.
  • C++ generates as good code as C for equivalent programs. Just try it.
  • C++ was designed to do that and current compilers deliver on that promise.
Naturally, you can write poor programs in any language. C++ is a powerful tool and in the wrong hands it can generate code that is *obviously* contorted and bloated. That may be preferable to the traditional spaghetti that poor programmers produce in C. Note that someone who is a good C programmer isn't automatically a good C++ programmer. Many problems have been caused by good C programmers assuming that they could adopt a semi-random collection of C++ language features and then magically become a good C++ programmer in a week.

A C programmer can benefit from C++ in a week, but only by sticking to a subset of C++'s facilities and by using libraries.

C++ supports powerful techniques that are at best weakly supported by C and learning these techniques takes time. C programmers might do well remembering how long it took them to become "master level" C programmers. I see no reason why it would take less time to become a "master level" C++ programmer.

The current generation of C++ compilers is far superior in standards conformance to compilers from a couple of years ago. The optimizers are shared with C. This can be a problem because it precludes some useful optimizations that cannot be done for C, but at least sharing of major compiler parts should convince sceptics that equivalent code it produced.

I'll deal with the roots of language complexity in my answer to question 9. Here, I'll just point out that many of the C++ facilities directly help people who needs to write efficient, reliable, and maintainable code. If you don't use these facilities, you typically end up simulating them with lower-level language constructs.

Even the "new"/"advanced" features of C++, such as templates, exceptions, and run-time type information (RTTI) are designed to meet the 0-overhead rule. If you need such features, it is more efficient (in run-time and memory space) to use them with a modern compiler than to fake their functionality in C. I do not know of a C++ language feature that has not been found useful and affordable by someone in some systems or embedded application.

Naturally, if you don't need a feature (often, RTTI is not needed) or if is unsuitable in a particular context (I can think of programs where exceptions would be unsuitable), you just don't use that feature. The 0-overhead rule is there to allow such decisions. This is not so different from not using a C feature that is unsuitable for a given application (in some embedded systems, malloc() is banned).

C++ is as portable as C. In both cases you need to encapsulate the system dependences to ease portability. Large classes of programs are portable across Unix platforms, and some programs can be made portable across other platforms also. The techniques are well known and when used well, C++ even has an edge when it comes to formalizing the notion of a system to allow trivial portability. For example, see the C++ library that defines the ACE platform (link on my C++ page).

The technical hardest problem is probably the lack of a C++ binary interface (ABI). There is no C ABI either, but on most (all?) Unix platforms there is a dominant compiler and other compilers have had to conform to its calling conventions and structure layout rules - or become unused. In C++ there are more things that can vary - such as the layout of the virtual function table - and no vendor has created a C++ ABI by fiat by eliminating all competitors that did not conform. In the same way as it used to be impossible to link code from two different PC C compilers together, it is generally impossible to link the code from two different Unix C++ compilers together (unless there are compatibility switches).

The current solution is usually a combination of using a single compiler and of providing C-level interfaces. This is not ideal - see also my answer to question 10.

That said, I think the main problem is educational. Many simply have seriously inaccurate ideas of what C++ is and what can be done with it. Often "inaccurate ideas" add up to a strong disincentive to learn. C++ is now very different from Release 1 from 1985. The ISO standard for C++ was ratified in 1998 and current compilers approximate it well enough for me to move programs that stress the newer facilities from compiler to compiler for performance testing on a variety of platforms. The standard library makes a difference here.

3) What would you do differently?
by spiralx

If you could go back to when you designed C++, what would you change and why?

Bjarne:

You can never go back. However, I think my most obvious mistake was not to introduce templates before multiple inheritance and not to ship a larger library with Release 1 of my C++ compiler. The two mistakes are somewhat related.

The reason I didn't ship a library was that I didn't know how to write one that was good enough. To get efficiency and type safety for containers, you need templates (and I didn't have an implementation supporting templates until 1988 or 1989). However, templates are not enough, you also need a design for containers and uses of containers that can deliver that safety. We didn't have such an architecture until Alex Stepanov came along with the STL. If you want a real firework of interesting opinions and insights, read this interview with Alex. The STL is the nucleus of the C++ standard library, providing the standard containers and algorithms, and the framework for their use and their extension with user-defined containers and algorithms. Naturally, this is extensively discussed in "The C++ Programming Language."

One problem with introducing MI before templates was that it encouraged further overuse of class hierarchies. Templates provide a simple and efficient alternative to some of the more contorted uses of inheritance.

Let me just mention something I wouldn't have done differently: compatibility. Had C not been there to be compatible with, I'd have chosen compatibility with some another language. Innovation should focus on improvements and what works should be left as unchanged as possible. That way, people keep their existing tools and techniques and can develop from a base that is functionally complete. Also it saves the effort to re-invent the wheel and to teach "new" stuff that is equivalent to old stuff. Thus, C++ is as close to C as possible - but no closer.

The flip side of this is that you have to deal with old mistakes and with compatibility problems. For example, I consider the C declarator syntax an experiment that failed. Nevertheless, I adopted it for C++. The alternatives and improvements I considered at the time would not have improved matters. I rate is as a minor problem. The more serious problem is to maintain closeness of language definitions as C evolves.

Also, there is no major language feature, I'd remove for Standard C++ - even in retrospect. New major facilities have to be added with care. Often, a library can provide functionality that people thought required language changes.

I think the C++ standards committee did a good job. It is not easy to create a consensus about a specification. Commercially competing companies have to agree and nations with conflicting traditions of standards work have to be satisfied. However, I think that the the time and effort was well spent. Standard C++ is a better approximation to my ideals than any previous version, and a great standard library to go with it. The time and effort is necessary unless you want to give free reign to "de facto standards" and proprietary languages. My 3rd edition describes ISO standard C++ and current C++ compilers approximate the standard.

4) Why no templated typedefs?
by Venomous Louse

Well, this is weird. Just the guy I wanted to talk to this morning!

It would occasionally be handy to have typedef templates (or template typedefs?! help!), something like this:

template
typedef bool (* func)( const T &r );

. . . but that doesn't seem to be legal. I don't recall seeing anything about this issue in The Design and Evolution of C++. So what's the deal?

Bjarne:

I, and the standards committee, underestimated the importance of templated typedefs. My guess is that they will be added in the future.

Actually, D&E (pg 357) does discuss templated typedefs and points out a technique that is often an alternative:

The extension is technically trivial, but I'm not sure how wise it would be to introduce yet another renaming feature.

Derivation also allows for partial specification of template arguments in the definition of a new type: template class X { /* ... */ };
template class XX : public X { };

I guess that in this case, my reluctance to add new features without a clear practical need caused problems. I'm more often accused of the opposite mistake - to be too aggressive in adding features - but as people learn to use what is available, new requests based on new experience are starting to appear.

Incidentally, your example "function of T returning a bool" is often best represented as a function object. And function objects are natural templates:

template
struct Predicate {
bool operator()(const T &r) { /* ... */ };
};

This way, you don't need a typedef; you can simply say:

Predicate* p;

Function objects also inline better than pointers to functions, so their use leads to faster code as well as cleaner code.

In general, I recommend "The Design and Evolution of C++" for people with "why is/isn't it like that in C++?" questions.

5) Question...
by MrHat

I (and maybe most of "us") know you solely through your creation of the C++ language and your assistance in authoring the ANSI standard for said language.

Aside from this one (albeit major) project, what do you work on from day to day? What projects are you currently involved in? Do you have any more language definitions/standards in the pipeline?

Bjarne:

C++ related work is a major part of my day. The standard is in "maintenance mode," but it still requires a bit of attention. I do some work related to libraries and programming techniques (I'll have a paper on "wrappers" in "The C++ Report" later this year), and I worry about the poor state of C++ education - and the way C++ is often seriously misused by misguided programmers. Look at me paper "Learning Standard C++ as a New Language" (download from my papers page). As you can see, I write a bit, give talks, and interviews.

In the standards committee, I'm spending most time on the performance working group. This group was created to investigate sources of inefficiency and implementation and programming techniques to deliver "lean and mean" code. Embedded systems is one area where this is needed. The current language allows close-to-optimal solutions, but not every implementation is well tuned for that degree of efficiency, and not every programmer knows the basic techniques for delivering compact and efficient code.

There is - as ever - much talk about extensions and new libraries on the net, but the C++ community still haven't learned to fully utilize the new facilities. My guess is that there is a lot of benefits to be had from better libraries. The Standard library in general and the STL in particular shows some of what could be done. Eventually, some of those new libraries will be standardized.

I'm trying to understand distributed computing better. To that end I read a lot and experiment with computerized gadgets. I worry about mobility, reliability, fault tolerance, and security. These areas of research were among the ones that led me to the design of C++, so in a sense I'm returning to my roots in "systems." Being a manager at AT&T Labs - Research also takes some time, but not as much as you might think, and it doesn't feel like real work: in that capacity, I don't produce code or technical literature.

6) Multiple inheritance
by MosesJones

Three linked questions:

a) Do you think that multiple inheritance is a requirement for a true OO Language?

b) When designing a system with multiple inheritance what do you see as the pitfalls to avoid, especially when it comes to maintainability?

c) Do you know of anyway to simplify the readability of multiple inheritance to enable first time users to do less damage?

Bjarne:

If you rely on static (compile time) typechecking, you need MI. If you don't have MI, many programs get contorted and you have to use explicit type conversion (casting) far too often. I wouldn't claim to know what - if anything - is "a true OO Language" but if you have to use explicit type inquiry essentially all the time, you don't have one.

I don't see MI as a particularly serious source of pitfalls. The obvious problem - which MI shares with single inheritance and every other powerful language feature - is overuse. I tend to use MI for simple aggregation and for adding implementations to interfaces. For example:

class network_file_error : public network_error,
public file_error {
// ...
};

and

class interface { // abstract class
// pure virtual functions
};
class base_implementation { // useful functionality
// data, functions, virtual functions
};

class my_implementation
: public interface,
protected base_implementation {
// data, functions
// override some base_implementation functions
// override all interface functions
};

In the latter case, you then have the users of my_implementation access it exclusively through pointers or references to interface. That was user code is independent on the implementation class and the system doesn't suffer from the so-called "brittle base class" problem. The implementation class can be exchanged for an improved version without recompilation of user code (except my_implementation itself).

Following those two styles avoids most problems. Naturally, you can find a more extensive discussion in "The C++ Programming Language (3rd Edition)" and in the new "The C++ Programming Language (Special Edition)." (See my home pages for details, sample chapters, reviews, etc.).

Actually, questions about multiple inheritance usually indicate that the questioner has been distracted into technicalities. To almost all programs, questions about use of abstract classes, templates, exceptions, and the standard library would bring far more benefits. MI is necessary in a statically typed language with inheritance, but it is not among the features that should be used most often.

If you focus on defining concrete classes to represent simple types and abstract classes to represent major interfaces, a good design is likely to emerge. Then, MI may or may not be needed to complete the program, but will be pretty obvious where it might be needed.

7) Questions
by Edward Kmett

Is there any hope for the introduction of constrained templates? Right now using templates is an exercise in willpower for the programmer. I know that constrained genericity went before the committee when templates were first introduced, but has there been any thought to revisiting that decision?

Another item that has gained a lot of momentum in the Eiffel community is Design by Contract, for which I would love to see a standardized approach in C++, but I doubt I'll ever see it.

Lastly, Bjarne, you were quoted once as saying 'When (not if) reference counting becomes available in C++ that it would be optional' (in a book on object oriented programming languages of which I cannot find on Amazon at the moment to post the ISBN). Has much progress been made on the front of making reference counted objects available? Or has your thinking changed since you were quoted?

Bjarne:

Actually, what I said was something like "When (not if) auotmatic garbage collection becomes part of C++, it will be optional".

Reference counting can be very useful for less frequently used resources, but I'm not advocating it as a general mechanism for keeping track of memory. C++ has good mechanisms for keeping memory management under control (such as constructors and destructors and the standard library containers), but if you need something more automatics, plugging in one of the available garbage collectors is the right answer (see section C.9.1 of "The C++ Programming language", my C++ page, or my FAQ).

Incidentally, the ISBN for the new hardbound "Special Edition" is 0-201-700735 and the ISBN for the softbound "3rd Edition" is 0-201-889544.

"Constraining" templates without taking away their power isn't as easy as it sounds. See D&E for a detailed discussion. One problem is that if you express template argument constraints in terms of base classes, you warp your system design towards a style where every property becomes a base class. This easily becomes a mess of over-used multiple inheritance and indirect expression of things that are better said directly. For example, It's clearer to say that a class must have a Specialization and partial specialization provide much of the expressive power that people want from constraints. For example, if I have a general sort template

template void mysort(Container& c);

and I want want special sort algorithms for vectors then I can simply write:

template void mysort(vector& v);

I'd like much better error messages from templates with type errors. Some of this can be done with better compiler technology (people are working on that) and some will be hard to do without some kind of template argument constraints/checking (but I don't know how to do that). Fortunately, a programmer can help. Consider the example I gave in my answer to question 1:

template
void draw_all(Container& c)
{
for_each(c.begin(),c.end(),mem_fun(&Shape::draw));
}

If there is a type error, it will be in the resolution of the fairly complicated for_each() call. For example, if the element type of the container is an int, then we get some kind of obscure error related to the for_each() call (because we can't invoke Shape::draw() for an int).

What I really wrote was:

template
void draw_all(Container& c)
{
Shape* p = c.front(); // accept only Shape*s

for_each(c.begin(),c.end(),mem_fun(&Shape::draw));
}

The initialization of the spurious variable "p" will trigger a comprehensible error message from most current compilers. Tricks like this are common in all languages and have to be developed for all novel constructs. In production code, I'd probably have written something like:

template
void draw_all(Container& c)
{
typedef typename Container::value_type T;
assert_equiv(); // accept only Shape*s
for_each(c.begin(),c.end(),mem_fun(&Shape::draw)); }

This makes it clear that I'm making an assertion. I leave the definition of assert_equiv() as an exercise to the reader :-)

This leads use to the second part of the question: design by contract. Since "design by contract" is a design style, you can apply it to C++. To do so you need to use asserts systematically. I personally prefer to rely on some specialized assert templates (see my 3rd edition). I agree that some such templates are good candidates for standardization as part of the library.

However, I don't think we'll see direct language support for things such as preconditions and postconditions. I don't think that pre- and postconditions written in essentially the same language as the program itself are a significant improvement on asserts(). Also, I'm not sure that the checking of class hierarchies afforded by language-supported conditions is worth the effort. For starters, people can gain very significant benefits today using current standard C++ simply by using assertions more systematically.

8) A quick question (ha!)
by jd

C++ is an Object-Based, rather than a "pure" (in a Software Engineering sense) Object-Oriented language. However, it's still centered around the notion of objects, rather than procedures.

However, all existing processors are procedural, and there is no real concept of an OO CPU.

Do you feel that OO languages, such as C++, will result in OO systems, at the hardware level, or will it always be easier to confine OO thinking to the abstract, using extremely complex compilers to translate between OO and procedural paradigms?

Bjarne:

One of the things I worked with before designing C++ was architectures for direct support of "higher level" facilities. I came to the conclusion that as long as hardware were growing cheaper and faster at a rapid pace, sowtware-based approaches would have an advantage over high-level hardware. These advantages are in cost, in flexibility, in the number of potential users, and in the vintage of computers that the software could run on (it takes longer to design and build a high-level machine than a traditional one).

In the forseeable future compilers mapping high-level constructs onto low-level hardware primitives will be the dominant approach.

9) C++ complexity vs. OOP simplicity
by hanwen

[Sorry for the potential inflammatory matter in this question].

How do you relate the complexity of current C++ with the much-touted simplicity of Object Oriented Programming?

Longer explanation:

Over the years, the C++ implementation has ballooned; If I recall correctly, your book the C++PL has more than doubled in size. C++ has become a very large and complicated language, and I doubt whether there are any individuals (besides you, that is) that know the entire definition by heart, let alone teams of programmers.

This means that it is not practical to use C++ fully in any project, and one also has to set strict guidelines for a project what features to use and which not. Seen, in this light, it is doubtful whether C++ has made writing software more manageable. So I think, that as tool for writing better software more efficiently, C++ is a failure.

C++'s evolution was motivated by a few mottos (you don't pay for what you don't use, C compatibility, etc.), and seen in this light, C++ is a success. Do you think that these mottos need reconsideration?

Bjarne:

Inflammatory? I think you are remarkably polite and technical here - and that your "editor/moderator" weeded out the real flames :-)

Complexity has to go somewhere and I think that putting it in the language in the form of direct support of common and powerful techniques is a good idea (or else I wouldn't have done it :-). Have you seen C code that simulates class hierarchies, parameterized types, or exceptions? Such code tend to be a complete mess of pointers, casts, and macros. In C++, such code can be clean and simple. Most importantly, the constructs have well-specified semantics rather than just comments explaining the intent of code fragments. What has happened is that the complexity has been transferred from the code to the language definition (and compiler).

You are right that there is little need to use all of C++ explicitly in every project. However, that doesn't mean that you need to impose restrictive "gudelines". When did you last use all of Unix or all of NT explicitly on a project? Would you like some manager to tell you exactly which OS facilities you could and couldn't use - independently of the nature of a project?

The typical "guideline" is straight out of the dark ages, based on information about the state of the world years ago and on strange assumptions on what is and isn't complicated. In the defense of people issuing such "guidelines," it must be said that the educational establishment has on average done a poor job at focussing students on the key programming techniques that are effective in C++. The results have been much muddled C-style code combined with bloated Smalltalk-style class hierarchies. The common denominator for these sub-optimal uses of C++ is losts of casts and lots of macros.

That said, I have seen many successful C++ projects (many more than failures) and much good C++. By good I mean, elegant, efficient, reliable, and maintainable. So, for many, C++ has delivered exactly what it was designed to deliver. Please remember that I made few, specific, and well-documented promises about C++ (See D&E and "The C++ Programming Language"). I was not a contributor to commercial OO hype.

I think I see a correlation between successful use of C++ and respect for its limitations (the deliberate constraints on its design) and a willingness to adapt design approaches to the facilities offered. For example, if you reject the use of abstract classes and build deep hierarchies with lots of data defined at each level, you really shouldn't be surprised by long compile times, frequent recompilations, and problems understanding what is defined where. Similarly, if you refrain from using C++ facilities and litter your code with C-style strings, arrays, plain structs, and lots of pointers into low-level data structures, you shouldn't really be surprised to get C-style problems rather than the promised benefits from C++.

The main tutorial presentation of the C++ language was 186 in the 1st edition, 282 pages in the 2nd, and 360 pages in the 3rd. Part of that increase is a greater emphasis on programming technique. The rest of the increase in book size (from 327 pages in the 1st edition to 1040 pages of the new special edition) is due to more information on programming and design technique, and the standard library. The "special edition" has 363 pages on the standard library - in addition to the uses of the standard library as examples in other parts of the book.

10) Questions for Bjarne
by scherrey

I was introduced to the C++ language in 1989 on the BIX online service by you and Greg Comeau whereupon the both of you set out to demonstrate (and finally convinced me) that this OO stuff wasn't just a fad and that C++ was a language that could efficiently implement it. This was during the time when Computer Language magazine had there "Language of the Month" feature article so languages had a tendency to come and go quickly back then.

As I recall, the two major goals that you stressed were a) to build a language that could get a handle on these huge projects that C was having difficulties with and b) to provide a balance of features and efficiency so that a developer should have to pay for features he doesn't use.

From my own experience using C++ in an extreme variety of projects (including very cramped embedded systems and large, multi-platform enterprise systems), there's no doubt that the great progress has been made on the first goal and that the second might have been fully achieved.

The biggest disappointment to me, however, has been the lack of ability to fully replace plain-old-C in system level development which is an area that stands to gain the most from the language's abstraction features and your stated goals of the language. I understand that early on, it would have been impossible to define standard ABI's since implementation techniques for things such as virtual method and inheritance resolution were very experimental. Now that a full decade has gone by and a surprisingly strong standard has been produced, these differences in implementations are more contrived than based on architectural considerations.

Presently the Open Source movement is growing wildly in popularity in commercial and non-commercial segments of the industry. Unfortunately, C++ cannot be used to provide linkable API's without either downgrading to severely limiting C-based linkage or forcing everyone to use the same compiler that wants to call your library because of non-standard representations of structures and calling conventions.

Do you think that standardized application binary interfaces should be a priority time now? If so, what should be the mechanism used to define these interfaces (defacto vs. formal standards, etc), who should do it, and what can be done to encourage this development?

Bjarne:

Hi Ben,

I think I nailed the efficiency, the generality, and to some extent the elegance. However, I underestimated the linker problems. I may also have underestimated the problems stemming from C compatibility.

If I were a platform provider, I would have made a C++ ABI a priority a couple of years ago, so that all vendors on my platform could be ready to provide conforming implementations when the compilers reached a high degree of standards compliance. I know such efforts have been started by Sun for SPARC and by a group of vendors for Intel's upcoming Merced architecture (IA-64, see http://reality.sgi.com/dehnert_engr/cxx/).

I would encourage everyone - and especially people who write software intented as part of a collaborative efforts - to encourage such platform ABI standards. If you are among people who can, lobby for a C++ ABI on your favorite platform. Unfortunately, I don't have specific suggestions on how to do this.

The compatibility with C at the system interface level has encouraged people to use C-style strings, arrays, and structs, where they would have been better off with some higher-level abstractions presented as classes or templates. Instead of leaving the low-level facilities at the system level and within the implementations of classes, people have let the low-level constructs - and pointers to them - permeate their designs. Type errors, wild pointers, array bounds errors, and memory leaks are the obvious results. Lots of macros and casts often adds to the obscurity of the code. It saddens me to see some of the unnecessary messes people get themselves into.

Poor educations is part of the problem and better education must be part of the solution. However, education can only do so much. Libraries and tools must that takes advantage of modern C++ must become ubiquitous before we can expect novice programmers to venture out of the C subset and apply more powerful techniques.

For starters, people ought to realize that starting to learn C++ is easier than starting to learn C. The optimal initial subset of C++ to learn is not "most of C" and C++ can provide a much smoother learning curve than is commonly done. See "Learning Standard C++ as a New Language" (download from my papers page) for a further discussion.

We have always had applications and specialized libraries that used C++ to give programmers a higher-level environment to work in. One significant aspect of the standard library is that it provides an example of that to everybody. Writing code using standard facilities such as string, vector, map, and algorithms really can change the way people program and the way people think about programming. I hope to see the techniques used for defining and implementing the standard library applied in many other areas to yield equivalent benefits in source code size, type safety, code clarity, and run-time efficiency.

I think the time has come to experiment with the more advanced/interesting parts of Standard C++. For example, my new Standard-Library Exception Handling appendix shows a style of programming that departs rather dramatically from "C common wisdom" yet leads to simpler code. This is not written for novices, though, but it gives a peek into the inner workings of the standard library.

Naturally, we must be more cautious in production code and there compatibility concerns with older code weighs stronger. However, we should not be so bound by older styles and compatibility that we never dare try out more modern and more effective styles. There now are native C++ styles, and we should use them.

-----------

I did take peek at the "raw questions" on slashdot.org. I had to resist the temptation to explain all of C++ here, and explain how to use it, and explain why the facilities are the way they are. For more information, have a look at The C++ Programming Language (Special Edition), The Design and Evolution of C++, and my papers.

It appears that I'll have to update my FAQ with several new questions, but that'll take me a few weeks.

Thanks for asking hard questions.

- Bjarne


Update: 02/28 02:14 by R : Additional comments...

Comment by Anonymous Coward
Friday February 25, @12:53PM EST (#44):

Some really, really interesting stuff. I'm going to forward this to everyone at work here.

My only negative question is did he have to plug his books so much?? It seems like he never passed up a chance to "refer to my 3rd edition of C++PL", etc..... I tend not to trust people who plug themselves and their products too much.

This, of course, is a minor concern. Thanks to /. for getting this great interview!

Bjarne:

Imagine a radio interview with a serious painter or sculptor. To such an artist, his/her work is what matters, but there is no way that work can be presented on the radio. You would expect many references to individual works and to museums where people can go to see such work. Descriptive words simply aren't enough. Poor artist can compensate by distracting the discussion away from their work and into their personal lives or politics, but that's not an option for serious ones.

I'm not an artist, but for an interview like this, I have a similar problem. I want to show code and serious discussions of problems, but the Q&A format doesn't allow that. My solution is to refer to my published work and to my homepages.

After all, my published work are the primary sources on C++. So, unabashed, if you want more see my home pages, read TC++PL, D&E, or my papers.

C++ and scientific computing
by J. Chrysostom on Saturday February 26, @12:32AM EST (#308)

As a soon-to-be graduate student in scientific computing, I sit and wonder sometimes why the support for mathematical and scientific computation in C++ is so limited. FORTRAN, the ugly and unmanageable beast that it is, is the only haven for computational mathematics.

Bjarne:

Have a look at the links to numeric libraries in C++ (such as Blitz++, POOMA, MTL, and ROOT). Maybe also track down some of the numeric C++ pages.

Comment by Davorama
Friday February 25, @12:37PM EST (#22)

These other questions were so great I didn't make the cut but maybe you folks have opinions you'd like to share?

What do you think of template meta programming? Do you consider it a boon, enabling clever programmers to do outrageously cool things like the Blitz project? Or is any benefit derived from it's use washed away by the obscure, nearly unreadable code it takes to implement it?

Bjarne:

I really like some of the things being done with C++ in numerics. The common thread is that templates are used to eliminate spurious temporaries. The results tend to beat Fortran in its own game while maintaining Math textbook notation. On my homepage you can find links to POOMA from LANL, Blitz++ from Warterloo U., and MTL from Notre dame. TC++PL has an explanation of the basic technique in the Numerics chapter.

I don't mind the obscure code in the implementations. Actually, I find most of that code far less obscure than, say, C kernel code. Where efficiency is paramount, you shouldn't complain too much about obscure optimizations, and anyway if you are a real user, you shouldn't read the implementation code.

Comment by sethg
Friday February 25, @01:12PM EST (#65):

A common theme in the answers seems to be "that complaint is based on outdated information; get a new compiler that follows the standard and use the STL."

For the benefit of us C++ newbies, does anyone maintain a chart showing which currently-available "C++" compilers violate which sections of the C++ standard?

Bjarne:

A first approximation: Compilers currently shipping from major suppliers are reasonably up to date (I use them). Examples include. Borland, GNU, Metrowerks, Microsoft, and SGI.

For more details see LANL's list (link from the POOMA site, see my C++ page) or a site in NZ that tries to keep track. Some vendors, such as Borland, keep the results of the Plumm Hall validation suiye public on their websites.

And, yes. It is my opinion that a very large proportion of problems reported with C++ can be traced to misunderstandings and misuse. A modern C++ implementation is a prerequisite for trying out some of the techniques that I'm suggesting, but please don't think that a new compiler by itself will help much. You need to actually change the way you work - and unfortunately there are many real-world factors that makes such changes hard (legacy code, lack of time to learn new techniques, co-workers, antique style rules, etc.). I dit not say it would be easy, just that it is possible and that many have succeeded.

Comment by hanwen
Friday February 25, @01:25PM EST (#77)

-- much stuff omitted --

Maybe nowadays some of my gripes may be soothed by the Standard Libraries, but I don't feel like learning yet another big C++ component, all the more because I know that afterwards C++ will still not be good enough (or will it ever have reflection, higher order functions, GC?)

In this light, I find your statement that "starting to learn C++ is easier than starting to learn C" dangerous, as are the examples in your "learning C++ as a new language paper" for they imply that any of these two languages can or should be a "first" language.

Do you really want people grow up with a language that has distinction between non-immediate objects on the heap and stack, no automatic garbage collection, pointers, no initialization, no higher-order anything?

You're educating people about C++: fighting misconception, telling them where it is good for. But you're not telling them what it is bad for. C++ is immensely popular, and people easily get the misconception that this popularity makes it a good language to start programming with, or to write their highly tweakable programs, etc.

Bjarne:

Actually, yes. I don't feel that it is right to start off people with a language that they don't have a chance using once they graduate. The Lisp and functional language community failed to make automatic garbage collection and higher-order everything mainstream even though they had the enthusiastic backing of the academic and educational establishment for more than two decades. Clearly, I don't feel that leaving people with a lower-level language like C is optimal either.

Given the current miserable state of programming and design education, C++ can be a major advance. Of course, people can also fail to take advantage of C++'s abstraction mechanisms and fall back to writing the equivalent of assembly code in C or C++. Through STL, the C++ community may have introduced more people to functional programming techniques and may have applied such techniques to more real-world problems than all previous languages put together. The fact that function objects are not the most flexible "closures" available doesn't detract from the fact that people understand them, like them, and use them.

The "Learning Standard C++ as a New Language" paper (link on my papers page) clearly states that I think that these approaches scale - and argues why. Looking at C++ as it was in 1988 (no templates, no exceptions, no RTTI, and no standard library) is really to look at a different language - one that simply doesn't support most modern C++ techniques.

If you want garbage collection, then there are excellent free or commercially supported garbage collectors available for C++ (see links from my C++ page). One reason that the C++ garbage collectors are so effcient is exactly that C++ has the distinction between stack-allocated objects and free-store-allocated objects.

Comment by Anonymous Coward
Friday February 25, @02:54PM EST (#118)

Yeah this is the guy who at one time usurped the name "C" for his new language, and was referring to K&R as "old C" around AT&T ... until Dennis Ritchie told him to knock it off :)

I think he does acknowledge that the committees have straightened out a lot of the problems in the earlier versions of the language, and I don't think he would claim current C++ is perfect.

Given his success and recognition, I'd probably be a bit arrogant myself :)

Bjarne:

I don't actually think that I'm seriously "humility deficient".

Remember, I worked with Dennis (though not closely) and closely with Brian Kernighan for more than a decade. I don't think I "appropriated" the name "C", but if I had, nobody would have had a better claim to it :-)

It was not me who referrend to C as "Old C." It was me who acted to defuse the confusion and the possible slur on Dennis by finding a name for "C with Classes" that was less likely to cause confusion: C++.

Also, I worked hard in the committee (few language designers have bothered with such "tedious details"), and I think the committee did a very good job.

cancel ×

386 comments

Sorry! There are no comments related to the filter you selected.

AGREED (0)

Anonymous Coward | more than 14 years ago | (#1245895)

if u dont like gatez then that prob means ur a GAY COMMIE!!!! COMMIES/LINUX ZEELUTZ ARE RUINING THE COUNTRY OF AMERICA!!!!!

TRoLL

Re:High Quality? (0)

Anonymous Coward | more than 14 years ago | (#1245931)

yep

TRoLL

He had a tough crowd (0)

Anonymous Coward | more than 14 years ago | (#1245938)

He did mention things that he'd wished he'd done better or different, like a better/earlier standard libaray (amen!) and promoting a C++ ABI. What do you want, a confession?

Well put! (0)

Anonymous Coward | more than 14 years ago | (#1245940)

And I think I speak for nobody (including myself) when I say that.

Re:The problem with C++ (0)

Anonymous Coward | more than 14 years ago | (#1245943)

Dude - don't talk about Torvalis that way!

As long as we're talking C++... (0)

Anonymous Coward | more than 14 years ago | (#1245945)

Trying to use gdb with the STL drives me nuts! I get stuff like:

(gdb) print Rollover
$1 = {start = {cur = 0x8061544, first = 0x8061510, last = 0x8061710, node = 0x80604a4}, finish = {cur = 0x8061554, first = 0x8061510, last = 0x8061710, node = 0x80604a4}, map = 0x8060498, map_size = 8}
(gdb) print Rollover.start
$2 = {cur = 0x8061544, first = 0x8061510, last = 0x8061710, node = 0x80604a4}
(gdb) print *Rollover.start.first
$5 = 0

Is there a better way to get to the debugging info I want without wading through the STL intestines? MS VC++ seems to handle that much more cleanly... (as much as I hate to say it)

question.. (0)

Anonymous Coward | more than 14 years ago | (#1245947)

does alan cocks/linis trovalds use this in the kernel or is it mainly C?

Re:templates? (0)

Anonymous Coward | more than 14 years ago | (#1245948)

I've been and am somewhat still in that same boat. when I took my first comp sci course. I was on a mission to dethrown stroustrup as the jedi master c++ programmer, (of course Im still in training). but my suggestion is spend a few hours at the barnes and noble or your local bookmark and browse around. the books I saw are usuallu expensive. but... "21 ways to improve your c++" or something similar to that. is excellent. as I was. I just looked it up. "Effective C++..." by Scott Myers. I have both editions. The key to being good is mastering the basics. then everything is easy.

RTFA (0)

Anonymous Coward | more than 14 years ago | (#1245952)


I was looking for some reference to "I wish I had done that better" or something.

Have you considered reading what he wrote? That might be a good way to find out what it says.

God knows the man has an ego, but your comment just isn't accurate.

GDB sucks.. (0)

Anonymous Coward | more than 14 years ago | (#1245957)

compared to every other debugger out there. Yes, I know it's portable and free. But I'd rather use almost *any* other debugger for actually debugging.

Oh, yeah, one more thing: (0)

Anonymous Coward | more than 14 years ago | (#1245959)


If it is on the exam, you're fucked.

Sorry.

Yes, a confession. He is a criminal. (0)

Anonymous Coward | more than 14 years ago | (#1245962)


Stroustrup is denying the validity of my opinions by refusing to agree with them. This is tyrrany. It's a symptom of the radical left-wing nature of the C++ programming language: It's completely -- one might even say brutally -- authoritarian. Linguistic sovereignty resides in the very broadest possible level of authority: The International Standards Organizaiton. I don't think I really need to clarify the implications of that, do I? Or maybe I do: Your mindless, slavish parrotting of the Party Line demonstrates a level of delusion and pure ignorance consistent with liberalism or worse.

The very concept of coercive language design, much less a militantly centralized standards process, speaks of a violently dictatorial and anti-American point of view regarding programming. The language should be defined at the local level, by committees of Christian men of known good character. This, of course, will never happen: The socialist establishment is hell-bent on chipping away at every vestige of sovereignty left at any level below the UN. This is to serve their short-range goal of totally annihilating all wealth creation in the world. When they've done away with wealth, the world will be ripe for the next and final stage of their conquest: The imposition of an infinitely cruel medieval agricultural slave-state. Cambodia was their dress rehearsal, and it went well. Clinton came back from his apprenticeship in Cambodia ready to take on his assigned role as the so-called "Final Controller" of what the liberals call "The United States Occupied Zone". He has done well. We will not be permitted to remove him. We tried once, with undeniable evidence of his treasons and murders, and we were defeated. He will never leave office. His ultimate reward will be an appointment as the first King of the USA, which in its medieval slave-state form will be known in liberal terminology as "Subdued Slave Zone 53". Ignore the election. It's just window dressing, circuses to keep the plebians distracted while the real work of conquest is done. The real decisions have already been made. Your "excess" children will be ground up and sold as dog food in accordance with the protocols of the Gore Population Control Agenda.

Thanks, I'll check those out. (0)

Anonymous Coward | more than 14 years ago | (#1245963)


.

Re:templates? (0)

Anonymous Coward | more than 14 years ago | (#1245964)

Though it may not be the best book to learn a first programming language from, I would encourage anyone interested in C++ to struggle through Bjarne's The C++ Programming Language, 3rd Edition (the "wave book"). It does an excellent job of explaining why features are the way they are, presenting clear examples of subtle points and inculcating the proper mindset to have to program effectively. I read the 2nd edition (the "gray book") so frequently that the binding broke and all the pages separated -- I guess I loved it too much --, and the 3rd edition was heading that way until I started redirecting my non-work efforts into Linux, Python and internet stuff -- though with KDevelop I will be getting back into the C++. C++ can be a difficult language to use effectively (or rather, it is an easy language to use improperly), but it is an absolutely essential language -- as close to the metal as one can get without writing assembly (I recall Bjarne stating that one of his objectives was to obviate the need for any language between assembly and C++), but providing the abstraction tools necessary for the structuring of larger-scale projects. What I like about C++ is that it adds to C the bare minimum of higher-level features necessary to accomplish this goal. Higher-level languages like Java or Python are great (I have given up writing smaller (several hundred line) programs in C++ unless they are very speed sensitive, and now write them in Python), but in a way C++ is like the sports car that gives the driver total control while these other languages can at time feel plush-upholsteried, automatic steering, automatic transmission Cadillacs. Bottom line: long live C++, long live Bjarne!

Re:templates? (0)

Anonymous Coward | more than 14 years ago | (#1245965)

MUUUHHHAAAHHHHAA!!!

That's +5 Funny!

Angle Brackets Missing (0)

Anonymous Coward | more than 14 years ago | (#1245966)

< (&lt;) and > (&gt;) have fallen out of the templates in this interview. Fix that at once!

Thank you!

Great interview (0)

Anonymous Coward | more than 14 years ago | (#1245967)

This was a great interview - thanks to all involved, especially Stroustrop. You made my day!

I think Bjarne is right about the state of C++ edu (0)

Anonymous Coward | more than 14 years ago | (#1245968)

I'm a 3rd year computer engineering major and so far I've taken a lot of really crappy programming classes. No one even mentioned templates until the 3rd or 4th programming course I took, even though our programming assignments would have been much much easier with generic containers. Luckily I was curious enough to read ahead. Also, the textbook I had only mentioned multiple inheritance in passing, and didn't explain at all how it was implemented and how it might be used. To this day not a single class I have taken has even mentioned C++ exceptions, which (now that I know what they are) are a very powerful tool.

I was really getting fed up with C++ and a lot of things that I wanted to try but couldn't figure out how to code because I didn't really know how to use the language (or what features the language really had). I read (well I'm about 2/3 of the way through) Bjarne's The C++ Programming Language, 3rd ed. and it's been consistently answering every question I've had about the language, like questions about templates and their capabilties, why certain language features are the way they are, and how all the language features were designed to be used together.

I would very enthusiastically recommend TC++PL if you're already comfortable with programming and want to learn how to effectively use the advanced features of C++ (or learn what they are if your classes aren't explaining them), but like others on this board have said, it's not a programming tutorial, so if you're just starting to program it might be wise to hold off for a little while.

-Mike

You should consider learning C++. (0)

Anonymous Coward | more than 14 years ago | (#1245969)


You sound like somebody who writes a 10,000 line C program all in main() with goto's, and then turns around and starts bitching about what a rotten language C is because it doesn't have line numbers. A good C programmer would spend ten minutes with such an idiot trying to explain how C is used, and if the idiot still insisted that C was BASIC, the good C programmer would use an important language feature called a baseball bat to modify the idiot's life-expectancy.

You're missing the point in a very profound way. You're using a saw to drive a nail, and cursing the saw.


typedef void (*fptr)();
..
fptr[2] = {&func1,&func2}
for (int i=0; i ...


True, that stuff's a hassle in C, but in C++ you can use an STL container for whatever you're keeping a list of, and use std::for_each() to call a function on each item in any given container. If you need to pass some arbitrary argument to your function, it's perfectly trivial to write a single (one, only one, single, solitary, not plural, only one, the number between zero and two, as in ONE) function template that takes an extra argument and passes it to the callback for each item.

The problem here is that you don't know C++, and yet you're bitching about it. You are not using the relevant features of the language, and you're complaining that they're not there because you are too arrogant and lazy to RTFM and find out about them.

learning Python and LISP has made writing C++ a generally painful experience for me.

Learning C++ would make writing C++ considerably easier, if you were bright enough to grasp the fact that you do not understand what you do not know.

I don't feel like learning yet another big C++ component,

So quit whining. If you don't want to learn the language, that's your problem, not ours. In any case, it's not just the library you're not learning: You're refusing to learn a very important and central feature of the language (templates), and along the way you're utterly refusing to come to terms with the way the language was meant to be used.

Re:humility deficient (0)

Anonymous Coward | more than 14 years ago | (#1245970)


Yeah this is the guy who at one time usurped the name "C" for his new language, and was referring to K&R as "old C" around AT&T ... until Dennis Ritchie told him to knock it off :)

I think he does acknowledge that the committees have straightened out a lot of the problems in the earlier versions of the language, and I don't think he would claim current C++ is perfect.

Given his success and recognition, I'd probably be a bit arrogant myself :)

Re:ObjC (0)

Anonymous Coward | more than 14 years ago | (#1245971)

You're criticizing Obj-C readability because of people not writing comments? I could criticize any language for that -- and what I'd really be criticizing is the programmer.

Anyway, I can't stand C++/Java style message passing syntax. The Smalltalk/Objective-C style is so much more expressive. (And the typing system is much less confining.) I also don't see what's so "unreadable" about calling a function you can name. You don't have to use the feature, anyway, but when you need it, you tend to really need it.

Re:Complexity the cause of poor education? (0)

Anonymous Coward | more than 14 years ago | (#1245972)

I think it is a result of the complexity of the language. I found the learning curve for doing powerful things to be quicker for the Smalltalk/Objective-C line of languages. Java too. C++ just has too many features interacting in subtle ways; it's easy to get trapped by details.

Stroustrup isn't Kernighan, sorry (0)

Anonymous Coward | more than 14 years ago | (#1245973)

Amen!

Thankfully, there are two writers who do c++ justice. Scott Myers, and Herb Sutter. Scott's books (now he has everything on one low-priced CD-ROM) are mandatory for any c++ programmer, beginner or expert. Herb's book is a compendium of the 'guru of the week' posts on comp.lang.c++.moderated.

ObjC (0)

PHroD (1018) | more than 14 years ago | (#1245982)

i just dig objective-c more than C++ ...i find it more elegant and easier to write for and read (comments are alomost unnecessary as the code reads almost like english!) I think most people that say they cant understand it just have to wrap their brains around a few ideas in it, and maybe some not-exactly-C syntax, and they will discover how powerful an OO language it can be :)

"There is no spoon"-Neo, The Matrix
"SPOOOOOOOOON!"-The Tick, The Tick

Re:Complexity the cause of poor education? (0)

Zurk (37028) | more than 14 years ago | (#1245984)

The problem with C++ is that it basically sucks - it was meant as a powerful offshoot of C but instead turned into a large and *really* complex language..went waay too far out in the left field. Hell, even experienced C programmers cant pick it up easily. On the other hand, Java, besides its lack of multiple inheritance and all, was C++ done right. Java is easy to use, forgiving, has memory protection, easy to debug etc etc. In other words people - if you invent a proigramming language invent a forgiving one and one thats simple to understand for newbies. not everyone is an expert and this results in a cruddy mess of code like C++. there may be nothing wrong with C++ as a language or a compiler, but for most humans its a mess and the learning curve is simply *too steep*.

Re:ObjC (0)

SquierStrat (42516) | more than 14 years ago | (#1245985)

Actually no, you're just a a loser. :-) Cuz the Matrix == 2nd only to Star Wars.

Re:What about Java? (0)

shitface (121619) | more than 14 years ago | (#1245988)

His expresses quite a bit about his java views on his faq page. Look under the question thatgoes something like "If you hadn't designed c++ is Java the language you would of like to of made." He right away says no and explains that java is not really platform independent and a whole bunch of other goo.

Is it on the exam? (1)

Anonymous Coward | more than 14 years ago | (#1245991)


If not, don't even worry about it. Templates aren't going to be meaningful until you're reasonably comfortable with the rest of the language. For getting "reasonably comfortable" with the more commonly used features, I'd recommend C++: The Core Language from O'Reilly (the authors are Sapir and somebody else, IIRC). Templates are not covered in that book, but when you've mastered what is in that book, you should be able go to Stroustrup and deal with templates.

C++ is very large and complicated and you can't learn the whole thing at once. Stroustrup's TC++PL is an absolutely rotten tutorial, because it was never meant to be a tutorial. It's a reference for experienced programmers. It's not "Son of K&R". Stroustrup isn't Kernighan, sorry. It's often damned hard to decipher what he's getting at, and his discussion of templates in TC++PL is totally unsuited for beginners.

Here's the most simple and trivial template example I can think of:


template<class T>
class foo {
public:
T data;
};

foo<int> bar;
bar.data = 8;


foo<int> bar creates an instance of a class based on foo, with the type argument (int) substituted for each appearance of T in the template. Thus bar.data is of type int.

The above example is, of course, not useful code. If you can't imagine any uses that are useful, learn C++ first (or contemplate what it would be like to write one linked list, and then use that one for the rest of your life on any data type you want). You'll eventually start to "get it".

Actually, the BeOS kernel and drivers are in C (1)

Anonymous Coward | more than 14 years ago | (#1245992)

I do BeOS programming as a hobby and think it is fabulous, but the system-level stuff isn't in C++. According to Be, it is about 95% straight C and 5% assembly. The programming interface, however, is a really well-designed set of C++ classes along with some C functions. It is really quite straightforward (and fun) to write GUI-based apps using these objects (usually your own inherited versions). For anyone interested in learning C++, I would highly recommend trying BeOS (especially since they are about to start giving it away for free). There was a Be newsletter article around the holidays entitled something like "Using C++ in the kernel" that explains why, in general, you can't write BeOS drivers in C++. It was way over my head, but it had something to do with the order in which libraries are loaded in the two languages.

Why unix developers still prefer c (1)

Anonymous Coward | more than 14 years ago | (#1245993)

they do because they don't do a lot of gui work. systems programming can be done in c, and there is not reason to learn all the complicated stuff in c++ just for the sake of using c++. When you start working with gui elements and abstract interfaces you will quickly realize how tedious and unusable c is for that sort of work

Re:templates? (1)

Anonymous Coward | more than 14 years ago | (#1245994)

The best C++ learning book I've found is the C++ Primer by Lippman and Lajoie. It covers all the features and has simplified explanations with more detailed sections for those who want them.

The Effective C++ series by Meyers is damn near essential. It was the first book to really explain why some things were done the way they are.

Re:What about Java? (1)

Maryck (84) | more than 14 years ago | (#1245995)

I think a discussion of Java would have also been somewhat redundant. He has made his views on Java fairly well known on several occasions, so asking him here would have been slightly pointless and would probably have been major flamebait too.

Even so, you can pick up some of his attitudes towards java (or more generally, strict OO langs) simply based on the answers he presented here.

humility deficient (1)

lophophore (4087) | more than 14 years ago | (#1246012)

Wow! Can he do no wrong? I guess there's just nothing wrong with C++ at all. There's nothing that could have been better implemented.

I was looking for some reference to "I wish I had done that better" or something. Even Gosling has his regrets...


there are 3 kinds of people:
* those who can count

Re:What about Java? (1)

warmi (13527) | more than 14 years ago | (#1246077)

This is in the FAQ. Go and check it out - it is quite interesting.

Re:humility deficient (1)

RPoet (20693) | more than 14 years ago | (#1246082)

Scuse my ignorance, but what is Goslings regrets with regards to Java? Lack of multiple inheritance? Lack of operator overloading?

Re:Bjarne (1)

abelsson (21706) | more than 14 years ago | (#1246083)

i doubt he did it to make another buck or two, it sounded a lot more like he was trying to point out where you could find more info where the complete explanation was too long to write in this interview.

Server Side HTML (1)

delmoi (26744) | more than 14 years ago | (#1246088)

They were using serverside HTML on apache, as that the standard error message. I know that wasn't really the point of your post... but...

[ c h a d &nbsp o k e r e ] [dhs.org]

Re:Complexity the cause of poor education? (1)

deacent (32502) | more than 14 years ago | (#1246094)

Bjarne mentions the poor education of C++ programmers frequently in this interview. I can't help but think, is this poor education a direct result of the complexity of the language?

I think that there is a great deal of confusion caused by C++'s resemblance to C. There is a whole different way of thinking involved in using an object oriented paradigm versus a functional one. I've seen so many functionally thinking programmers learn C++ in an effort to broaden their horizons without really taking the time to understand the difference. This leads to situations such as not knowing how to use classes properly. There are some who seem to think that classes are just C++'s way of doing a struct, much less appreciate templates. They start to make assumptions about some of C++'s features by trying to equate them to C's features, such as using streams in place of printf. But then they fail to recognize the power of these features and try to use them just like they would in C. This creates all sorts of ugly code and usually leaves the programmer with a feeling that C++ is too complicated to be worth it.

think that it's a much shorter learning curve to learn the C language fairly well than C++. I think this has helped in the Gnome project, although I'm sure there are people who feel differently.

That said, many of the historical reasons for disliking C++ are becoming obsolete. In particular, the language seems to be settling down standards-wise, and there are now decent implementation to be had, both free and non. I've only used C++ sparingly in my own work so far, but I look forward to expanding my use of the language.

It has always been a matter of vendor implementation. The language itself started out reasonably strong and has grown stronger. The big stumbling blocks were vague areas of the language that vendors chose define (and sometimes rely on) and how efficient the compilers and linkers have been. Of course, the more experience a vendor has at creating programming utilites, the more efficient they tend to be as long as you don't try to keep cramming more crap into them (hello MS).

-Jennifer

Re:I hate Java [nope] (1)

Zurk (37028) | more than 14 years ago | (#1246097)

yep. i like to think of Java as C++ done right. The 1.1/1.2 java versions are perfectly useable and lead to decent code in a decent size. the speed will improve eventually..but it rocks as a language.

A mix is needed for a secessfull project. (1)

infodragon (38608) | more than 14 years ago | (#1246099)

I truely belive that a mix of programming languages and methodologies is needed. Deciding on the mix is dependant on the project/problem at hand.

Often the choice of the mix will determine the outcome of a project more than the actual implementation.

For instance you take a huge project (200,000+ lines of code, not white spaces or comments). You have 20 programmers working on this project. Are all of them going to have the same skill set? Some are going to have a better grasp of OOP and some better at structured programming. This is where a good manager comes into play. He should be able to recognise who has what skills and devide the team accordingly. During this process the manager needs to find the people with strong aptitude towads the metholodigies which are going to interact and put them in charge of the interface of thoes metholodigies.

After the team has been devided then the proper tools for a correct solution needs to be selected. The programmers selected to be in charge of the interfaces should be the ones to select the tools/languages based on the expertise in each of the teams.

With a good mix of the above situation any software project is destined to be a success. I have personally been involved with a project of the one described and the results were phenominal! We used assembler, c and c++ with carefully designed interfaces. Each team had somebody who was extremely adept in what his team was working on and what his team was going to be interfacing with. The team was made up of the people who's aptitude mostly fit with the particular team. There were varying degrees of aptitude in which the expirenced tackeled the more complex problems and the novice tackeled the simpler problems or assisted the more expirenced.

Sadly I've not found this situation outside the college environment. The above mentioned project was with an unmanned aerial-vehicle competition. Most of the students were there for the fun of it. The project was to designe an aerial-vehicle to map a simulateed a toxic wast field. Finding and diferentiating(SP) between barrels with either a raidoactive or biohazerdous symbol on them. There were quite a few disperate subsystems which exsisted. Mainly communications from the vehicle to the ground station. The vision system and the acompying software. The navigation system... In one year we built a system that took 3rd place in an internationl competition held at Eppcot Center Orlando Florida.

Of course this type of environment needs decient people who know where their programming aptitude stands and not take offence to working on a simpler problem.

Re:better than C is not good enough (1)

guerby (49204) | more than 14 years ago | (#1246101)

I wholeheartly agree with you, C++ is far from being the best solution when you realize there is something else than C and its pointers around.

However, no question on the potential flaws of C++ made it through moderation, so of course you can conclude it's the ultimate language ;-).

Re:GDB sucks..NOT! (1)

Monolith (80866) | more than 14 years ago | (#1246116)

GDB is the greatest. What should I use instead...
dbx...xdb...or some graphical thing. What debugger do you know that accepts things like
c 100 to skip this breakpoint the next 99 times. Great when doing things like looking for a certain record in a file.

Fragile Base Class (1)

epeus (84683) | more than 14 years ago | (#1246117)

I notice that Bjarne mentions this in passing, but doesn't elaborate. It is this issue that prevents a solid ABI based on C++ that sues calss inheritance.

Re:Thank You Moderators... (1)

Valur (87561) | more than 14 years ago | (#1246121)

I was a moderator Monday, and I thought the fake inverview was funny. ;)

Re:Java is covered in the FAQ (1)

gid-foo (89604) | more than 14 years ago | (#1246123)

Wow, he's even more of a man than I thought. That little section on Java in his FAQ rules. What a bad man. Damn, this whole /. interview thing kicks ass.

Bjarne (1)

bakreule (95098) | more than 14 years ago | (#1246129)

Some really, really interesting stuff. I'm going to forward this to everyone at work here.

My only negative question is did he have to plug his books so much?? It seems like he never passed up a chance to "refer to my 3rd edition of C++PL", etc..... I tend not to trust people who plug themselves and their products too much.

This, of course, is a minor concern. Thanks to /. for getting this great interview!

Re:if C++ isn't really OOPL, then why C++ at all? (1)

bakreule (95098) | more than 14 years ago | (#1246130)

Um, why do you think it's an abomination?? Don't just shot something down without giving a reason. What projects have you participated in using C++ that have failed so much or left such a sour taste? I'm assuming that you have used C++ for something and haven't just read the book and then burned it.

Re:I hate Java (1)

Succa (108618) | more than 14 years ago | (#1246139)

Well, all politics aside, I'm just saying that I like the language. I like how it's an object-based language. Everything is a descendent of the Object class. This makes me very happy. I like how the language is simple. No ambiguities about things like where to place "const", like in C. No preprocessor madness. I like not having to worry too much about memory management. I like the libraries that come with JDK 1.2. I like it all, man. I just wish it was a bit faster.

templates? (1)

shitface (121619) | more than 14 years ago | (#1246143)

I am currently a first-year comp-sci student who is learning/learned c++. The book(s) that I have used have in my opinion sucked and did not explain templates at all. Can anyone suggest a good c++ book? I understand that Bjarne's book, whatever the name is, is not a pure programming book- but would his book help me understand templates?

Cool!! (1)

jallen02 (124384) | more than 14 years ago | (#1246149)

Ive already taken a few deliberate moderation hits today to be goofy but this is awesome :-) I love when /. gets people like Bjarne to do interviews. Makes me feel all warm and fuzzy inside. This is content generation at its best! :-)

if C++ isn't really OOPL, then why C++ at all? (1)

porky_pig_jr (129948) | more than 14 years ago | (#1246153)

As far as OOP is concerned, that is a number of language far better than C++, by 'better' I mean more compact, consistent, and less confusing. Why bother with C++ then? I"ve been hearing 'because it inforces the programming's discipline whereas C doesn't. Give me a break. A lack of programming discipline is something you can't just inforce with a particular language, right to the contrary, a language such as C++ or Perl, both feature rich and both confusing as hell don't do anything toward better programming discipline. In short, C++ is abomination. A crime against nature.

Re:ObjC (1)

MacOSNeedsDeath (140242) | more than 14 years ago | (#1246159)

I've also used Objective-C, and must say that it produced some of the most unreadable code I've ever seen, in part because people didn't feel the need to write comments. The other part is that prototypes are optional and there is no access control. If you can name a function, you can call it. This does not encourage readable code. Objective-C also doesn't fix some of the same parts of C that C++ doesn't fix (declarator syntax and others). Java, on the other hand, puts the best parts of Objective-C into a reasonable syntax. It'll be interesting to see how efficient the GCC Java front-end ends up being.

Re:if C++ isn't really OOPL, then why C++ at all? (1)

Steve Burnap (155427) | more than 14 years ago | (#1246163)

Why? Because I can use C++ to write a purely OO language, a purely structured language, or anything in between. The language doesn't constrain me to use a certain paradigm.

Re:Bjarne (1)

Steve Burnap (155427) | more than 14 years ago | (#1246164)

I suspect that part of the reason is that a lot of the questions and criticisms, especially those that didn't make it into the interview, are answered at length in The Design and Evolution of C++

It can be annoying answering the same question over and over.

Re:Why unix developers still prefer c (1)

Steve Burnap (155427) | more than 14 years ago | (#1246165)

One thing that people seem not to really understand is that you don't have to use "all that complicated stuff" to get benefit out of C++. After all, here is "hello world" in C:

#include <stdio.h>

int main(void)
{
printf("Hello, World!\n");
}

Here is the same program written in C++:

#include <stdio.h>

int main(void)
{
printf("Hello, World!\n");
}

The key to understanding being that if your job is just to say "Hello, World", there is no point in using multiple inheritance.

Once you've done this, then you can pick and choose elements of c++ that are advantagous to you. To take a simple example, this C++ program:

#include <iostream>

int main(void)
{
char* Name="Steve";

cout << "Hi, " << Name << "!\n";
}

is much less error prone then this C program:

int main(void)
{
char* Name="Steve";
cout << "Hi, %d!\n", Name); // Crash, boom
}

Thus, you gain benefit without dealing with "all that complex stuff".

Re:ObjC (1)

OaITw (155633) | more than 14 years ago | (#1246166)

I would grant you that it is easy to write and read, but it suffers from bad association with the horrible compiler that apple puts out for NT. God am I glad I don't have to work with that everyday anymore. I never had a chance to try the compiler on the MACH system or on a MAC but I have been told by people who have that the IDE is weak compared to Visual Studio/Borland Builder type IDEs. Of course I do most of my programming on a SUN system without an IDE so that is not terrible critical. Now that I think about it, it was the IDE and WebObjects together that was buggy. Just random thoughts. Forgive.

char *'s, structs, and other C madness... (1)

jolly_cola (156667) | more than 14 years ago | (#1246168)

I don't think people use char *'s and structs and write
their own vectors because they are too lazy to use the
STL. It seems like so many compilers don't even come
with it!! We use Sun's C++ compiler and it comes
bundled with RogueWave instead, and frankly RogueWave
sucks, especially if you are trying to write code that
ports to win32. Frustration with mediocre libs is what
drives me to use my own low-level C constructs.

* Bjarne writes:
*
* The compatibility with C at the system interface level
* has encouraged people to use C-style strings, arrays,
* and structs, where they would have been better off
* with some higher-level abstractions presented as
* classes or templates. Instead of leaving the low-level
* facilities at the system level and within the
* implementations of classes, people have let the
* low-level constructs - and pointers to them -
* permeate their designs. Type errors, wild pointers,
* array bounds errors, and memory leaks are the obvious
* results. Lots of macros and casts often adds to the
* obscurity of the code. It saddens me to see some of
* the unnecessary messes people get themselves into.

Re:templates? (1)

scc (156697) | more than 14 years ago | (#1246169)

Essential C++ [amazon.com] by Stanley B. Lippman ...only 276 pages long. This book is an excellent place to start, and covers templates in chapter 6.

High Quality? (2)

Anonymous Coward | more than 14 years ago | (#1246176)

And the very first question of the lot:

1) Has OO run out of steam?
by rambone

After 20-some years, it's obvious that object-oriented
programming is not a panacea. What are your thoughts on the
future of the OO paradigm? What other paradigms do you see
challenging it?

I can just imagine Bjarne's eyes rolling back, and then him taking a deep breath when he read this question.

Thanks for wasting Bjarne's time with dribble.

One of the biggest problem with C++... (2)

rngadam (304) | more than 14 years ago | (#1246177)

One of the biggest problem with C++ is the lack of a featureful (freely available!) standard library to cover the range of things that Java covers (including the GUI).

Obviously, that sounds like "everything and the kitchen sink" but at least you don't have to search days and night to find poorly designed/implemented libraries... And it can always be made "standard but optional".

That is one of the reason why Qt is so popular: C++ is a great language when it has the appropriate libraries. But there is still some lacks as evidenced by the hack that Troll Tech has built.

This is why the next big thing in OO won't be C++ but a free, efficient Java native compiler.

Re:Thank You Moderators... (2)

Roblimo (357) | more than 14 years ago | (#1246178)

The fake interview *was* funny - but it wasn't a question...

- Robin

The importance of Multiple Inheritance (2)

Kaz Kylheku (1484) | more than 14 years ago | (#1246181)

I just want to say that I use MI much more often than single inheritance. I most often use inheritance to say that ``this object provides this protocol/interface/behavior'', and often have objects that provide more than one.

I've also done this kind of multiple inheritance in C. I believe it's the most useful form of inheritance, and also the least kludgy and most genuine and elegant form of OO.

Beyond being able to express interfaces, and dynamically bind interfaces to objects is the essence of object orientation. The ability to create a ``new kind of'' class with extra members, or overriden base members is just a handy kludge that sometimes saves work.

Without MI, I would find the usefulness of C++ to be vastly diminshed to the point where I might as well be programming in C.

Re:Systems level programming (2)

Otter (3800) | more than 14 years ago | (#1246187)

I believe the entire BeOS operating is written in C++, with an object oriented framework and a microkernel on which several "servers" handle system tasks.

On the contrary, despite Be's C++ orientation, the kernel is written in C. Someone posted some relevant links [slashdot.org] when this issue came up while questions were being asked.

Re:already OT, so... How do you pronounce "Bjarne" (2)

Ptolemarch (11506) | more than 14 years ago | (#1246193)

Read the FAQ [att.com] .

It's definitely a question of background (2)

JohnZed (20191) | more than 14 years ago | (#1246206)

I have to agree with what some of the other folks have been saying here. I first learned C++ (well, a shoddy mix of C and C++), and, especially as I've learned more about its features, I've found it painful to go back to purely-procedural languages. I've had to do tons of C in school, and it always leaves me wanting for the power of C++, Java, or even the convoluted object-extensions of Perl5.
Of course, now we have Brian Kernighan here as a guest lecturer and he's trying to convert everybody to use awk instead. . . (great guy, though)
--JRZ

Java is covered in the FAQ (2)

RPoet (20693) | more than 14 years ago | (#1246207)

Or maybe this is in the FAQ?

It is, right here [att.com] . You should read it, it's worthwhile. In particular I like the quote "Java isn't platform independent; it is a platform." :)

C++ > C + 2 (2)

exa (27197) | more than 14 years ago | (#1246216)

I haven't been writing any C programs (except mandatory ones) for the last 3.5 years, and I don't think that C surpasses C++ for any real purpose.

For programs of any size and of any choice I've found C++ to be the most expressive, flexible and efficient tool at my hand. For my stuff, "the worse is better" philosophy just doesn't work. Sorry Linus.

From compiler writing to graphics, from combinatorial optimization to multithreaded protocol implementations, C++ proved to be the right tool for me. It did, because it is not a couple of ad hoc extensions over the C language. It is a new language, and a way better one.

As far as I know, no other language comes close to the "multi-paradigm" features C++ offers, and with a most graceful treatment for efficiency.

My advise is simple. Learn C++ in the true sense. First work through the language features with the latest editions of the wonderful books such as D&E or C++ Primer, and then proceed to the standard library to see *how it should be done* and to grasp *how to use the std lib*. The new ISO standard defines a language of power for any field. Don't forget that people who claim to know the language are quite a lot compared to the people who have comprehended it.

Of C++ and Purple Dinosaurs? (2)

powerlord (28156) | more than 14 years ago | (#1246217)

First off the interview was great. I'll be the first one to admit that parts of it went over my head (too many I fear... time to brush off the dusty old text books and review) but I also had another problem, I couldn't stop chuckling.

Did anyone else keep picturing a large purple dinosaur as the 'mastermind' behind this new language designed, not to 'help everyone love each other' but to 'take over the world'. Yes... its Barney's evil twin (doesn't everyone have one?) Bjarne.

Thank You Moderators... (2)

GoofyBoy (44399) | more than 14 years ago | (#1246220)


...for picking good questions and moderating down that old joke/fake interview about C++/job security and any questions associated with it.

Moderation worked.

Re:What about Java? (2)

DaveHowe (51510) | more than 14 years ago | (#1246221)

I'm amazed that no question regarding his opinion on Java didn't make it through moderation.
I'm sure it scored highly - but when you are limited to ten, it's difficult to select such a small subset to give from such a wide pool of possible queries.
One point I did find interesting was the statement that he "peeked" at the raw questions on /. - and wondered if it would be possible to have a more interactive layout for this - maybe even convice some of our potential questionees to take part in the initial trawling and guide some of the comments with short replies. Does he feel Java is a competitor? or just another implementation to solve a different set of problems (e.g. web-programming)?
I am slowing learning this too <grin> but also see it as aimed at a different set of problems - one where compatibility and visual effect is more important than power and scope. I could be wrong of course :+)

Or maybe this is in the FAQ?
Not that I have ever seen.
--

Re:Poor coding (2)

DaveHowe (51510) | more than 14 years ago | (#1246222)

Elegantly said. C++ is a little tougher and takes a little effort to learn. The key word being effort. As a PHB I've found that developers who write marginal code in C did write poor code in C++, however I think this comes down to both a person who uses tools and resources targeted to meet a specific purpose and people who stay whith what is comfortable to them reguardless of the fact they may be using the wrong tool for the job.
Guilty as charged <grin>. I have largely ended up writing C code thinly disguised as C++ for years - not really due to comfort or singlemindedness though, but due to the fact I can write decent C, and if I had to suffer through my C++ puppyhood in a production environment, my job would be on the line. It took me four or five years to learn to write decent procedural-language paycode - and how many employers are willing to have an employee currently producing usable code effectively not there for that length of time?
--

Re:High Quality? (2)

DaveHowe (51510) | more than 14 years ago | (#1246223)

I can just imagine Bjarne's eyes rolling back, and then him taking a deep breath when he read this question.
I can see how the style it was written in (confrontational and almost a direct attack) could be a little daunting, but there *is* a important question in there, and I think he made a game attempt to answer it - what it comes down to is "How tied is C++ to the OO methodologies, can it evolve to whatever is or could replace it in the near future, and if it can, in what directions would you expect it to evolve?"
--

Name one that isn't! (2)

zorgon (66258) | more than 14 years ago | (#1246228)

Well, come on, PPJ, you have to tell us now. What are the languages that you refer to that are not abominations and crimes against nature? Restrict your answer to languages that are actually useful, and meet your criteria of OOPed, more compact, more consistent and less confusing, while encouraging better programming discipline. Otherwise your comment is just hot grits. I ask this question in genuine curiosity and without sarcasm.

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off."

Re:ObjC (2)

anatoli (74215) | more than 14 years ago | (#1246232)

As Bjarne once said, Smalltalk is the best Smalltalk around. And ObjC is just C that tries to be Smalltalk.
--

Re:Complexity the cause of poor education? (2)

fprintf (82740) | more than 14 years ago | (#1246234)

I think the difficulty in new users learning C++ is the inability to read Bjarne Stroustrup. Seriously, I have had his 3rd edition book for about 6 months now, and I have yet to be able to figure out the first couple of chapters. It has now become an issue of pride that every opportunity I get, I try and understand still yet another paragraph (good bathroom reading material). His writing style is definitely geared towards a technical, engineering personality.

I realize most of these questions were not directed at newbies, most of those questions were answered in the FAQ, but just reading Bjarne's thoughtful responses gave me flashbacks to the bathroom this morning. :-)

Re:ObjC (2)

Mr Neutron (93455) | more than 14 years ago | (#1246236)

Obj-C has advantages and disadvantages with reference to C++. I used a NeXTstation as my primary development platform 1992-1995 and became intimately familiar with Obj-C. Its elegance comes from the inclusion of only a minimal set of OO features - there's no multiple inheritance, no template classes, all object access is accomplished via reference variables (pointers), there's not even a public/protected/private distinction (everything is effectively protected). This greatly simplifies the resulting code. The object syntax, while elegant, is borrowed wholesale from Smalltalk and therefore looks somewhat strange when mixed in with C syntax. C++'s object syntax is definitely more consistent with its C origins. Also, Obj-C relies heavily on "run-time magic," which Bjarne specifically sought to avoid in C++. This dependence can increase the elegance of your source code at the expense of performance.

Part of what made Obj-C so pleasant to use on the NeXTstation was the rich object class library that NeXT developed. My big indictment of C++ is its lack of such a library; the STL is nice, but it's only a small part of what we need. I think C++'s wide installed base actually hinders such an effort to a great degree. Java's JFC/Swing libs are certainly rich but somewhat strangely organized.

Neutron

Re:As long as we're talking C++... (2)

benwb (96829) | more than 14 years ago | (#1246237)

Not meaing to go completely off topic, but I will anyway. This is one of the reasons that I think that there will always be a place for commercial software. There's lots of stuff that is just boring, complicated, and generally a pain to program- ie stuff that no one is going to do for fun, like getting gdb to wade through the STL symbols output by gcc and display them intelligently. Dollar signs have a way of overcoming these little shortcomings.

Poor coding (2)

348 (124012) | more than 14 years ago | (#1246238)

Naturally, you can write poor programs in any language. C++ is a powerful tool and in the wrong hands it can generate code that is *obviously* contorted and bloated. That may be preferable to the traditional spaghetti that poor programmers produce in C. Note that someone who is a good C programmer isn't automatically a good C++ programmer. Many problems have been caused by good C programmers assuming that they could adopt a semi-random collection of C++ language features and then magically become a good C++ programmer in a week.

Elegantly said. C++ is a little tougher and takes a little effort to learn. The key word being effort. As a PHB I've found that developers who write marginal code in C did write poor code in C++, however I think this comes down to both a person who uses tools and resources targeted to meet a specific purpose and people who stay whith what is comfortable to them reguardless of the fact they may be using the wrong tool for the job.

The interview questions were very good, Glad to see the good ones get bubbled up to the top. Also thanks to Bjarne Stroustrup for taking the time to answer them fully and completely, it's obvious that he spent some time with this.

Lack of ABI -> C++ != java (2)

mnf999 (137795) | more than 14 years ago | (#1246243)

Something strikes me when talking to the two communities. C++ guys will talk about features of the "language" and will wax poetic on STL. Java guys will consider STL as "just another library" and in java's case java.util.Collection.* but will talk about the API's, software design, extreme programming, and the high level libraries.

In my case EJBoss is based on many 3rd party libraries (BullSoft, IBM, SUN, W3C, Apache, Dreambean, Telkel). That REUSE is possible given that java comes with bytecode format and a DEFACTO ABI..

This to me is the main difference between the two class of people. One is "stuck" at the language layer, and the only interesting discussions will be on compilers ( i am not saying they are not deep just that they are stuck in a "low level" language world). The other one is REUSING libraries and discussing software functionality. The design of large sofware frameworks is based on this. OOP Reuse is REAL in java and seems non-existent in C++ due to the lack of ABI. Please turn off the light in the C++ camp, as this to me is the future of programming i.e. online component based development.

marc

Re:Complexity the cause of poor education? (2)

Steve Burnap (155427) | more than 14 years ago | (#1246244)

More likely the fact that C++ tends to be taught by lecturers more familiar with C. I suspect better training for lecturers would result in better training for students :+)

Odd, one of the problems I've seen is that lecturers concentrate on the C++ aspects of C++ too much and give the C aspects short-shrift. The biggest problem I see in day to day coding maintaining stuff written by people who are poor C++ coders is overuse and misuse of the advanced parts of C++. If I had a nickle every time multiple inheritance was used unneccesarily...

Re:Bjarne (2)

OaITw (155633) | more than 14 years ago | (#1246245)

I do not presume to know Bjarne's motivation but I do disagree with your judgement of people plugging their work. Have you noticed that people do the talk show circuit only when the have a project to sell. Do you distrust them for this. Talk show, book signings, taveling to a conference to give a talk, all the same thing. I found the way he pluged his papers and books very comforting. He's just a guy (bright and talented) that is working for a living and has produced some stuff that he is proud of and is rewarded for financialy. That makes him seem more real to me.

Maybe /.ers have an opinion then? (3)

Davorama (11731) | more than 14 years ago | (#1246246)

These other questions were so great I didn't make the cut but maybe you folks have opinions you'd like to share?

What do you think of template meta programming? Do you consider it a boon, enabling clever programmers to do outrageously cool things like the Blitz [oonumerics.org] project? Or is any benefit derived from it's use washed away by the obscure, nearly unreadable code it takes to implement it?

Why I use char *'s: No choice. (3)

Venomous Louse (12488) | more than 14 years ago | (#1246247)


In an ideal world, all the code one uses would use the same string class, and all the old C libraries one links with would be rewritten in C++ and available in source form so you could compile it yourself and not have to worry about name-mangling and whatnot. On earth, we're stuck with legacy code that uses its own string classes, MFC (pray for us poor sinners) which uses their own (broken) string class, and OS API's (and other C libraries) which use char * and various typedefs thereof. We should probably all be using std::string, but I've found it sort of perplexing the few times I've bothered with it. In any case, it came along so late in the game that other string classes had already proliferated and are now immortalized by bassackwards compatibility.

However, all of these string classes have some way to get at their char *'s, and they'll all construct from char *. So char * is a sort of lingua franca or least common denominator that lets us work with all this inconsistent crap and still get code written. It's a bummer, but it's better than nothing.

I think the first thing Stroustrup should've done by way of C++ libraries was write a good solid string class while CFront 0.1 was still wet from the womb, and proselytize it endlessly. Of course, if he had, ten years later we would've ended up with a standard string class inconsistent with the rest of the STL. Oh, well. You can't have everything.

What about Java? (3)

tdrury (49462) | more than 14 years ago | (#1246251)

I'm amazed that no question regarding his opinion on Java didn't make it through moderation.

Does he feel Java is a competitor? or just another implementation to solve a different set of problems (e.g. web-programming)?

Or maybe this is in the FAQ?

-tim

Re:humility deficient (3)

DaveHowe (51510) | more than 14 years ago | (#1246252)

Wow! Can he do no wrong? I guess there's just nothing wrong with C++ at all. There's nothing that could have been better implemented.
I think this is far from a problem - what he is saying is that anything he saw as being wrong he has fixed or is fixing - If someone builds a tool, and it is perfectly suited to his hands and his reach, then you also use that tool, and find it less well suited, it just means you are different to him - not that either of you are "wrong" in some abstract sense.....
--

Re:humility deficient (3)

LordEq (63011) | more than 14 years ago | (#1246253)

> I was looking for some reference to "I wish I
> had done that better" or something.

"I think my most obvious mistake was not to introduce templates before multiple inheritance and not to ship a larger library with Release 1 of my C++ compiler."

"I, and the standards committee, underestimated the importance of templated typedefs. My guess is that they will be added in the future."

"I guess that in this case, my reluctance to add new features without a clear practical need caused problems."

"I underestimated the linker problems. I may also have underestimated the problems stemming from C compatibility."

There you go.

--LordEq

ObjC (4)

Julian Morrison (5575) | more than 14 years ago | (#1246255)

From my way of seeing it, ObjC is way more similar to smalltalk or perl than it is to C++. So much is resolved at run time - and quite a lot is also left to programmer discipline. Coupled with the Foundation library, it can do neat tricks like opt-in reference counting, simple clean distributed-objects without ugly hacks like CORBA, and building "selectors" (function identifiers) at runtime and calling them on arbitrary objects. Plus, it's proof against "fragile base class" except with instance variables.

ObjC's attitude reminds me of perl: "You wanna do something wierd? Your program, your problem; don't let me stop you."

I'd pick ObjC over C++ any day for everything except kernel bit-twiddling or projects needing huge-scale multiparty co-ordination, but if I had my way I'd add in proper exceptions and some java-like threadsafety primitives.

Systems level programming (4)

grappler (14976) | more than 14 years ago | (#1246256)

I believe the entire BeOS operating is written in C++, with an object oriented framework and a microkernel on which several "servers" handle system tasks. It is by no means slow or bloated. Of course, for R5 they are scrapping the Net server in favor of one more closely tied to the kernel to improve performance, and I think they're doing something similiar with 3d acceleration.

Anyway, the point is, they use C++ for system level stuff and it works great. Of course, the Be people are by no means "old dogs". There is nothing legacy about BeOS.

--
grappler

how well do various compilers track the standard? (4)

sethg (15187) | more than 14 years ago | (#1246257)

A common theme in the answers seems to be "that complaint is based on outdated information; get a new compiler that follows the standard and use the STL."

For the benefit of us C++ newbies, does anyone maintain a chart showing which currently-available "C++" compilers violate which sections of the C++ standard?
--
"But, Mulder, the new millennium doesn't begin until January 2001."

Re:humility deficient (4)

jilles (20976) | more than 14 years ago | (#1246258)

If you look back in this interview, you'll notice that bjarne has very clear ideas about how multiple inheritance should be used. If you compare that to what Java supports you'll find that it actually supports this type of usage (namely multiple inheritance of interfaces). The problem with C++ is that it has no first class representation of interfaces (which is why you need multiple inheritance of classes to imitate this feature). Java has support for interfaces built into the language so it can prevent people like you shooting theirselves and the companies they work for in the foot by abusing MI. If you are still sceptical about this, I would like to point out that there have been empirical studies about the use of multiple inheritance and these studies make it pretty clear that the use of MI for inheriting code is a bad idea in most cases.

I don't really see the point of having operator overloading. The advantage of being able to overload them is fully consumed by the resulting confusing code. I don't want my + operator to be overloaded. I don't want to work on code where I have to look up what the + operator actually means. If assumptions I have about such simple things as + and - no longer hold true I can't do my work properly.

My main problem with C++ is not that it lacks features but that provides to much of them. Java as a language is much simpler and the only problem I see with it is that it doesn't have support for templates yet. On the other hand there are many features in it that you only get in c++ if you are a skilled and disciplined programmer. Take for instance a simple concept: package. The package construct allows you to group classes into packages. Packages can be nested and the package is part of the class name (which makes it possible to have class names with the same name in different packages). Of course this simple feature can (and should) be imitated for large C++ projects but its just not as straight forward as in Java. Another feature is that Java assumes that your functions are virtual rather than static (as in C++). C++ obviously can't do this without breaking compatibility with C so OO programmers are doomed to type virtual in front of every method they declare.
Another thing is the C compatibility. I don't see the point of it. True, in isolated situations it may be handy to be able to quickly port old C code (but then why not redesign it while you are at it?). In most situations though you are better of resuing the old code base in the form of libraries (as you do in Java with native methods).

These little, well designed language features make life easy for a programmer. And that's exactly what a language should do. C++ programmers always complain about lack of features in Java but this is in sharp contradiction with actual productivity of programmers using C++ and Java.

Also the fact that C++ is so close to C prevents it from doing certain optimizations (according to Bjarne in this interview). I'm not in favor of a one size fits all language. Especially if that means making compromises all over the place. C++ is one big compromise towards C compatibility and performance. In many projects C compatibility is not essential or even redundant and performance is not the primary quality requirement. C++ therefore is not the most suitable language for this growing category of projects.

In many cases using C++ makes your programs needlessly complex and confuses the programmers. True, if you no what you are doing it can be a handy tool but unfortunately many programmers are not in that position.

In the interview I noticed some frustration with the fact that there are still hordes of programmers using C (for non valid reasons). I feel a similar frustration towards the use of C++ and Java. True there have been and there are performance problems with Java. But just like most of these issues resolved with C++, most current issues with java will be resolved over time.

Re:I hate Java (4)

SheldonYoung (25077) | more than 14 years ago | (#1246259)

There are some decent arguments in there. However, you're arguing the wrong points. That language wasn't design to be either fast or feature-rich.

Speed of execution isn't always important. There is such a thing as "fast enough". Often the speed at which a developer can write an application is more important than the speed at which it runs.

Feature-rich is another pitfall. Yes, generic programming, multiple inheritence and operator overloading are things that can be beneficial sometimes. But it also means it is harder to understand what is really going on. Is [] just an array or is an overloaded operator that makes some non-obvious assumptions? With MI if I hadd something to one of the base class, what happens - especially if there are conflicting names?

Consider this: It is almost difficult to make a Java program that is difficult to understand, unless the design is really, really bad.

One of Bjarne's articles on the Web... (4)

mav[LAG] (31387) | more than 14 years ago | (#1246260)

...came up at me like this:

Why no single programming language can solve every need. By Bjarne Stroustrup
The Red Herring magazine
From the April 1999 issue
Why would investors or executives care what programming languages their companies use? After all, customers don't care, and shouldn't. When I dial an 800 number, I don't stop to consider which language was used to write the program that translates it into the number of a phone on someone's desk. But software is crucial to the products and services we deliver -- and the programming languages we use to write that software can make the difference between success and failure.

[an error occurred while processing this directive] LANGUAGE ARTS
A good programming language allows programmers to express the ideas of an application simply, directly, and affordably. It gives programmers who want to improve on a program a decent chance of grasping the structure of the system. This is critical for a software development organization's effectiveness: a programming language that makes the structure explicit helps engineers and makes it easier for software tools to analyze and display programs.

I'm not sure that the programming language used to write the software that generated this page has made that difference between success and failure :)

Moderate this up, please! (4)

adubey (82183) | more than 14 years ago | (#1246261)

(Refering to the post I'm replying to).

In my experience, much of the unavoidable complexity of C++ comes from the fact that you can use either pointers or references to refer to objects.

Note the distinction between "unavoidable" complexity and the avoidable complexity of templates and multiple inheritance - often you can't get around this.

References are nice because the "->" operator is brain-dead: why should the programmer keep track if something is a pointer or not when a type-safe compiler can figure out if "." or "->" is suitable.

But references, unforutnately, can't be used everywhere. The lack of an ABI might be one reason. The fact that Linux/Unix only has 'C' style interface is another, related reason. (NB: Windows _does_ have MFC to abstract OS functionality, if you want it. From what I hear, it doesn't abstract that functionality very well, though...).

But you sometimes have to mix pointers and references for the simple reason that you can't re-assign references. In code, this might be no problem, but what about classes?

Another unavoidable complexity deals with the language's decision not to have proper "interface"/"implmentation" files. On one simplistic level, it means I have to unnecessarily type in:

#ifndef __MY_HEADER_H__
#define __MY_HEADER_H__

...

#endif

But there are other annoyances. For example, you can't statically initialize static member variables! To be honest, you can, but not the way that a programmer would naively expect:

class {
static int foo = {1,2,3,4};
};

just doesn't work.

Things like this are the gravest error a language designer can make: if the language doesn't work in the way a naive programmer would expect, you *need* to become experienced and learn the special cases.

Re: bloatedness. Stroustrup makes the assertion that if you use C++ right, you won't have bloated code. With G++ at least, it is difficult to use STL in *any* way without bloating your code. Perhaps this is a shortcoming of g++ rather than C++. However, I think that the design of C++ makes it difficult for compiler writers to make efficient STL code.

In some sense, I feel like C++ is like Windows: people use it because they have to, not because they want to. And "have to" doesn't mean it's imposed, sometimes it just means that tools have been developed for it that are unavailable elsewhere. In many languages, I simply can't use yacc, makedepend, the Unix API, etc, etc.

Re:Poor coding (4)

348 (124012) | more than 14 years ago | (#1246262)

Honestly, not many. What we learned (the hard way) was that C developers that were good, were also good in adapting/learning/etc. C++. On the other hand, we did get out of the training business by trying to port C developers to C++. The expectations I had were quite misguided. I understood C++ to be just the next version of C, for the longest time I just never got it that C++ was different. When we did, we looked for C++ developers and stopped the pain, and increased the quality of our code overall.

I hate Java (5)

joss (1346) | more than 14 years ago | (#1246263)

Each to his own.

This is a list of reasons why I personally hate Java. They're not all rational, but hatred seldom is...
Three points I would like to make up front.
1. I *know* Java is the best choice for certain things.
2. Please don't bother telling me all the drawbacks of C++ in reply.
Believe me, I am aware of many glaring flaws with C++,
it's just that I've learned to live with these flaws. If I had
learned java before C++ I'm sure I would find those flaws less
tolerable.
3. I'm not a Java newbie. I learned it 5 years ago, and I used it
nearly full time commercially for the last 2 years, (recently returned
to C++ with a huge sigh of relief)

Firstly, the IRRATIONAL REASONS (that I'm aware of):

It took me years to learn all the pitfalls in C++, and then some
bastard comes out with a lanaguage in which many of those pitfalls are
removed. This makes that time more likely to have been wasted and
makes my skills less valuable. Don't bother telling me that this
mentality is selfish, stupid and short-sited, I'm well aware of this.
------------------------------------------------ ------------------

I've gotten burnt too many times with Java to trust anything I'm told
without trying it myself (eg - bug fixed, performance improved,
memory leaks). I started learning about Java as soon as it came out,
before books were available etc. I was terribly excited by the chance
of something to break MS hedgemony, so I was initially enthusiastic.
That enthusiasm has worn off, and then some, which is why
I now sound so bitter about the whole thing.

Java 1.0 was God awful, and the time spent learning how to overcome
it's shortcomings was a total waste of time. Other equally important
libraries have changed so much to require any old (2years+) java code
to need total rewriting. Yeah, yeah, I know, what do you expect with
bleeding edge technology, but it was managed badly, and Sun flat
lied about these issues from the beginning.

------------------------------------------------ ------------------
I don't like the default style of the code:

public ZipEntry getNextEntry() throws IOException {
if (entry != null) {
closeEntry();
}
... }

I prefer matched brackets, (the extra lines are worth the additional
clarity methinks) and I prefer this_style to thisStyle as a purely
arbitrary preference.

public ZipEntry get_next_entry() throws IOException
{
if (entry != null)
{
close_entry();
}
...
}

------------------------------------------------ ------------------
Sun's behaviour with Java

has been pretty disgusting at times. For instance they delayed
providing a Linux version of the JDK for as long as possible. They
spread vast amounts of disinformation and pro Java FUD. They made
thousands of misleading statements wrt performance and stability and
seem to have effectively brainwashed a whole generation of students as
to the benefits of Java compared to other languages. The number
of clueless little student wankers I've heard regurgitating Sun's
propoganda...

For some reason people give more credence to what Sun says about
Java compared to other langauges than they give to what Microsoft
says about Windows compared to other OS'es, but the same level
of objectivity and accuracy has been used.

Sun has done plenty of other boneheaded things with Java, but the
misinformation thing is the one that irritates me most.

The other obvious mistake is that Sun never tried to use
Java to obtain a level playing field. It wanted to keep control
and replace MS. If they had completely opened up Java initially then it
would be a different story by now.

Java isn't a bad language, but it's not "all that" either. IMO ML and
Eiffel are preferable aesthetically while C/C++ is preferable for
practical engineering today. I think Java is an excellent training
langauge, an OO equivalent of Pascal.

------------------------------------------------ ------------------
Exceptions

I can understand the motivation for declaring the exceptions thrown
in method declarations, but I'm not convinced it's a good idea.
The whole point of exceptions is to localize the pain of
dealing with weird occurences rather than pass the pain up the
call stack in the form of checking return values everywhere.

With java, you constantly have to work your way up the call stack
adding extra exception declarations to methods. It's very
tempting to either not bother throwing the exception or just
trap it inappropriately rather than editing half a dozen
files up the call stack. It's almost as much work as the old C paradigm of
checking return values everywhere.

This argument is kinda weak, I know you don't need to declare Error
exceptions in method declarations, and in some ways it's a good
thing that it makes you think about the fact that an exception
could be thrown, I guess it depends on what you're used to.
------------------------------------------------ ------------------
------------------------------------------------ ------------------
RATIONAL REASONS for disliking Java.
(I mean reasons that I don't already know are irrational)
------------------------------------------------ ------------------
Java is slow.

I don't care how many benchmarks Sun comes out with
claiming the latest JIT has "C++ level performance". It's just not
fucking true. While we're on that subject, these benchmarks always
show considerable difference between C++ and C level performance. You
only see a significant difference in performance between C and C++ for
a given task if either (a) the C++ programmer didn't care about
performance or (b) the C++ programmer was stupid, in which case all
bets are off. You can write hand crafted assembly that's slower than
Java if you're stupid enough.

A uncontrived comparison is at http://sprout.stanford.edu/uli/java_cpp.html
In summary, with HotSpot 1.3 beta, (a JIT that Sun touted as being
faster than C++ !!) Java was roughly 5 times slower than C++.

The performance hit from Java comes more from it's crappy libraries
(Swing anybody) than the JIT aspects. Bounds checking, garbage
collection, and inherent overhead of OO techniques all cause a
performance hit, but the real trouble comes from crappy libraries
that put 10 levels of indirection between a request and it's
implementation.

For instance the String class being written with 16 bit characters to
make it unicode friendly when 98% of the java code written never uses
this feature but it still requires twice the time and space for every
operation. Also Strings are not alterable so to alter a character you
create a new StringBuffer object, copy everything, make an adjustment,
then replace the old reference with the new so the old object
eventually gets passed to garbage collection... all compared to
buf[i]= 'a'; (C or C++). It's crap like this that really makes Java seem
so slow, not the JIT hit.

Basically Java is slow for the same reason that Windows sys admin is
slower than Linux sys admin. You don't trust the user with the rm
command or trust the programmer with pointers - show him an idiot box
if he tries to delete a file or bounds check that array access for
him. It's one way of doing things, but it sure isn't efficient.

------------------------------------------------ ------------------
Missing language features (compared to C++)

* templates
No, just because everything is derived from Object, does
not mean you don't need them. Writing container classes for Object is
equivalent to writing container classes for void * in C++. You can do
it, but it's not ideal. Besides templates are useful for more than
just container classes. See http://oonumerics.org/blitz/ for an
advanced example.

* enum
Java is meant to have stricter type checking than C++. It seems like
the kinds of mistakes an experienced engineer
hardly ever makes are guarded against, but the kinds of mistakes
that people are likely to make are more likely in Java because of
the lack of enums or templates. The only reason for their absence
is the added complication - that only makes sense in a training language.

* multiple inheritance
Interfaces are pretty good, but MI is more powerful and abstract virtual
inheritance if equivalent to interface, so interfaces are subset of MI.

* preprocessor
"not needed because Java is platform independent" -
hahaha. No it fucking isn't, but a more common need for the
preprocessor would be to ease the pain of version changes. You either
end up with duplicated code bases or you hack your own preprocessor on
to javac, or you deal with a minor headache for every minor version
change or a huge headache for major version changes (1.1 -> 1.2 or 2.0
as it's now called).

* operator overloading
String str = (String)vec.elementAt(i);
versus
string str = vec[i];

It's even more striking if you're working with matrices and vectors
etc, but I've thankfully managed to avoid the pain of doing that in
java.

Now we get into the "these language features can be abused" argument.
It's easy to show examples of the dangers of misusing MI or operators.
I think this is pure packer mentality. You cannot make programming
idiot proof and it's a mistake to try. This mentality pervades java
and is probably the single thing that really makes me hate it. The
notion that you prevent everyone from doing something because
"some people abuse it" drives me crazy.
------------------------------------------------ ------------------
Verbosity

Java code just tends to be longer than the equivalent in C, C++, perl
or ML (unless of course you're implementing something that is nicely
covered in the libaries)

There are several reasons for this.

Insistence on using OO paradigm all the time.
Missing language features (especially operator overloading)
choice: boolean Concept.Conventions.StyleGuide.LongFunctionNamesDe sirable() { returns true; }

This relates to something I've never fully understood. Several people
who's opinion I respect insist that they can develop stuff faster
with Java than with C++. If they really know C++ I just
don't understand this, unless they are comparing old
(pre-STL) C++ with modern (post-collections)java.
The other possibility is that they have been using MFC, a
piece of code so vile, that I can barely speak it's name.

I can see that if you're working on a project where (2 or more apply):
threads are important;
has to work on multiple platforms;
requires functionality that JDK library classes cover well;
is deployed over the internet;
speed is not an issue;
memory useage is not an issue;
very precise control is not important;
some team members are inexperienced;

then Java may well be the best choice.

However for implementing arbitrary fresh functionality I can develop
far faster in C++ than java. For instance a fragment of a C++ program
that reads in a file and gets a list of the starting positions for
every word in the file:

map > word_positions;
string word;
while (cin)
{
cin >> word;
word_positions[word].push_back((int)cin.tellg() - word.size());
}

Writing the equivalent in Java would take 20+ lines.

Now, I admit this is a contrived example, but do it the other
way round - give me a nice piece of algorithmic code in Java,
that is not dependent on some database/graphics/network library
and I believe the equivalent C++ will almost always be smaller.

------------------------------------------------ ------------------

Libraries

I don't like the JDK libraries much. This is mostly a maturity
issue, but also it's a kind of OO at all costs mentality.
For instance using NumberFormat & PrintWriter to create
precisely formatted scientific output is immensly painful
compared to using printf() (iostream's suck for this too).

"simple stuff should be easy and difficult stuff should be possible"
Java libraries lose points on the first half, but are generally OK
on second.

Using stuff like Dictionary is unpleasant compared to STL
- there's no way to avoid this due to the lack of templates
(BTW I am aware of Pizza, and this is definitely a step in
the right direction, but unless Sun adopts Pizza it's
not really worth bothering with).

I started on my last project before I knew about FLTK, and
portability was an issue which was why I chose Java for the
interface part of the project. Swing has quite a good design,
but a shitty implementation. It's buggy as fuck, and seriously
inefficient. Learning how to work around it's shortcomings is a
right royal pain in the ass. It has gradually improved, but
is still slow, leaky, bloated, buggy, and perverse in places.
Stick a breakpoint in at any point in the code - the callstack
will be at least 15 levels deep. It's still preferable to MFC
though, which has shitty implementation coupled with *appalling*
design.

Swing is wonderful compared to AWT, but I wish they
had worked harder on stability and performance and less
on features. Visual Basic based applications feel much
faster than Swing even with the latest JIT.

------------------------------------------------ ------------------
Printing
Why did they hardcode the output to 72dpi ???
It's just typical Java. You get the performance of 5 years
ago on the latest hardware. Not a good use of Moore's law IMO.
(There is a workaround to this using drawImage() but that has serious
problems too...)
------------------------------------------------ ------------------
Tools

javac versus egcs/make,
gdb v jdb,
VisualC++ v. Jbuilder3
DDD v ...er... DDD
purify v JProbe
quantify v JProbe

The C++ tools just have a greater polish.

This is an unfair comparison, since it's not really Java's fault
and is just a matter of time.
(Actually, the problems with JBuilder3 *are* java's fault.
JBuilder3 is mostly written in Java and it shows. It's virtually unusable
with less than 128Meg of RAM, 256M is recommended.)

------------------------------------------------ ------------------

And that's enough ranting for today...

Complexity the cause of poor education? (5)

raph (3148) | more than 14 years ago | (#1246264)

Bjarne mentions the poor education of C++ programmers frequently in this interview. I can't help but think, is this poor education a direct result of the complexity of the language?

I think that it's a much shorter learning curve to learn the C language fairly well than C++. I think this has helped in the Gnome project, although I'm sure there are people who feel differently.

That said, many of the historical reasons for disliking C++ are becoming obsolete. In particular, the language seems to be settling down standards-wise, and there are now decent implementation to be had, both free and non. I've only used C++ sparingly in my own work so far, but I look forward to expanding my use of the language.

better than C is not good enough (5)

hanwen (8589) | more than 14 years ago | (#1246265)

Thanks for answering my question.

Now that I am reading your replies (and of course after reading your
FAQ as well), I've started to notice that your replies center on the fact that

C++ is better than C


Or maybe even the less subjective


Complicated programs in look better in C++ than in C


This is patently true, of course. C++ has support for various nifty
features that make a large C project more easy to manage. In fact it
describes precisely what I felt when I traded C++ for C: no more
hassling with function pointer tables was needed. I could simply use
a virtual function, great!

My problem is "better than C" is no longer good enough for me.

I've grown a lot in my programming skills, and my projects have grown
with me. A little detour: my pet project is GNU LilyPond, a music
typesetter (free software of course) written and maintained largely by
myself: it consists of about 55000 lines of C++.

The problem with this application is that

1. music typesetting is _very_ complicated

2. every formatting detail should be tweakable.

Since I've started it almost 4 years ago, I've learned a lot, and also
came in touch with languages like Python, Haskell and LISP. Half a
year ago we made the step of converting large portions of the C++ side
to GUILE (the embedded Scheme interpreter of the GNU project).

This step has dramatically simplified most of the code in LilyPond:
now we have garbage collection, generic types without the overhead
templates!, a clean way for users to plug into this system using
Scheme, etc. (if you want details of what kind of uglyness went away,
tell me, I can explain). This revelation caused to me reconsider C++
as the ultimate language.

In python, I can simply write

for x in func1, func2:
[some complicated code with x]

in C++, I'd have to go through the hassle of defining the correct
function signature as a typedef, then build an array, and then loop
through that array using an integer, eg.

typedef void (*fptr)();
..
fptr[2] = {&func1,&func2}
for (int i=0; i

And usually, I don't go through the hassle , and just copy and paste
[something complicated], which is also a Bad Thing. Maybe this is a
slightly contrived example (I'm not sure about the typedef), but
learning Python and LISP has made writing C++ a generally painful
experience for me.

Maybe nowadays some of my gripes may be soothed by the Standard
Libraries, but I don't feel like learning yet another big C++
component, all the more because I know that afterwards C++ will still
not be good enough (or will it ever have reflection, higher order
functions, GC?)

In this light, I find your statement that

starting to learn C++ is easier than starting to learn C

dangerous, as are the examples in your "learning C++ as a new language
paper" for they imply that any of these two languages can or should be
a "first" language.

Do you really want people grow up with a language that has distinction
between non-immediate objects on the heap and stack, no automatic garbage
collection, pointers, no initialization, no higher-order anything?

You're educating people about C++: fighting misconception, telling
them where it is good for. But you're not telling them what it is bad
for. C++ is immensely popular, and people easily get the misconception
that this popularity makes it a good language start programming with,
or to write their highly tweakable programs, etc.

Re:Systems level programming (5)

brad.hill (21936) | more than 14 years ago | (#1246266)

Of course, the Be people are by no means "old dogs". There is nothing legacy about BeOS.

On the other hand, IBM (the oldest dog in the book, but with more new tricks than anybody) entirely rewrote AS/400 in C++. They claim it was the largest OO project ever undertaken and was a spectacular success. Also, it seems that having an OO architecure at the core of the OS allosed them recently to integrate a JVM into the AS/400 kernel that's amazingly fast and scalable.

I actually find it strange that C++ is thought of as unsuitable for systems programming. To me it seems exactly suited for that, while Eiffel or Java are much more suited to business programming.

Perhaps the argument is more fundamentally that OOP is unsuitable for systems level development, which the above example blows to bits, of course.

Re:Complexity the cause of poor education? (5)

DaveHowe (51510) | more than 14 years ago | (#1246267)

Bjarne mentions the poor education of C++ programmers frequently in this interview. I can't help but think, is this poor education a direct result of the complexity of the language?
More likely the fact that C++ tends to be taught by lecturers more familiar with C. I suspect better training for lecturers would result in better training for students :+)

I think that it's a much shorter learning curve to learn the C language fairly well than C++. I think this has helped in the Gnome project, although I'm sure there are people who feel differently.
I suspect a lot depends on what you have learned before it - I found C easy to learn having already studied Basic, Cobol and Pascal - all procedural languages. Had I went from a base of OO language to C++, I would probably have regarded the C subset as a primitive reminant suitable only for things not worth wasting the full glory of objects on.....

That said, many of the historical reasons for disliking C++ are becoming obsolete. In particular, the language seems to be settling down standards-wise, and there are now decent implementations to be had, both free and non. I've only used C++ sparingly in my own work so far, but I look forward to expanding my use of the language.
I am being dragged kicking and screaming into C++ :+)
well, I might not be THAT badly off, but the Microsoft Visual C++ compilers seem to go out of their way to make using classic C awkward, so I am having to adopt C++ in self defence.
--

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>