Experience the STL in Visual C++.net 2005

To better adapt the STL to. NET Development, the Visual C + + product group redesigned the STL in version 2005 of Visual C + +, named Stl.net, and started offering it from the Beta1 version of the product.

In the design of stl.net, the implementation of STL uses the CLI generics and C + + template mechanism. The 2005 version of C + + will join the support of C++/CLI dynamic programming, and should be the most responsive language for programmer design.

Give programmers a rich choice

A total of three container libraries are available for programmers to manipulate CLI types, and these three container libraries are built on three types of parameterized models.

The Systems::collection libraries that were stored by the original element type are implemented based on the object base class in the CLI type. The following ArrayList implements the IList interface. It represents an array of type objects, in this case, to control the elements of the string type. (This is implemented with version 2 syntax)

void ObjectCollection () { using namespace System::Collections; ArrayList ^as = gcnew ArrayList; As->add ("Pooh"); As->add ("Piglet"); As->add ("Eeyore"); As->add ("Rabbit"); As->sort (); Console::WriteLine ("ArrayList holds {0} elements:", as->count); for (int i = 0; i < as->count; i++) Console::WriteLine (as[i]); int index = As->indexof ("Pooh"); if (index!=-1) { Need a clear downcast string^ item = safe_cast (as[index]); As->removeat (index); } As->remove ("Rabbit"); Console::WriteLine ("\narraylist holds {0} elements:", as->count); ienumerator^ is = As->getenumerator (); while (Is->movenext ()) Console::WriteLine (is->current); }

Now we have introduced a new container library based on the CLI generics mechanism. Can be found in the System::collections::generic namespace. This is an implementation in Visual Studio Beta1, which may change in the final release. Collection is a concrete generic base class from which users can derive their own special container classes. The following sample works the same as the example above, using only a new container library,

Stl. NET provides a type Parameterization model that is different from the previous design style, and we'll talk about it in the next topic. The following is the implementation of the string container.

#include #include void stlcollection () { Vector ^svec = gcnew Vector Svec->push_back ("Pooh"); Svec->push_back ("Piglet"); Svec->push_back ("Eeyore"); Svec->push_back ("Rabbit");　 //Generic algorithm: Sort Sort (svec->begin (), Svec->end ()); Console::WriteLine ("Collection holds {0} elements:", svec->size ());　　 for (int i = 0; i < svec->size (); i++) Console::WriteLine (svec[i)); 　　Generic algorithm: Find Vector::iterator iter = Find (Svec->begin (), Svec->end (), "Pooh"); if (ITER!= svec->end ()) { //no downcast required ... String ^item = *iter; Svec->erase (ITER); } //Generic algorithm: Remove ... Remove (Svec->begin (), Svec->end (), "Rabbit"); Console::WriteLine ("\ncollection holds {0} elements:", svec->size ()); IEnumerator ^is = Svec->getenumerator (); while (Is->movenext ()) Console::WriteLine (is->current); }

Why do you choose Stl.net?

Before we dive into the stl.net, let's start with a brief answer to an unavoidable question: Why do Visual C + + programmers choose stl.net Container classes instead of language neutral systems: Collections or System::Collections:: Generic Library?

Discard system::collections Library and Visual Studio 2005 the decision to provide generic trousers is the same: because of the loss of type information, the parameterized object model is often very complex and unsafe. In simple use, such as having 16 or fewer elements in a container, you can use it for bubble sorting. But when your application involves real-world problems, you have to provide a more complete solution.

So, STL. NET and system::collections::generic libraries become alternatives to a system-level programming language such as Visual C + +. Why should Visual C + + programmers prefer stl.net? This does not make our program with the other. NET language separated away? This is a very realistic question and it is also worthwhile to give an answer.

One reply is "Scalability (extensibility)." The original STL design pattern was invented by Alex Stepanov, who stored the algorithms and containers in different domain spaces. This allows users to add algorithms to the set of algorithms for all containers, or add containers to the container set that each algorithm can apply to. A generic library is a more traditional model. This leads us to the second reply.

