CLR defines some modifiers used for access and access, which function beyond the equivalent of class member functions and variables in local C ++ (such as public, private, and protected, you can even define the accessibility of namespaces or nested types. To enable C ++/CLI to achieve its goal as a low-level language, in addition to accessibility, it also provides more control than other high-level languages on the CLR platform.
The differences between local C ++ accessibility and the accessibility defined in CLR are as follows: the local C ++ access indicator is usually used to restrict the members of the alias class from other codes in the same program. the type defined by CLR and the accessibility of the members are not only for other codes in the same assembly, the Code also references it from other programs.
A namespace or non-nested type, such as the class or delegate type, can specify visibility outside the Assembly by adding the public or private keyword before the type definition.
| Public ref class ReferenceType {}; |
If visibility is explicitly specified, the type is assumed to be private for the Assembly ).
The access indicators of class members are also extended to allow two keywords to be used together to specify access from both the internal and external. In these two keywords, more users are limited to define the access from outside the Assembly, while the other defines the access within the Assembly. If only one keyword is used, it applies to both internal and external access. This design concept provides great flexibility for the definition type and the accessibility of class members. The following is an example:
Public ref class ReferenceType
{
Public:
// Both the internal and external components of the Assembly can be viewed.
Private public:
// Only visible to the Assembly
Protected public:
// Visible to all code in the Assembly; visible to external inheritance types
}; |
Attribute
Except for the nested type, the CLR type can only contain methods and fields. To allow programmers to clearly express the meaning of code, metadata can be used to indicate that a specific method will be treated as an attribute by the programming language. Strictly speaking, a CLR attribute is a member of its containing Class. However, the attribute is not assigned to a bucket, and it is just a name reference for the respective methods of the attribute, different compilers generate the required metadata when encountering the syntax related to attributes in the source code. That is to say, type users can use Attribute syntax in their languages to access get and set methods for implementing attributes. Compared with local C ++, C # has the best support for attributes.
Public string Name
{
Get
{
Return m_name;
}
Set
{
M_name = value;
}
} |
C # The Compiler generates the corresponding get_Name and set_Name methods, and also contains the necessary metadata to indicate their contact. In hosting C ++, the keyword _ property is introduced to indicate a method for implementing attributes in semantics.
_ Property String * get_Name ()
{
Return m_value;
}
_ Property String * set_Name (String * value)
{
M_value = value;
} |
Obviously, this is not an ideal situation. Not only does this "ugly" _ property keyword need to be used, but there is nothing to clearly indicate the actual connection between the two member functions, this leads to unpredictable bugs during maintenance. C ++/CLI is much more concise in the design of attributes, closer to the design of C #, and you will find that this is more powerful.
Property String ^ Name
{
String ^ get ()
{
Return m_value;
}
Void set (String ^ value)
{
M_value = value;
}
} |
This is a big improvement. The compiler is responsible for generating the get_Name and set_Name methods and the necessary metadata declared in this attribute. Better yet, this attribute value can be read-only to the outside of the Assembly, but writable to the inside of the Assembly. You can also use the access indicator in the curly brackets following the property name to achieve this purpose.
Property String ^ Name
{
Public:
String ^ get ();
Private public:
Void set (String ^ );
} |
The last thing that is irrelevant is that there is no need to perform special processing on the get and set attributes. You can also use simple notation.
Again, the compiler generates the get_Name and set_Name methods. However, a default implementation supported by the private String ^ member variable is also provided. The advantage is that you can replace the simple attributes with some other implementations at some time point in the future without damaging the class interfaces.
Proxy
The function pointer in local C ++ provides a mechanism for asynchronous code execution. You can store a function pointer and call it in time when necessary, this is usually used to separate an algorithm from the implementation code, such as comparing objects in a search. In addition, it can also be called in different threads to implement real asynchronous programming. The following is a simple example of a ThreadPool class. You can arrange a series of function pointers and execute them in the worker thread.
Class ThreadPool
{
Public:
Template <typename T>
Static void QueueUserWorkItem (void (T: * function) (), T * object)
{
Typedef std: pair <void (T: *) (), T *> CallbackType;
Std: auto_ptr <CallbackType> p (new CallbackType (function, object ));
If (: QueueUserWorkItem (ThreadProc <T>,
P. get (),
WT_EXECUTEDEFAULT ))
{
// ThreadProc is responsible for deleting pair.
P. release ();
}
Else
{
AtlThrowLastWin32 ();
}
}
Private:
Template <typename T>
Static dword winapi ThreadProc (PVOID context)
{
Typedef std: pair <void (T: *) (), T *> CallbackType;
Std: auto_ptr <CallbackType> p (static_cast <CallbackType *> (context ));
(P-> second-> * p-> first )();
Return 0;
}
ThreadPool ();
}; |
Using a thread pool in C ++ is simple and natural.
Class Service
{
Public:
Void AsyncRun ()
{
ThreadPool: QueueUserWorkItem (Run, this );
}
Void Run ()
{
// Other code
}
} |
Obviously, the ThreadPool class is very limited. It can only accept specific function pointers. This is only the limitation of the example itself, not the C ++ itself.
When a C ++ programmer wants to implement or obtain rich library functions for asynchronous programming, the built-in support for CLR comes. The "proxy" is very similar to the function pointer, except for the type of the target and method (it cannot determine whether a proxy can be bound to a given method). As long as the type matches, the method can be proxy and called later. This is similar to the preceding example of using the C ++ template to accept any class member function. Of course, the proxy also provides more and more useful indirect function calling mechanisms. The following is an example of defining a proxy type in C ++/CLI:
| Delegate void Function (); |
The use of proxy is also very straightforward.
Ref struct ReferenceType
{
Void InstanceMethod (){}
Static void StaticMethod (){}
};
// Create a proxy and bind it to the member function instance
Function ^ f = gcnew Function (gcnew ReferenceType, ReferenceType: InstanceMethod );
// You can also bind it to a static member function and combine several proxies to form a proxy chain.
F + = gcnew Function (ReferenceType: StaticMethod );
// Call a function
F (); |
Conclusion
With regard to C ++/CLI, the last few days cannot be completed. The new language design provides unprecedented power and unique "elegant" syntax, in addition, C ++ can be fully used to compile a wide range of functions without sacrificing simplicity, programming efficiency, and execution efficiency.. NET application.
