【導讀】以及多形性，但另一些問題也可能顯得非常重要。本節(jié)將就這些問題進行探討。最重要的問題之一是對象的創(chuàng)建及破壞方式。針對這個問題，解決的方案是各異其趣的。認為程序的執(zhí)行效率是最重要的一個問題，所以它允許程序員做出選擇。?；蛘哽o態(tài)存儲區(qū)域即可。配和釋放提供了一個優(yōu)先級。某些情況下，這種優(yōu)先級的控制是非常有價值的。量、存在時間、以及類型。如果要解決的是一個較常規(guī)的問題，如計算機輔助設。序正式運行時才決定的。由于存儲空間的管理是運行期間動態(tài)進行的，所以在內存堆里分。需要一個簡單的指令，將堆棧指針向下或向下移動即可）。象的創(chuàng)建造成明顯的影響。垃圾收集器顯得方便得多，但要求所有應用程序都必須容忍垃圾收集器的存在，但這并不符合C++語言的設計宗旨，所以。在某些庫中，一個常規(guī)集合便可滿足人們的大多數要求；堆棧的接口與行為與隊列的不同，而。其次，不同的集合在進行特定操作時往往有不同的效率。

　　

【正文】 y rooted hierarchy (such as Java provides) can be guaranteed to have certain functionality. You know you can perform certain basic operations on every object in your system. A singly rooted hierarchy, along with creating all objects on the heap, greatly simplifies argument passing (one of the more plex topics in C++). A singly rooted hierarchy makes it much easier to implement a garbage collector (which is conveniently built into Java). The necessary support can be installed in the base class, and the garbage collector can thus send the appropriate messages to every object in the system. Without a singly rooted hierarchy and a system to manipulate an object via a reference, it is difficult to implement a garbage collector. Since runtime type information is guaranteed to be in all objects, you’ll never end up with an object whose type you cannot determine. This is especially important with system level operations, such as exception handling, and to allow greater flexibility in programming. 3． Collection libraries and support for easy collection use Because a container is a tool that you’ll use frequently, it makes sense to have a library of containers that are built in a reusable fashion, so you can take one off the shelf Because a container is a tool that you’ll use frequently, it makes sense to have a library of containers that are built in a reusable fashion, so you can take one off the shelf and plug it into your program. Java provides such a library, which should satisfy most needs. Downcasting vs. templates/generics To make these containers reusable, they hold the one universal type in Java that was previously mentioned: Object. The singly rooted hierarchy means that everything is an Object, so a container that holds Objects can hold anything. This makes containers easy to reuse. To use such a container, you simply add object references to it, and later ask for them back. But, since the container holds only Objects, when you add your object reference into the container it is upcast to Object, thus losing its identity. When you fetch it back, you get an Object reference, and not a reference to the type that you put in. So how do you turn it back into something that has the useful interface of the object that you put into the container? Here, the cast is used again, but this time you’re not casting up the inheritance hierarchy to a more general type, you cast down the hierarchy to a more specific type. This manner of casting is called downcasting. With upcasting, you know, for example, that a Circle is a type of Shape so it’s safe to upcast, but you don’t know that an Object is necessarily a Circle or a Shape so it’s hardly safe to downcast unless you know that’s what you’re dealing with. It’s not pletely dangerous, however, because if you downcast to the wrong thing you’ll get a runtime error called an exception, which will be described shortly. When you fetch object references from a container, though, you must have some way 10 to remember exactly what they are so you can perform a proper downcast. Downcasting and the runtime checks require extra time for the running program, and extra effort from the programmer. Wouldn’t it make sense to somehow create the container so that it knows the types that it holds, eliminating the need for the downcast and a possible mistake? The solution is parameterized types, which are classes that the piler can automatically customize to work with particular types. For example, with a parameterized container, the piler could customize that container so that it would accept only Shapes and fetch only Shapes. Parameterized types are an important part of C++, partly because C++ has no singly rooted hierarchy. In C++, the keyword that implements parameterized types is “template.” Java currently has no parameterized types since it is possible for it to get by—however awkwardly—using the singly rooted hierarchy.