Viusal Studio2005 greatly enriched its library, which can be said to be behind the research of the Wrecker and accelerator, for this, I think most people think so. It brings a lot of tools and new functional functions that make life more enjoyable and simpler for developers. But for me, all of this is so pale compared to the changes that visual Studio2005 have made in C + +. In this article, I highlight the changes that will be brought to C + + by the upcoming release of Viusal Studio2005 to users.
One, say good-bye to underline
Visual Studio.NET 2002 introduces extensible hosting in C + +, which leads to keywords that start with a double underline, such as __gc and __property. Over the years since this release, I've written a lot of code with double underlines, I have to admit that I never liked it, and I fully understand what the real reason is: Double underline the keyword is extended specifically to differentiate the compiler's standard compilation Rules, in theory, you can fully use the extensible hosting, Compile it using a different compiler, which ignores all the double underline keywords.
Solution: Microsoft has found a solution to change the language rather than replace it. But this compromise brings the following results:
1, the developer found that the syntax is not natural and looks very uncomfortable.
2, not to do their best.
For example, the following is an example of a managed C + + declaration property:
Public __gc class Foo
{
Hundreds of lines of code
__property string* Get_text ();
Hundreds of lines of code
__property void Set_text (string*);
Hundreds of lines of code
}; |
I believe that programmers with good programming habits will use get and set close to each other, and then declare all the variables below that need to be used. But the language does not, however, provide enclosed parentheses to define the structure to allow you to declare "this is a property as a unit". So when it runs it appears unnatural and with others. NET language is also out of tune.
What can you do with this? The only way is to combine C + + with the CLI naturally, and vice versa is to really change C + +. If you do, a natural perfect language will bring you great freedom, and you will never need to double underline when you program.
Ii. Life cycle and scope
I really like to destroy objects explicitly. In fact, I also like the garbage collector very much. Maybe I have to say more, in fact, although they are everywhere, and for me to need, but if I am creating objects that only manipulate memory, I would be very happy if I did not need to release the content after use. But memory management is so weak that when my objects occupy unmanaged resources, such as a database connection, a file object, or a similar object, I need to control myself. I need to make sure it dies when it's not needed. The dispose pattern attempts to deal with these situations, but it is not a conscious act. Enclosing parentheses may be a good way to solve the problem.
In normal unmanaged C + +, the following code illustrates the work you have to do:
This is a code fragment
{
Try
{
foo* f=new Foo (/* params *);
All kinds of code, some of which might throw exceptions
Delete F;
}
catch (/* something * *)
{
Delete F;
Whatever else, or rethrow;
}
} |
It's so easy to create objects on the heap:
This is a code fragment
{
Foo F;
All kinds of code, some of which might throw exceptions
} |
When the variable F goes out of scope, whether it is due to an exception or not, it automatically dies, which is very natural and pleasing and satisfying.
When this object is on the managed heap, you do not need to delete it and it will be purged by the garbage collector. However, if it occupies a managed resource, you may want to clear it by using the Dispose () method, and C # provides a using construct for doing so, but it is still not as simple as our heap example.
In a new version of the language (formerly called C++/CLI), you can create it without relying on the kind of object you can create on the heap, and it can be explicitly destroyed after it has gone beyond scope. If you want, you can also create on the managed heap, depending on your choice.
This change brings other consequences. The most far-reaching result is that you can easily put any object into a template set or as a member variable of another class. Instead of just allocating it on the heap and waiting for the garbage processor to handle it, you can use the power of C + + to manage the lifetime of the object.
Iii. Deconstruction and termination
What happens when you write a garbage collection object that can be used in another language? Have you written a destructor for this object? When you are using C + +, you can create objects on the heap, and the destructor of the object will run automatically when the scope is exceeded. What happens when C # or VB applications (which cannot create garbage collection objects on the heap) Use this object? This situation is handled in real time in an ingenious way. It converts the destructor of an object to the Dispose () method, so that the C++/cli object that owns the destructor can be used arbitrarily.
If you write a class with the Dispose () method in C # or VB, you may have written a termination function, and there is a very simple syntax for the c++/cli of the End function. Just as the destructor of the Foo object is called ~foo (), the End function of the Foo object is called! Foo (), both of which remind you that they are opposite to the constructor.
When an object is created on the managed heap, the terminating function begins to run but is never processed (because the level of the execution of the dispose is higher than the terminating function). In a sense, it is a protective net that convinces you that an object can release the unmanaged resources it occupies. Even the developer who uses the object forgets to process it.
Iv. Pointers and handles
A major limitation for extended managed C + + is that the C + + language does not change, and two different things use the same symbol. The Meaning of "*" depends on the context of the code, try to look at the downlink code:
Where is the Foo object created? Will memory be automatically erased? Can you use the following algorithm for pointers, as in the following code:
The answer depends on whether Foo uses the __gc keyword declaration, and if it is a garbage collection object, it can only be created on the managed heap, not on the local heap, not on the stack. On the other hand, if the __gc keyword declaration is not used, this line of code allocates memory to the object on the local heap, and you must remember to use "delete" to release it.
Once the compiler's author has the freedom to modify the language, as C++/CLI has already done, you don't have to worry about where the class object comes from and where it exists. You can tell by the different grammar that the object it should exist in.
This is called a handle, and at first the vast majority of C + + development groups refer to the symbol "caret or hat", which is now called a hat. Like a pointer, you are freed from the processing of * or-> symbols. Most of the impact of this change is in your mind, you can judge the life of the object by looking at the declaration of the instance, without returning to the declaration of the View class.
When it comes to class declarations, __gc and __nogc no longer exist, in their place are some of the more "cool", with the space of the keyword, with the space of the keyword, although it appears to be two words, but actually contains a space word.
For example:
Ref class R
{
Private
int m_a;
Public
R (int a): M_a (a) {}
}; |
You may think that "ref" is a new keyword in c++/cli, but it is not, "ref class" is a keyword, and some of the other similar keywords are: "value class", "Interface Class" and "Enum class". Since almost every C + + program previously written contains a variable called "Value", I'm very glad it didn't turn into a keyword.
A ref class is a managed class, a class that lives on the managed heap and is managed by the garbage collector. As I said earlier, you can create an instance on the stack, and the compiler will manage the object with a hidden, dexterous pointer.
Five, attributes
The attributes of C + + are very large, because I am beginning to explain the embarrassment of the properties in managed C + +, so let's end with a concise version of C++/CLI.
Ref class R
{
Private
int m_size;
Public
property int Size
{
int get () {return m_size;}
void set (int val) {m_size = val;}
}
};
R R;
R.size = 42; |
Whether the attribute is a keyword is, in a sense, a positional keyword, so you can call a variable or function without conflict as a property, just like the code above, which has a special meaning in the definition of a class. Now that the C++/CLI language supports defining attributes as a separate unit, I like the new way more than ever, I'm sure you are.