The second reply is "Unity (unification)". The level of use of this library and existing code by programmers using C + + has reached expert levels. Not only do we want to provide a way to migrate existing code, but we also hope that the expertise accumulated by programmers will still apply. If you rely on STL in your original C + + programming, and it is hard to imagine a C + + programmer not dependent on STL, then it is. NET is going to make you feel a big mistake-at least that's what I've learned. Many of the C + + experts I've communicated with have mentioned this issue, and therefore represent the migration to. NET holds a reserved attitude.

The third reply is "performance". But C + + programmers have long been reluctant to mention these clichés about the topic of performance, and I'm just a bit of a band--and will be discussed in more detail in a later article.

The final question is. These are great and very good. Stan, but isn't this a disconnect between C + + programmers and C++/CLI programs and the rest of the. NET community? The answer to this question, I think, is a very simple "no". Stl. NET Architecture architect, including Anson Tsao, Martyn Lovell, and P.J. Plauger has considered this issue very carefully, and through support for IEnumerator, IList, and ICollection, we are very confident that stl.net can work with other. NET languages. We will discuss this in more detail in a series of subsequent articles.

Define a public base

There are two ways to understand and use stl.net: one way to learn is by understanding the differences between STL and Stl.net. Another way is by understanding what they have in common. Although those with STL-rich experience seem to need a "difference list", this does not, however, allow you to escape from the smog of unfamiliar libraries, so when we slow down, delve into these or those containers and how they relate to the system collection Libraries--although these are all very neat and elegant, is it better for us to understand these new content directly? At least in the short introductory section below I hope you will do so. In this way, it is possible for those novices to have an understanding of the extended model of the parameterized set provided by STL and Stl.net.

So what does STL and stl.net have in common? Both of these include two main components: sequential (sequential) and associative (associative) container types, and a generic algorithm set. (yes, if you're an experienced STL developer, you should know what I'm going to discuss below.) Again, the two have the same terminology and background, so you have to be patient. The generic algorithm does not directly manipulate the container type. Instead, we used an iterator to pair to identify the range of elements used for the operation. The element range symbol (the formal term is the left inclusive interval) is as follows:

Read as: include first until but not including last [I, Last]

This indicates that the range is from first beginning with last ending but not including last. The range is empty when the one is last.

A sequence set of elements of a single type is stored in a sequential container. The vector and list types are two major sequential containers. (The third sequential container is deque-pronunciation deck-provides the same function as vector, but is used for the special case of inserting and deleting the first element efficiently.) Generally we prefer deque rather than vectors, such as the implementation of a queue. )

Before we can access a contiguous container type, we must include the appropriate header file as follows:

#include #include #include

These header files also contain declarations of shared base class interfaces, such as Interface_vector, and generics in containers, such as Generic_vector.

The associative container (associative container) supports efficient querying of the display and retrieval of existing elements. The two most important of the associative container types are map and set. Map is a key (key)/value (value) pair: Key is used for querying, and value is used to store and retrieve data. For example, a phone book can be simply represented by a map: key is the name of each person, and value is the associated phone number.

Map uses an underlined tree abstraction to arrange entries in ascending order of values. The Hash_map container is capable of more efficient retrieval sorting. However, hash_map iterations are also randomly accessing elements in some way. If the retrieval is the primary activity in the map, the Hash_map container should be preferred.

Set contains a single key value (key value) and an efficient query that supports whether the element exists. For example, a text query system may need to create a common word set and exclude it from text, such as the, and, but, and so on, when creating a text thesaurus. The program will take turns reading every word in the text, checking whether it is a refusal to accept words in the vocabulary, depending on the result of the query, or ignoring the word, or storing it in the database. In addition to set, there is the Hash_set container, which has the same characteristics as the map and Hash_map.

The map and set can contain only one key (key). Multimap and Multiset support the presence of multiple identical keys. Also, take our phone book as an example, we may need to list a person in more than one table. In this case, we need to use Multimap. There are also Hash_multimap and Hash_multiset.

The header files associated with these container types are as follows:

For maps and Multimap #include For set and Multiset #include For Hash_map and Hash_multimap #include For Hash_set and Hash_multiset #include