Well, it's recorded in Bjarne's "The C ++ programming language. I just saw it again. Put it on the blog. For the shortcomings of iterator implementation, that is, the overhead caused by the call of virtual functions, the solution is to erase virtual functions, but how to achieve polymorphism? For "intrusive" containers (Note: Elements in a container must inherit the specific interfaces/superclasses provided by the container framework before they can be placed into the container design, for example, only subclasses of objects in Java can enter the Java container ...... It seems to be nonsense, but it is not for CPP ). BJ (Note: Bjarne, CPP old bean) thinks that object-based container implementation is very bad. However, for Java, a single inherited OO language, Object-based containers are not "intrusive" (the language is "intrusive ?). The disadvantage of such a container is that it is difficult to directly put the basic type into the transformation and the resulting performance overhead. In jdk5, automatic packing and generic syntax have eliminated these manual factors, and performance defects cannot be remedied. The "Fat interface" of the container that BJ thinks is not a problem. If there is a good convention, it means that if a method returns a container abstracted to the collection, in fact, we will make the minimum functional assumption for this container, that is, we should not make too many requirements on the order, operation time, and so on. If the return value is list, then we want it to be orderly, and so on. In essence, the container expressed using interfaces also transmits the concept of "concept" rather than "class. This is similar to STL. Although many methods can only throw unsupportedmethodexception in the implementation of the collection interface, it seems that it is not so elegant, however, it provides more obvious readability and type check during compilation. In contrast to STL, its typename keyword can already be used to illustrate the problem. If a method is used to operate a generic container C:
Template < Class C > Void F (C & C)
... {
Typename C: iterator ITER = C. Begin ();
Typename C: value_type s = 0 ;
While (P ! = C. End ())
... {
S+ = *P;
++P;
}
}
The problem is that I cannotCodeIndicates the concept of "This Code is intended for STL containers". I can only describe it in this document. This is a huge loss for code readability: it cannot be self-interpreted. Even if I have to use typename to tell the compiler that "C: iterator is a type", I cannot raise it all to the height of a syntax. Of course, for the performance benefits of STL and generics, this little loss is nothing. After all, this code is not applied (instantiation ?) It didn't make sense before, but if we instantiate it with a wrong type (F <int>), we can still find problems during compilation. But after all, JDK style is a blessing for class library users. It is closer to human languages.
