The CLR defines some cosmetic elements for access and access that extend beyond the equivalent of class member functions and variables in local C + + (such as public, private, protected), and can even define the accessibility of namespaces or nested types. In order for C++/CLI to achieve the goal of being a low-level language, it provides more control over other CLR platform advanced languages than access.
Local C + + accessibility is compared to the accessibility defined in the CLR, the biggest difference is that local C + + Access indicators are typically used to restrict access to class members from other code in the same program, while CLR-defined types and members are accessible, not just for other code in the same assembly. It also refers to code that references it from another assembly.
A namespace, or not a nested type, such as class or delegate type, that specifies the visibility outside the assembly by adding public or private keywords before the type definition.
Public ref class Referencetype {};
If the visibility is explicitly specified, the type is assumed to be a private type for the assembly (private).
The access indicators for class members are also extended to allow two of keywords to be used together to specify access from both internal and external sources. In these two keywords, more restrictive one define access from outside the assembly, while the other defines the accessibility within the assembly. If you use only one keyword, it will work on both internal and external accessibility. This design idea provides a great deal of flexibility in defining the types and accessibility of class members, and here is an example:
Public ref class Referencetype
{
Public
Both internal and external to the assembly are visible
Private public:
Visible only within an assembly
Protected public:
Visible to all code within the Assembly;
};
Property
In addition to nested types, CLR types can contain only methods and fields. In order for programmers to express their code more clearly, you can use metadata to indicate that a particular method will be treated as a property by the programming language. Strictly speaking, a CLR property is a member of its containing class, however, the property has no allocated storage space, it is just a named reference to the respective method of implementing the property, and different compilers, when they encounter the syntax for the property in the source code, will generate their own required metadata. This means that the user of the type can use the property syntax in their language to access the get and set methods of the implementation property. C # has the best support for attributes compared to local C + +.
public string Name
{
Get
{
return m_name;
}
Set
{
M_name = value;
}
}
The C # compiler generates the corresponding Get_name and Set_name methods, and also contains the necessary metadata to indicate their connection. In managed C + +, a keyword __property is introduced to indicate a method for semantically implementing a property.
__property string* get_name ()
{
return m_value;
}
__property string* set_name (string* value)
{
M_value = value;
}
Obviously, this is not the ideal situation, not only to use this "ugly" __property keyword, but nothing here clearly indicates the actual connection of these two member functions, which can lead to elusive bugs during maintenance. C++/CLI is 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 very big improvement, and the compiler is responsible for generating the get_name and Set_name methods and the necessary metadata declared in this property. Better still, this property value can be read-only on the outside of the Assembly, and be writable within the assembly, or by using an access indicator in curly braces immediately following the property name.
Property string^ Name
{
Public
string^ get ();
Private public:
void set (string^);
}
The last thing that matters is that there is no need for special treatment of Get and set in the attribute, or a shorthand notation can be used.
Property string^ Name;
Again, the compiler generates the Get_name and Set_name methods, but this time, it also provides a default implementation supported by the private String ^ member variable. The advantage is that you can replace the simple attributes here with some other implementation at some point in the future without breaking the interface of the class.
Agent
function pointers in local C + + provide a mechanism for executing code asynchronously, you can store a function pointer, and call it in time when you need it later, which is often used to separate an algorithm from the implementation code, such as comparing objects in a search. In addition, it can be invoked in different threads to achieve true asynchronous programming. The following is a simple example of a ThreadPool class that allows you to arrange a series of function pointers and execute them on worker threads.
Class ThreadPool
{
Public
Template <typename t>
static void QueueUserWorkItem (void (T::* function) (), t* object
{
typedef std::p air<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::p air<void (T::*) (), t*> Callbacktype;
Std::auto_ptr<callbacktype> p (static_cast<callbacktype*> (context));
(P->second->*p->first) ();
return 0;
}
ThreadPool ();
};
The use of thread pools 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 restricted, it can only accept specific function pointers, which is only the example itself, not the limitations of C + + itself.
When a C + + programmer wants to implement or get a rich library function for asynchronous programming, it comes with the CLR with this built-in support. The "Agent" is very similar to the function pointer, in addition to the type of target and method to which it belongs (it does not determine whether an agent can be bound to a given method), the method can be represented as long as the type matches, and later invoked to compare the example above using C + + templates to allow acceptance of any class member function. This is similar in ideology. Of course, the proxy also provides more and extremely useful mechanisms for indirect function calls, and here is an example of defining a proxy type in C++/CLI:
delegate void Function ();
The use of proxies is also very straightforward.
ref struct REFERENCETYPE
{
void Instancemethod () {}
static void Staticmethod () {}
};
To create an agent and bind to an instance of a member function
function^ f = gcnew Function (gcnew referencetype, Referencetype::instancemethod);
can also bind to static member functions, and combine several agents to form a broker chain
F + + gcnew Function (Referencetype::staticmethod);
Call function
f ();
Conclusion
As for the C++/CLI, it is said that the last few days, the new language design provides unprecedented power and unique "elegant" grammar, and can be done without sacrificing simplicity, programming efficiency, execution efficiency, the full use of C + + to write rich. NET application.
