Slashdot Mirror
Ask Bjarne Stroustrup, Inventor of C++
You can learn more about Bjarne Stroutrup here. Even though Bjarne isn't on your nightly news a lot (like never) he deserves (and gets) heavy respect from fellow programmers. If you have a question for Bjarne that he hasn't already answered on his FAQ page, please post it below. If you're a moderator, please moderate others' questions up or down, as deserved, which is just as important as actually asking questions. Tuesday afternoon (U.S. EST) we'll forward 10 selected questions to Bjarne. His answers are scheduled to appear Friday.
Now that the Java hype has cooled off, what is your assessment of its future?
Will/should name mangling be standardized so different implementations can coexist ?
1 reply beneath your current threshold.
After twenty some years, its 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?
C has long been the UNIX-world's systems programming language, and still remains that way. I know you don't like to compare C++ to other languages, so I'll just ask if you feel that there are any core reasons why C++ either does not make a good systems prgramming language or failed to capture the interest of the systems C programmers.
If you could go back to when you designed C++, what would you change and why?
Ibag
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< class T >
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?
"Christianity neither is, nor ever was a part of the common law." --
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?
43rd Law of Computing: Anything that can go wr
Three linked questionsquestions
1) Do you think that multiple inheritance is a requirement for a true OO Language
2) When designing a system with multiple inheritance what do you see as the pitfalls to avoid, especially when it comes to maintainability.
2) Do you know of anyway to simplifying the readability of multiple inheritance to enable first time users to do less damange.
An Eye for an Eye will make the whole world blind - Gandhi
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?
Sanity is a sandbox. I prefer the swings.
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?
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
The biggest complaint I hear about C++ (and agree with myself, depending on whose code I'm reading), is that it gives you enough rope to hang yourself, your company, and your close family.
Unfortunately, while it's easy to give a language new features without harming backwards compatibility, it's a lot harder to take things out. Are there any features that, in hindsight, you wouldn't have put into C++ to begin with? Are there particular features (templates keep coming to mind) that you would advise inexperienced programmers to avoid?
Another question, how do you see funtional programming playing a role in the future? Do you think functional programming is an acadmeic fad or a niche market for special purposes like Ada is used for?
This is my signature. There are many signatures like it but this one is mine..
Also, as a Windows programmer, I spend much of my time grappling with imperfect implementations and proprietary versions of classes. As an example, most Windows programs seem to use the Microsoft specific CString rather than the standard std::string operator for strings. This can cause problems because of the poor way Microsoft has implemented their versions of some of these classes. Is this a problem that will continue to plague us, or do you see all vendors moving towards better support for the standards instead of proprietary APIs?
The cake is a pie
I already see a lot of questions being asked that are already on the FAQ list, so here's a handy list, with links:
--
What are your thoughts on languages and the standardization process? Looking at how long it took for C (and C++) to have standards set by ANSI/ISO, and how the most popular implementations are still so very incomplete (MSVC++, even GCC in some ways), one might ask, "Why bother?" Sun might be thinking something similar with Java.
Is it worth the time and the trouble to be able to create and to point at a sort of Platonic ideal while the rest of the world is chasing a poorly realized reflection of that ideal? What are the benefits of handing over the design of a language to the standards organizations instead of pushing forward with the design yourself (see Python, or Perl, or PHP for successes of the latter)?
--
how to invest, a novice's guide
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?
Han-Wen Nienhuys -- LilyPond
I realize that you like to avoid comparing C++ to other languages. However, how do you feel about the Eiffel language, and more specifically, what is your reaction to the negativity the Eiffel community seems to show towards C++? Have you ever met any of the founding fathers of other languages, such as Bertrand Meyer of Eiffel or the Sun Java people? If so, was it a positive experience?
--- "So THAT's what an invisible barrier looks like!" - Time Bandits
Okay, in a battle to the death between Linus Torvalds and Bjarne Stroustrup, who would win?
For example, the GNU C Compiler's FAQ includes an entry detailing the available workarounds. Other compilers are similar (in fact, the GCC FAQ entry makes reference to other implementations).
A number of development shops I've worked in have avoided templates precisely because of these problems, despite their benefits. Code reusability suffers as a result.
Presumably you didn't have this sorry state of affairs in mind when you were working on the specification. What did you imagine people would do? Abandon object files in favor of some other incremental-compilation scheme? (If so, what?) Are there any compilers that get this "right" in your estimation? In retrospect, would you have done anything differently to encourage compiler vendors to do the "right thing"?
.. and would ignore backwards compatibility with C, would the resulting language resemble C++? It seems to me (I mainly do Java) that a lot of language features in C++ are less then optimal and heavily biased to performance rather than usability. Templates come to mind but also such things as macros (eeeww).
I hope you won't put this question aside like you do with most question asking you to compare C++ with <fill in your language here>. While I imagine that the latter type of question must have become a boring one for you, the fact remains that C++ is now more than 20 years old and other languages might exist that address some domains at which C++ was once targeted, better. So rather than asking you to do that I would like you to describe what a modern language should be able to do compared to C++.
Jilles
During the design phase, it's difficult to forsee all the issues that will occur in the final implementations (and when the language is put to use).
What were the biggest misfeatures of C++ (things which added little useful functionality but which make compiler implementation/use/efficiency more nightmarish?)
On the other hand, what restrictions or concessions turned out to have surprising wins in the same categories?
I've been playing around with OpenC++, C++ with a metaobject protocol and I find opening up the compiler in controlled ways like this to be very powerful - and more than just an academic toy. It would allow me to extend C++ in interesting ways to include Delegation (useful for the "Decorator" pattern) and multi-dispatch (useful for the "Visitor" pattern) - along with other interesting extensions (before/after methods, persistance, etc.). I know you considered and rejected both of these features in C++ (if I remember from "Design and Evolution of C++" you rejected Delegation because users found it confusing and you rejected multi-dispatch because it required too complex a linker[1]). I am not questioning your rejection of these features, but I would be interested in your option of a metaobject protocol for C++, which would allow me to add features like these to C++ so it is a closer to my designs. Did you consider a metaobject protocol for C++, and if you did why did you rejected it (too immature? too hard to maintain code? not useful enough to justify the complexity to the language?)
-Scott
nonya_cpp_question@yahoo.com
[1] I should mention my version of Multi-Dispatch doesn't solve the linker problem, it requires you call a function at the start of a program to initialize some tables of pointers to member functions.
Why was the decision made not have have references visible as parameters in the calling context of a function call?
What is your opinion on this fake interview?
Use Adsense for Charity
You said, in "The Design and Evolution of C++" (p. 207), "Within C++, there is a much smaller and cleaner language struggling to get out."
Do you still beleive this? If so, is it likely that such a language shall be created within the forseeable future?
Steven E. Ehrbar
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?
Davo -- Free speech, free software, AND free beer.
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 inheritence 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 severaly 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?
Beyond this issue, what are your personal priorities and hopes for the C++ language now?
Bjarne:
First, let me take this opportunity to thank you for offering the Slashdot community this chance to interview you. It is highly appreciated!
As I'm sure you're well aware, computer security has risen to the forefront of risks involved with online business(even beyond "nonexistent paying customers"!). From the external risks of network protocol weaknesses to the internal failure of insufficient buffer overflow prevention mechanisms, the number of "weakest links" available to fall against a determined attacker can be quite staggering.
In fact, an attacker is often not necessary to make code fall flat on its face--as many computer users can attest to, software written under several software paradigms falls apart in the face of extended but ultimately normal usage.
My question for you is, as a well respected language designer and programmer, what can we as a community do to deal with these sibling demons of instability and insecurity? Should we adopt languages such as Ada, which place breathtaking amounts of protections into the compile-time phase? Do we move towards the model of simplicity advocated by Schneier, well aware of the exponential increase in unpredictable interactions? Should we worry about the prevalence of interpreted languages as a vector for in-band attacks? What should we be doing that we aren't?
In short, Bjarne...Where To, Fearless Leader?
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Assuming that C/C++ is going to remain the One True Systems Programming Language for a long time, I have a question that is purely opinion-based but cries out for your personal opinion as the designer of C++. What scripting language do you feel most closely matches C++ in spirit and implementation? Do you use any of them yourself, to hack together prototypes over larger bodies of code? Do you feel that any of them are advancing the practice of programming in general?
;-)), but you would certainly be a better judge than I!
I noticed in Kernighan & Pike's latest book ("The Practice Of Programming" I believe it is... I gave a copy to a coworker whom I enjoyed sharing a project with) that they give several examples in Perl and Awk, in addition to C, C++, and Java. (I'm going to ignore Java for the time being; I have written plenty of Java code but I feel more confident that C/C++ will run where I want and need it to, plus it's easier to integrate with existing libraries IMHO). What are your feelings on this trend, as evidenced in my application arena by such projects as the mod_perl API to Apache and the AOLserver Tcl API? It may be unnecessary for me to note that Perl seems to be closest to C++ in the way it allows great flexibility (and lets you "blow your whole leg off"
I looked through your FAQ and didn't find anything resmbling this question; the folks at Reliable Software convinced me that the STL offers most if not all of the functionality of Perl to a C++-only programmer, but in my experience it wasn't really an apples-to-apples comparison (nothing beats Perl for text processing, for example). Nonetheless I'm sure that you have some insight as to how well a pure-C++ vs. scripting-and-systems-programming approach scales in large projects.
Anyways, that's all. OOP seems to make my life easier, but user-centered design and rapid prototyping (or just rapid programming) tools like Perl are equally important to getting things out the door. I wondered what you thought of this phenomenon and which tools you select for your work.
Remember that what's inside of you doesn't matter because nobody can see it.
Unlike Ada or Java, C++ currently has no facilities that allow a programmer or software engineer to ensure that a fault (e.g. a pointer error) in one component does not cause errors in another component (the facilities that C++ has are advisory).
The traditional answer has been to use better overall software engineering and design. But that does not work in a world in which components come from various different sources with different standards and coding conventions.
Java has many problems, but it does have a commitment to runtime safety and fault isolation. And Java's promise really works out in practice: we can combine dozens of independently developed components and trace any software faults to specific components reliably. We'd like to have the safety and decomposability of Java with the efficiency and control of C++, but given the choice, safety and decomposability usually win out for day-to-day applications for us.
So, what does the future hold for C++ runtime safety and fault isolation? Will future C++ standards mandate more facilities than exist right now? If not, how do you think C++ can survive in a world where software is composed of hundreds of independently developed components?
OpenSource programmers can write code in whatever language they want. Consequently, they write a lot of C, Perl, and Python. But with some notable exceptions, they don't write C++.
Contrast that with the lanuages programmers use at work, which are primarily C++ and Java.
It can't be entirely explained by the size of the programs written either. And as your FAQ says in the section C is better than C++ for small projects, right?, you believe that any C program can be better written in C++.
So why the disparity then?
Templates have these advantages:
- compile-time type safety
- performance (no dynamic binding - function calls can often be expanded inline, avoiding a function call altogether)
OO has these advantages:- simpler programming - you can get some extremely long compiler errors when working with templates
- less code bloat
- it seems unfortunate for so much code to be in header files instead of
.cpp files (circular #include's can be fun)
The craziness over template-orientation seems counter-productive to me. Templates are a great feature of C++ and they are the only reasonable way to solve some problems in C++. However, many now seem to think they should be used to solve every problem. I agree that compile-time type safety is a Good Thing, but are we making an intelligent decision given that:- dynamic_cast allows safe downward casting in an inheritance hierarchy
- Moore's law is still going strong : most people writing application software really do not need to obsessively count CPU cycles any more - choosing the right algorithms is more important than an O(1) improvement. Was it Knuth who said "premature optimization is the root of all evil."?
CPU cycles are becoming more and more plentiful whereas talented designers and programmers are not. Template-orientation seems to make the wrong trade-off. I know that TO and OO can be used together in one program, but they are very different ways of achieving re-use. When should one be favoured over the other?In the name of God, WHY? For the love of all that we hold sacred and holy, WHY?!?
One of the the features that C++ can be said to lack, as a high-level language, is a garbage collector. Or rather, it's not so much that no collector exists (the Hans Boehm conservative C/C++ garbage collector is one, after all) but the fact that it isn't well integrated in the C/C++ API.
Do you regret this? Do you think someday we'll have a decent programming language with a garbage collector (i.e. one which is well integrated in the language and not just an add-on)? Java might have been just that only its eficiency (notably that of the GC) was terrible: do you think that was a necessity or just a consequence of the wrong decisions being made?
Was there no way to avoid having private members (data and methods) of a class in the main definition of a class?
One of the ideas of OO is information hiding and encapsulation of implementation details.
Private data members declared in a class definition used by external objects runs counter to these OO concepts. Other objects are supposed to be "blind" to the inner workings of the object and yet see private methods and data members.
IMHO it is also a major hassle in the earlier stages of a new project or new additions to a project, when changes in the inner workings of classes are frequent.
I realize that part of the problem is the need to know the size of the object for memory allocation purposes.
Did you think of this contradiction when designing C++ and were there any attempts at solving it?
In your FAQ, you say that you are working on "fundamental ways of improving the tools and techniques we use to build large real-world systems."
That's been on your FAQ for at least 3 years now. What can you tell us about this work? What have you found?
making garbage collection standeard in C++ would be that it would reduce the language a bit by forinstance forbidding typecasts between pointers and integers
You lost me there. Why would garbage collection prohibit that?
At the basic machine level, everything in the computer's memory is just bits. As such, a garbage collector, without having some sort of memory markup, cannot tell if a memory address holds a value or a pointer to another address. One of the better forms of garbage collection is copy collection, which just reaches the memory currently being used - all other memory is ignored. It does this by following pointers. I believe Java implements this form of GC. If the garbage collector can't tell if a memory address holds a pointer or a value (as is the case with C++, which will allow all kinds of crazy casts), it can't know if the data it's looking at is needed or not.
As it is, garbage collection in C++ can only be conservative, which collects iff there is no doubt that freeing that particular memory address is a safe operation. Naturally, this is much less efficient than only accessing memory in use.
There is a saying, "Objects die young." Most objects that are instantiated are only there for the duration of a function call. Assuming this to be generally true, copy collection is very efficient, because it won't have to access most of the instantiated objects. Hand allocation/deallocation requires that you touch every piece of allocated memory. Saying that hand allocation/deallocation runs more efficiently than GC only holds true for conservative collectors. More formally put, GC runs in O(memory in use) and only runs when memory runs out. This is multiplication by a constant, so it is still O(memory in use). Hand (de)allocation runs in O(allocated memory). If memory in use = allocated memory, than you can't free anything anyway.
The power of pointers is its weakness. You can't guarantee object integrity when you can randomly write to the memory holding the object.
And if you can't guarantee object integrity, you can't guarantee good garbage collection. GC really doesn't belong in C++.
- Y
"There is no culture in computer science, only cults." - M. Felleisen
From your FAQ, it appears you have strong opinions on the relative merits of C vs. C++ for most applications. I quote, in particular:
Not in my opinion. I never saw a project for which C was better than C++ for any reason but the lack of a good C++ compiler.
Do you have any idea why C++ was rejected as the implementation language by the most experienced C programmers, those folks now at lucent.com (Dennis Ritchie, Rob Pike, et al), for their most visible projects, Plan 9 and Inferno?
Surely, these people had access to a good C++ compiler.
If I may have a follow up, but closely related, question. Was the division of the Bell Labs Research staff between Lucent and AT&T related to a division of opinions concerning C and C++?
-Jordan Henderson
A few things I've noticed throughout this discussion is almost ignorance of newer languages and language ideas.. Do not forget that the average software engineering development takes 18 YEARS to be put into widespread use.
OO has been with us since 1980. Its only in the mid-90's that its become big. Similarily, the new language ideas that have been developed relatively recently (functional programming--haskell, sml-nj, ocaml) will be the languages of the future in another 10 years.
In these languages..Here I will refer to SML-NJ, as I am most familiar with its type system, they are strongly typed. Polymorphic; lists are TRULY polymorphic, Unlike templates, there's no code duplication. They are also extremely strongly typed. In actuality they have an order of magnitude more typing information than C++ has, except that I don't care because the compiler itself intelligently infers all of that typing information fully automatically. Functions are truly first-order values. They may be 'created' at runtime (via partial application or closures), stored, passed around, and anything else.
SML is also much more understandable and more consise. It also has a module system that's extremely careful. You cannot even compile a program that violates the module system. As a language, the specification is well under 100 pages of carefully formalized mathematics.. (Though a careful analysis of SML shows that there are 'dusty corners' in the specification. My research right now deals with specifying a language so explicitly that an automated theorem proving system can prove the 'correctness' of the language specification. If anyone's interested in the tools I'm using, www.twelf.org.)
As far as consiceness and modularity: Remember the law of software engineering, half the number of lines of code means 5x easier to analyse, debug, and maintain.
As for the other languages, haskell has an even more versatile type system than SML-NJ has, I think its powerful enough to handle most of the typing characteristics of OO programming. OCaml is another language in this group.
While its still true that none of these languages are ready for prime time yet, I suspect that derivatives from them (like ML-2000) may be the language of the future; the languages that everyone will be calling the pancea in 10 years.
Given that it will probably be at least a decade or two until the next 'big thing' comes out, what things currently in the pipeline do you think will be big? Will it be the strongly typed functional languages? Will it be the a Java-style IDE where people don't think of a program as a set of linear text files but rather as a collection of objects and methods?
Another way of asking the same question, what abstractions do you feel will be the ones exploited in the future? Will the IDE abstract away the textual or linear representations of the code? Will typing, interfaces, and modularity be used to abstract away the objects implementing an interface? Will we finally have a good application programming language which completely abstracts away the ideas of bits, bytes, pointers?
Or, should I shut up because I've been around 'academic' language designers too much, who don't know how to make a language that the majority would accept?