From C + + to. NET: Mapping templates to generics

This article supporting source code

Discusses iso-c++ text Query language (TQL) applications to the Microsoft®.net Framework and C++/CLI transformations. In particular, I'll delve into how to map templates and the Standard Template Library (STL) to. NET generic tools. Although I worked on the original template implementation of Cfront version 3.0 in Bell Labs in 1991 and strongly advocated the use of these templates, I recommend that you do not use templates in C++/cli.

Under. NET, the static nature of the C + + template instantiation makes it impossible to become a "first-class citizen" of the C++/CLI. In language design, we say that the main language entities should have a "first-class citizen" status. In the case of Int: the 1870s, the motion to establish an abstract data type attempts to provide a mechanism by which the user-defined type can approach the "first citizen" identity of the original language type (for example, Integer). Therefore, it is always a reasonable method to compare the "first-class citizen" and "second-class citizen" of the language. If we compare generic objects and template objects under the. NET Framework, we find generics to be "first-class citizens", and templates are not only ranked back, but are ranked the last, so they are no longer your best choice.

The problem is that the template is a local object for the assembly in which it resides. This is because the assembly type is not simply identified by its name, but by its location. Thus, the two objects of the mytemplate<int> passed between the assemblies in the method are marked as type errors. Therefore, a template cannot be part of a public interface of a type. In addition, templates do not have language interoperability.

Generics are tightly integrated in. NET because the underlying intermediate language is extended to support generics. In addition, the runtime can automate the instantiation of generics on demand as needed. In the native compilation model, files are compiled separately, only linked together at run time. The problem has not been resolved in C + + because of the characteristics of the native compilation model.

Generally speaking,. NET solves three large-scale programming problems that cannot be solved by the native compilation model in C + +: The initialization order of complex global objects (that is, when objects are used and initialized separately in different files, make sure that the object is constructed before the object is first used), The management of dynamic heap allocation memory and the on-demand instantiation of parameterized types. Each of these issues represents a language layer in the actual domain solution that is not related to complexity. Under. NET, these problems no longer exist.

Because TQL relies heavily on templates (especially on STL), the problem with templates and generics is the focus of this column. There are three major problems to be solved, and they are all very painful because we don't want to do them.

First of all, my implementation uses the STL Vector class. Although the STL is currently unavailable under C++/CLI, the. NET Framework provides an equivalent generic collection type:list<t>. Then I just replace that class in the declaration. However, I have to manually change the usage of each object because the two sets of operations are not the same. (In addition, I can consider writing my own Vector class one-to-one mapping.) I'll consider using this method for the associated container of the STL collection later. For example, some Vector declarations are listed below:

typedef pair<short,short> location;
typedef vector<location>　loc;
typedef vector<string>　　text;
typedef pair<text*,loc*>　text_loc;

To replace a Vector with a List, simply open the namespace, change the type name, and then add a trace handle (^), because the list is a reference class:

using namespace System::Collections::Generic;
typedef pair<short,short> location;
typedef List<location>^　 loc;
typedef List<String^>^　　text;
typedef pair<text,loc>　　text_loc;

Second, as you can see in the previous code example, the implementation also uses the C + + standard library pair<> tool. The tool is not available for c++/cli, so I have to do something here. Since this is a very simple implementation, I just need to see if I can clone it. As a result, there is no pure one-to-one mapping between the native platform and the managed platform. And that's no surprise, because when considering how to make the native platform run more efficiently, you need to think of the managed platform as the best choice. (I think the only thing that's not taken into consideration now is whether to provide the same performance.) ）

Finally, my implementation also uses the STL Set class. Unfortunately, there is no equivalent generic collection type, so I have to do some action. My first idea was to implement a one-to-one mapping of its interfaces, but I couldn't intercept heap allocations under the. NET Framework. However, as you will see, practice proves that this is not a good idea. The following is an example of TQL usage for Set:

class Query {
public:
// ...
private:
set<short>*　　　 vec2set( const vector<location>* );
vector<location>　loc;
set<short>　　　　*solution;
};