同Bjarne Stroustrup的Email采访对话(1993年)
An E-mail Conversation with Bjarne Stroustrup
By Mike Toms
Overload, 1(2):, June 1993
Q: Many C++ users are aware that you are currently engaged with the ANSI/ISO standardisation of C++ and in particular, the enhancements. What do you feel are the most major enhancements that should be part of the standard? (regardless of whether or not they are an option)
Q:许多C++用户都知道，您目前正在从事C++的ANSI/ISO标准化，尤其是增强功能。您认为标准中最主要的增强功能是什么？（无论是否为选项）
A: We, that is the ANSI/ISO committee, have accepted templates, exception handling, run-time type information, and a couple of extension I consider minor.
That in itself is a lot for the community to absorb and for the implementors and educators to catch up with.
However, I hope to see namespaces accepted at the Munich meeting in July. Namespaces will provide significant help in organizing programs and in particular in composing programs out of separately developed libraries without the name clashes. Namespaces are also easy to implement and easy to learn.
I had them implemented in five days and I have taught people to use them in 10 minutes.
A:我们，也就是ANSI/ISO委员会，已经接受了模板、异常处理、运行时类型信息和一些我认为次要的扩展。这本身就是社区需要吸收的内容，也是实施者和教育者需要赶上的内容。
然而，我希望在7月份的慕尼黑会议上看到命名空间被接受。名称空间将在组织程序方面提供重要帮助，尤其是在使用单独开发的库编写程序时，不会出现名称冲突。名称空间也易于实现和学习。
我在五天内就实现了它们，我还教会人们在10分钟内使用它们。
For example, two suppliers may each use their own namespace so that names will not clash:
例如，两个供应商可能各自使用自己的名称空间，以便名称不会冲突：
namespace X {
class String { ... };
typedef Bool int;
int f(const char*);
void g();
}
namespace Y {
class String { ... };
enum Bool { false, true };
int f(int);
void h();
}
A user can then pick and chose among the names: 然后，用户可以在名称中进行选择：
void my_funct()
{
X::String s = "asdf";
Y::f(2);
X::g();
}
or state a preference for a particular namespace: 或声明特定命名空间的首选项：
void your_func()
{
using namespace X;
String s = "asdf"; // X::string
Y::f(2);
g(); //X::g
//...
}
There are more details, but these are the basics (and this is an interview, not a tutorial). 有更多的细节，但这些是基本的（这是一个采访，不是教程）。
I suspect that namespaces will be the last major extension in this round of work.
We can of course have a nice little discussion about what 'major' means in this context, but we do need to get a draft standard ready for public review in September '94 and we have a lot of work to do before then.
I suspect that the extensions' group will be busy with cleaning up the description of templates and exceptions and dealing with proposals for little extensions - most of which will also have to be rejected or postponed.
Then we'll see what the response to the public review period is and work on based on that.
我怀疑命名空间将是这一轮工作中的最后一个主要扩展。当然，我们可以就“主要”在这种情况下的含义进行一次很好的讨论，
但我们确实需要在1994年9月准备好一份标准草案供公众审查，在此之前我们还有很多工作要做。我怀疑扩展小组将忙于清理模板和例外情况的描述，并处理小扩展的建议，
其中大多数也将被拒绝或推迟。然后，我们将了解公众对审查期的反应，并在此基础上开展工作。
I hope this doesn't sound too negative, but stability is essential for C++ users and we can't just add every feature that people like. Even if we added just the GOOD ideas the language would become unmanageable. We have to apply taste and judgement. A language has to be a practical tool and not just a grab bag of neat features and bright ideas.
我希望这听起来不会太消极，但稳定性对于C++用户来说是必不可少的，我们不能只添加人们喜欢的所有功能。即使我们只添加好的想法，语言也会变得难以管理。我们必须应用体验和判断。
语言必须是一种实用的工具，而不仅仅是一堆整洁的特性和聪明的想法。
The minor extension I think would be most important is a set of cast operators to provide an alternative to the old "do everything" cast. Unfortunately, there still is a few loose ends in that proposal and if I can't resolve those I can't recommend its adoption and it won't make it into the standard.
我认为最重要的次要扩展是一组cast操作符，以提供旧的 “无所不能” cast 的替代。不幸的是，该提案中仍有一些漏洞，如果我不能解决这些问题，我就不能建议采用该提案，也不能将其纳入标准。
The basic idea is that a cast like 其基本思想是cast就像下面的
(T)v
can do too many things. It may be producing a new arithmetic value from v,
it may be producing a pointer to a different subobject, it may produce a pointer of a type unrelated to the object v pointed to,
it may be producing a pointer from a non-pointer type, it may be producing an integer from a pointer.
It may be constructing a new object of type T by calling a constructor. It all depends on the type of v and on what kind of type T is. A reader of
可以做很多事情。它可能从 v 生成新的算术值，可能生成指向不同子对象的pointer，可能生成与v指向的对象无关的类型的pointer，
可能从非指针类型生成指针，可能从pointer生成整数。它可能通过调用构造函数来构造 T 类型的新对象。这完全取决于v的类型和T的类型。
(T)v
cannot know without looking at the context if the declarations in that context change the meaning of the cast quietly changes.
Because of these quiet changes and because programmers frequently misunderstand what the casts they and their colleagues write actually do.
I consider the old-style cast "slippery".
It'll do something, but far too often it's not obvious what that is.
We at Bell Labs and many others have found this a significant source of bugs and maintenance problems (we do measure such things).
If the writer of the cast could say what was really meant to be done many of these problems would go away.
如果上下文中的声明发生变化，读者不看上下文就无法知道cast的含义是否发生了悄然的变化，正在因为这些安静的改变，程序员经常误解他们和他们的同事所写的casts的实际功能。
我认为旧式风格“靠不住的”。它会做些什么，但通常情况下，这是什么并不明显。
我们贝尔实验室和其他许多实验室都发现这是bug和维护问题的重要来源（我们确实估量了这些问题）。如果cast的作者能说出真正的意图，那么许多问题就会消失。
The basic idea is to have three operators doing three basic kinds of conversions currently done by (T)v:
基本思想是让三个操作符进行三种基本类型的转换，目前由（T）v 完成
static_cast<T>(v) // for reasonably well-behaved casts
reinterpret_cast<T>(v) // for horrible casts
const_cast<T>(v) // for casting away const and volatile
此外，我们现在有
dynamic_cast<T>(v) // for run-time checked casts
Naturally, we can't just ban old-style casts, but with these new operators In place people could write better new code and eventually fade out old cast.
当然，我们不能仅仅禁止旧的类型转换，但有了这些新的操作符，人们可以编写更好的新代码，最终淘汰旧的类型转换。
Currently, I'm stuck on problems related to const. Many people are VERY keen that constness doesn't quietly disappear. Therefore, my intent was that only const_cast should be able to remove constness. Unfortunately, people can ADD a const specifier in one operation and then go on to try to modify a const later where it is not obvious what is going on. The problem kind of that's holding me up is:
目前，我陷入了与const相关的问题中。许多人都非常希望 constness 不会悄悄消失。因此，我的意图是只有 const_cast 才能移除 constness(常量性)。不幸的是，人们可以在一个操作中添加常量说明符，然后在不明显的情况下继续尝试修改const。阻碍我前进的问题是：
void f(X* p); // f modifies *p
void (*fp)(const X* p); // *fp doesn't modify *p
fp = (void (*)(const X*))&f; // forcing fp to point to f
// note 'const' ADDED
void g(const X* p) // g doesn't modify *p
{
fp(p); // OOPS, thanks to the cast
// above *p gets modified
}
This is a highly obscure effect. Fortunately, it doesn't actually bite people very often, but when it does it can be extraordinarily hard to track down. Please note that this is also a problem in ANSI C. I have suggested:
这是一个非常模糊的效果。幸运的是，它实际上并不经常对别人产生不良影响，但一旦产生不良影响对其它人，就很难找到它。请注意，这也是ANSI C中的一个问题。我建议：
fp = static_cast<(void (*)(const X*)>(&f); // error
This wouldn't work because the compiler would know that the cast was suspect with respect to const and people would have to write
这是行不通的，因为编译器会知道 cast 在const方面是可疑的，人们必须编写
fp = const_cast<(void (*)(const X*)>(&f); // ok
My worry is that many const problems are so obscure and subtle that people would decide that the compiler was wrong and prefer to use the old style cast that would be seen as simpler. This is the kind of problem where I have a hard time deciding whether the cure might be worse than the illness. I have a logically sound solution, but can it be successfully introduced into common C++ use?
我担心的是，许多const问题是如此模糊和微妙，以至于人们会认为编译器是错误的，而更喜欢使用被视为更简单的旧式cast。在这种情况下，我很难判断治疗是否比疾病更糟糕。我有一个逻辑上合理的解决方案，但它能成功地引入到常见的C++中吗？
Q: If you had the opportunity to turn the clock back to 1980 and start the development process again, what would you have done differently and why?
A: You can never bathe in the same river twice. There are things that I could do better now, but some of those things would have killed C++ if I had done them then. For example, I couldn't work without virtual functions, yet the introduction of virtual functions were postponed from 1980 to 1983 because I - with reason - doubted my ability to get people to accept them in 1980/81. More to a current point, many can now afford garbage collection, but in 1980 essentially all of my users could not. Had C with Classes or early C++ relied on GC then the language would have been stillborn. A language has to fit with its time and grow with the changing demands. The idea of a perfect language in the abstract is fundamentally wrong. A good language serves its users as they are, for the problems they have, on the platforms they work on.
I'm not really sure Bjarne (vintage 1993) knows more about the vintage 1980 users than Bjarne (vintage 1980) did. Therefore, I don't really want to conjecture. I now know things about the vintage 1993 users that Bjarne (vintage 1980) didn't, and that knowledge I'm trying to put to good use in the standards group and elsewhere.
Q: When C++ is standardised, do you have plans to extend it further? (ANSI 2010 C++ Std perhaps)
Q:当C++标准化后，您是否计划进一步扩展它？（ANSI 2010 C++标准）
A: My immediate reaction is "No way!" I have had enough of language work to last a lifetime. As I'm disengaging from language work I'm getting back into the use of language that started it all. I didn't really want to design a language, I just happened to have programming problems for which there were no sufficiently good language available at the time. If - and only if - my future projects gets me into that situation again will I consider new language features. At the HOPL-2 conference Dennis Ritchie observed that there seemed to be two kinds of languages: the ones designed to solve a problem and the ones designed to prove a point. Like C, C++, is of the former kind.
A:我的第一反应是“不可能！”我已经做了足够多的语言工作，持续了一生。当我从语言工作中脱离出来时，我又回到了语言的使用中，这一切都是由语言开始的。
我并不是真的想设计一种语言，我只是碰巧遇到了一些编程问题，当时还没有足够好的语言来解决这些问题。如果——也只有当——我未来的项目让我再次陷入这种情况，
我才会考虑新的语言特性。在HOPL-2会议上，丹尼斯·里奇（DennisRitchie）注意到 似乎有两种语言：一种是用来解决问题的语言，另一种是用来证明观点的语言。像C，C++是前一种。
补充: 这个观点很有意思，意思是说c是用来证明观点的，c++是用来解决问题的。
Q: What was the programming problem that started you on the C++ development track?
Q:是什么编程问题让你开始了C++开发的道路？
A: I was looking for a way to separate the UNIX kernel into parts that could run as a distributed system using a local area network. I needed to express the kernel as a set of interacting modules and I needed to model the network for analysis. In both cases, I needed to class concept to express my ideas. I never actually got back to those problems myself, though I have over the years helped on several projects using C++ to simulate networks and network traffic to help design networks and protocols.
A:我正在寻找一种方法，将UNIX内核分成几个部分，这些部分可以作为使用局域网的分布式系统运行。我需要将内核表示为一组交互模块，并需要对网络进行建模以进行分析。
在这两种情况下，我都需要将概念分类来表达我的想法。我自己从来没有真正回到这些问题上来，尽管多年来我帮助过几个项目，使用C++模拟网络和网络流量，帮助设计网络和协议。
Q: I often hear (mainly from Smalltalk programmers) the criticism that C++ is not a 'pure' OO language. Do you think that being a 'hybrid' language strengthens or weakens C++ as a commercial programming language?
Q:我经常听到（主要是Smalltalk程序员）批评C++不是一种“纯”的OO语言。你认为作为一种“混合”语言会加强或削弱C++作为商业编程语言的地位吗？
A: Arm-chair philosophers also tend to make that criticism. I think that C++'s real strength comes from being a 'hybrid.' As I said above, C++ was designed to solve problems rather than (merely) to prove a point. C++ is a general-purpose programming language, a multi-paradigm programming language rather than (merely) an object-oriented language. Not all problems map well into any particular view of programming. In particular, not all problems map into a view of object-oriented programming as the design and use of deeply nested class hierarchies demonstrate. The programming problems we face and people's ways of thinking are much more varied than people would prefer to believe. Consequently, it is easy to design a smaller, simpler, and cleaner language than C++. I knew that all along. What is needed, though, and what I built was a language that was flexible enough, fast enough, and robust enough to cope with the unbelievable range of real challenges.
坐在扶手椅上的哲学家也倾向于提出这种批评。我认为C++的真正优势来自于它的“混合体”正如我上面所说的，C++是为了解决问题而设计的，而不仅仅是为了证明一个观点。
C++是一种通用编程语言，一种多范式编程语言，而不仅仅是一种面向对象的语言。并非所有问题都能很好地映射到编程的任何特定视图中。
特别是，并不是所有的问题都映射到面向对象编程的视图中，正如设计和使用深度嵌套的类层次结构所证明的那样。
我们面临的编程问题和人们的思维方式比人们更愿意相信的要多种多样。因此，设计一种比C++更小、更简单、更干净的语言很容易。我一直都知道这一点。
然而，我们需要的是一种足够灵活、足够快速、足够健壮的语言，以应对令人难以置信的真实挑战。
补充：
这个是国内在谈论C++时都没有提及的，所以C++是当时遇到了解决不了的问题的时候，创造的语言。
Q: Do you think that subjects such as Garbage Collection and Persistence should be dealt with as part of the language, or be implementation/third-party add-ons?
Q: 您认为垃圾收集和持久性之类的主题应该作为语言的一部分来处理，还是应该是实现/第三方附加组件？
A: Persistence is many different things to different people. Some just wants an object-l/O package as provided by many libraries, others wants a seamless migration of objects from file to main memory and back, others wants versioning and transaction logging, others will settle for nothing less than a distributed system with proper concurrency control and full support for schema migration. For that reason, I think that persistence must be provided by special libraries, non-standard extension, and/or "third-party" products. I see no hope of standardizing persistence.
坚持对不同的人来说是许多不同的东西。一些人只想要一个由许多库提供的object-l/O包，其他人想要对象从文件到主内存的无缝迁移，其他人想要版本控制和事务日志记录，其他人只需要一个具有适当并发控制和完全支持模式迁移的分布式系统。因此，我认为持久性必须由特殊库、非标准扩展和/或“第三方”产品提供。我看不到标准化持久性的希望。
The ANSI/ISO standards committee's extensions' group is looking into whether we can help with some of the simpler levels of this problem either through language features or through standard library classes.
ANSI/ISO标准委员会的扩展小组正在研究我们是否可以通过语言特性或标准库类来帮助解决这个问题的一些更简单级别。
The support for run-time type identification that we accepted in Portland in March contains a few "hooks" deemed useful by people dealing with persistence.
3月份，我们在波特兰接受了对运行时类型识别的支持，其中包含一些被处理持久性的人认为有用的“hooks”。
Optional garbage collection is, I think, the right approach for C++. Exactly how that can best be done is not yet known, but we are going to get the option in several forms over the next couple of years (whether we want to or not).
我认为，可选垃圾收集是C++的正确方法。目前还不清楚如何才能最好地做到这一点，但我们将在未来几年内以多种形式获得该选项（无论我们是否愿意）。
Why GC? 为什么GC？
It is the easiest for the user. In particular, it simplifies library building and use. 这对用户来说是最简单的。特别是，它最简化了库的建设和使用。
It is more reliable than user-supplied memory management schemes for some applications. 对于某些应用程序，它比用户提供的内存管理方案更可靠。
Why not GC? 为什么不GC呢?
GC carries a run-time overhead that is not affordable to many current C++ applications running on current hardware.
GC带来的运行时开销对于在当前硬件上运行的许多当前C++应用程序来说是无法承受的。
Many GC techniques imply service interruptions that are not acceptable for important classes of applications (e.g. real-time, control, human interface on slow hardware, OS kernel).
许多GC技术意味着服务中断对于重要的应用程序类（例如实时、控制、慢硬件上的人机界面、操作系统内核）是不可接受的。
Many GC techniques carry a large fixed overhead compared to non-GC techniques. Remember, not every program needs to run forever, memory leaks are quite acceptable in many applications, many applications can manage their memory without GC and without relative high-overhead GC-like techniques such as reference counting. Some such applications are high performance applications where overhead from unneeded GC is unacceptable.
与非GC技术相比，许多GC技术具有较大的固定开销。请记住，并不是每个程序都需要永远运行，内存泄漏在许多应用程序中都是可以接受的，许多应用程序可以在没有GC的情况下管理内存，也不需要相对高开销的类似GC的技术，如引用计数。一些这样的应用程序是高性能应用程序，不需要的GC带来的开销是不可接受的。
Some applications do not have the hardware resources of a traditional general-purpose computer.
一些应用程序没有传统通用计算机的硬件资源。
Some GC schemes require banning of several basic C operations (e.g. p+1, a[i], printf()).
一些GC方案要求禁止几个基本的C操作（例如 p+1、a[i]、printf（））。
I know that you can find more reasons for and against, but no further reasons are needed. I do not think you can find sufficient arguments that EVERY application would be better done with GC without restricting the set of applications you consider. Similarly, I don't think you can find sufficient arguments that NO application would be better done with GC without restricting set of applications you consider.
我知道你可以找到更多的赞成和反对理由，但不需要更多的理由。我认为，如果不限制您所考虑的应用程序集，您无法找到足够的理由证明每个应用程序都可以使用GC更好地完成。类似地，我认为您无法找到足够的理由证明，如果不限制您所考虑的应用程序集，没有哪个应用程序能够更好地使用GC。
My conclusion (as you can find in "The C++ Programming Language" (even the first edition) and also in the ARM) is that GC is desirable in principle and feasible, but for current users, current uses, and current hardware we can't afford to make the semantics of C++ and of its most basic standard libraries dependent on GC.
我的结论（正如你在《C++编程语言》（甚至是第一版）和ARM中所发现的那样）是，GC在原则上是可取的，也是可行的，但对于当前的用户、当前的使用和当前的硬件，我们无法使C++及其最基本的标准库的语义依赖于GC。
But mustn't GC be guaranteed in "The Standard" to be useful?
但是，难道不能在“标准”中保证GC是有用的吗？
We don't have a scheme that is anywhere near ready for standardization. If the experimental schemes are demonstrated to be good enough for a wide enough range of real applications (hard to do, but necessary) and doesn't have unavoidable drawback that would make C++ an unacceptable choice for significant applications, implementors will scramble to provide the best implementations.
我们还没有一个接近标准化的方案。如果实验方案被证明对于足够广泛的实际应用程序来说足够好（很难做到，但却是必要的），并且没有不可避免的缺点，使C++成为重要应用程序无法接受的选择，那么实现者将争相提供最佳实现。
I expect that some of my programs will be using GC within a couple of years and that some of my programs will still not be using GC at the turn of the century.
我期望我的一些程序将在几年内使用GC，而我的一些程序在在旧世纪结束新世纪开始的时候(世纪之交)仍然不会使用GC。
I am under no illusion that building an acceptable GC mechanism for C++ will be easy - I just don't think it is impossible. Consequently, given the number of people looking at the problem, several solutions will emerge and hopefully we'll settle on a common scheme at the end.
我并没有幻想为C++构建一个可接受的GC机制会很容易——我只是不认为这是不可能的。因此，考虑到关注这个问题的人数众多，将出现几种解决方案，希望我们最终能达成一个共同的方案。
Q: What methodology do you use when designing C++ programs?
A: That depends what kind of problem I'm trying to solve. For small programs I simply doodle a bit on the back of an envelope or something, for larger issues I get more formal, but my primary "tool" is a blackboard and a couple of friends to talk the problems and the possible solutions over with. Have a look at chapters 11 and 12 in "The C++ Programming Language (2nd Edition)" for a much more detailed explanation of my ideas (which naturally are based on experience from the various projects I have been involved in).
Q: Tools nearly always lag behind the development of a 'new' language, in what areas do you feel that the C++ development world is being deprived of suitable software tools?
A: Actually, I think that in the case of C++ tools are lacking less than education is. C++ isn't just a new syntax for expressing the same old ideas - at least not for most programmers. This implies a need for education, rather than mere training. New concepts have to be learned and mastered through practice. Old and well-tried habits of work have to be re-evaluated, and rather than dashing of doing things "the good old way" new ways have to be considered - and often doing things a new way will be harder and more time-consuming than the old way - when tried for the first time.
The overwhelming experience is that taking the time and making the effort to learn the key data abstraction and object-oriented techniques is worth while for almost all programmers and yields benefits not just in the very long run but also on a three to twelve month time scale.
There are benefits in using C++ without making this effort, but most benefits require the extra effort to learn new concepts - I would wonder why anyone not willing to make that effort would switch to C++.
When approaching C++ for the first time, or for the first time after some time, take the time to read a good textbook or a few well-chosen articles (the C++ Report and the C++ Journal contains many). Maybe also have a look at the definition or the source code of some major library and consider the techniques and concepts used. This is also a good idea for people who has used C++ for some time. Many could do with a review of the concepts and techniques. Much has happened to C++ and its associated programming and design techniques since C++ first appeared. A quick comparison of the 1st and the 2nd edition of "The C++ Programming Language" should convince anyone of that.
As for tools (says he, getting off his hobby horse :-), I think that what we are seeing today will look rather primitive in a few year's time. In particular, we need many more tools that actually understand C++ (both the syntax and the type system) and can use that knowledge. Currently, most tools know only a little bit about syntax or about the stream of executable instructions.
Eventually, we'll have editors that can navigate through a program based on the logical structure of a program rather than the lexical layout, be able to click on a + and instantly be told with it resolves to under overload resolution, and have re-compilation be incremental with a small grain. Such an environment would make what you can currently get for languages such as Lisp and Smalltalk look relative primitive by taking advantage of the wealth of information available in the structure of a C++ program.
Let's not get greedy, though. C++ was designed to be useful in tool poor environments and even in a traditional Unix or DOS environment it is more than a match for many alternatives for many applications. Environments and tools are nice, and we'll eventually get great ones, but for much C++ at least they are not essential.
Q: With all the advantages of C++, do you think the use of ANSI C will decline?
A: In a sense, yes. You can't buy an ANSI C compiler for the PC market any more except as an option on a C++ compiler. I expect that over the years we'll see a gradual adoption of C++ features even by the most hard-core C fanatics. The C++ features are now available in the environments C programmers use, they work, and they are efficient. C programmers would be silly not to take advantage of the C++ features that are helpful to them.
Not that I'm not preaching some OO religion. C++ is a pragmatic language and is best approached in a pragmatic manner: Use the parts of it that are useful to you and leave the rest for later when it might come in handy. I strongly prefer sceptics to "true believers." Naturally, I recommend "The C++ Programming Language (2nd edition)" as the main help in understanding C++ and its associated techniques. It contains a lot of practical information and advice - on programming, on the language, and on design - and very little hype and preaching. I think too many C++ texts push a particular limited view of what C++ is or aims at delivering only a shallow understanding of C++.
To gain really major benefits from C++ you have to invest a certain amount of effort in learning the new concepts. Writing C or Pascal with C++ syntax gives some benefits, but the greatest gains come from understanding the abstraction techniques and the language features that support them. Just being able to parrot the OO buzzwords doesn't do the trick either. The nice thing about C++ in this context is that you can learn it incrementally and can get benefits proportionally to your effort in learning it. You don't have to first learn everything and only then start reaping benefits.
Q: I feel that C++ should be (like C) "lean and mean" and some of the additions (such as RTTI) will be adding layers of "fat" to the language. Do these extensions impose a penalty on the C++ community even if no use is made of them?
A: C++ is lean and mean. The underlying principle is that you don't pay for what you don't use. RTTI and even exception handling can be implemented to follow this dictum - strictly. In the case of RTTI the simple and obvious implementation is to add two pointers to each virtual table (that is a fixed storage overhead of 8 bytes per class with virtual functions) and no further overhead unless you explicitly use some aspect of RTTI. In my UNIX implementation, those two words have actually been allocated in the vtbl "for future enhancements" since 1987!
When you start using dynamic casts the implementation needs to allocate objects representing the classes. In my experimental implementation those were about 40 bytes per class with virtual functions and you can do better yet in a production system. That doesn't strike me as much when you take into account that you only get the overhead if you explicitly use the facilities. Presumably, you'd have to fake the features if you wanted them and the language didn't support them and that's more expensive in my experience. One reason for accepting RTTI was the observation that most of the major libraries did fake RTTI in incompatible and unnecessarily expensive ways. The run-time overhead of an unoptimized dynamic cast is one function call per level of derivation between the base class known and the derived class you are looking for.
One thing people really should remember is that a design that relies on static type checking is usually better (easier to understand, less error-prone, and more efficient) than one relying on dynamic type checking. RTTI is for the relatively few (but often important) cases where C++'s static type system isn't sufficient. If you start using RTTI to simulate Smalltalk or CLOS in C++ you probably haven't quite understood the problem or C++.
Q: A lot of programmers (and members of the press) envisage C++ as a language developed solely for the development of GUI products, and that it has no place in the "normal" (whatever that may be) programming arena due to its complexity. I, on the other hand, think that C++ is the best all-round programming language ever invented and should be used for every programming task. A middle ground obviously exists, but what tasks do you see C++ as being best suited for?
A: They are plain wrong. C++ was designed for applications that had to work under the most stringent constraints of run-time and space efficiency. That was the kind of applications where C++ first thrived: operating system kernels, simulations, compilers, graphics, real-time control, etc. This was done in direct competition with C. Current C++ implementations are a bit faster yet.
Also, C++ appears much more complex to a language lawyer trying to understand every little detail than to a programmer looking for a tool to solve a problem. There are no prizes (except maybe booby prizes) for using the largest number of C++ features.
The way to approach a problem with C++ is to decide which classes you need to represent the concepts of your application and then express them as simply and as straight-forwardly as possibly. Most often you need only relatively simple features used in simple ways. Often, much of the complexity is hidden in the bowels of libraries.
Q: C++'s popularity seems to be accelerating at present. Do you think that other OO languages (such as Smalltalk, Actor and Eiffel) and other hybrids like OO-COBOL will make an impact on the growth of C++?
A: I don't think so. Compared to C++, they are niche languages. They all have their nice aspects but none have C++'s breath of applicability or C++'s efficiency over a wide range of application areas and programming styles. Smalltalk seems to have a safe ecological niche in prototyping and highly dynamic individual projects. It ought to thrive. If OO-COBOL takes off it also ought to have a ready-made user base.
Q: I see parallel processors becoming more widely available to programmers in the near future. How easy will it be to use C++ in the parallel programming environment?
A: Parallel processors are becoming more common, but so are amazingly fast single-processors. This implies the need for at least two forms of concurrency: multithreading within a single processor, and multiprocessing with several processors. In addition, networking (both WAN and LAN) imposes its own demands. Because of this diversity I recommend parallelism be represented by libraries within C++ rather than as a general language feature. Such as feature, say something like Ada's tasks, would be inconvenient for almost all users. It is possible to design concurrency support libraries in C++ that approaches built-in concurrency support in both convenience of use and efficiency. By relying on libraries, you can support a variety of concurrency models, though, and thus serve the users that need those different models better than can be done by a single built-in concurrency model. I expect this will be the direction that will be taken by most people and that the portability problems that will arise when several concurrency-support libraries are used within the C++ community can be dealt with by a thin layer of interface classes.
Many thanks for your time Bjarne, I'm sure my readers will enjoy reading your comments.
