Changes in C + + in Visual Studio 2005

The next generation of Visual Studio versions (formerly Whidbey, now Visual Studio 2005) provide richer and improved library files and without much pressure behind the behind-the-scenes streamlining and acceleration, and its large number of matching tools and new features will make the developer's development process much simpler and more interesting, For me, these are somewhat paler than Visual Studio 2005 's handling of C + +, where I'll talk about the changes in C + + in next-generation Visual Studio.

Just follow the underline.

In Visual Studio. NET introduces the processing of C + + extensions, which are keywords starting with two underscores, such as __gc and __ property. Since the last release, I've written a lot of code with double underline features, I do not like this, I understand the specific reason is: with two underlined keywords as a special extension so that they will not be confused with the standard compiler, you can fully manage the extension can be compiled with other compilers, it ignores __ keywords.

This is a workaround: Microsoft has found a way to change the programming language, but there are some results:

• Developers find grammar not natural

• cannot be fully adopted

As an example, the appropriate C + + processing method: Program code:
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
}; Programmers with good habits place the get and put on the right side of each extension, placing potential variables next to each other, but the programming language does not require you to do so. It provides an environment-free, bounding structure that allows you to understand that as a unit is correct, so it is unnatural with other Visual Studio. NET language is not the same. But how do you deal with this problem, the only way to do this is to convert C + + into the CLR and vice versa. If you want to do that, you can have enough freedom to get the best of natural language and you can cancel a lot of double underlined keywords.

Life Time and scope

I like to determine the parsing, actually I also like the collection of fragments, I can also cite more, they have their own role and I need them, if I only in the memory of the construction of an object, I want to clear it before I clean it,

So memory management is very complex. However, if your object contains a unmanaged source file such as a database link, an open file, or similar I want to get a control. I want to know that it is going to leave as soon as possible, in this mode to deal with, but it is not direct, simple intimate support is the best way.

Here's what you do with the original C + +: Program code:

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;
}
}

If you build objects on the stack, the life cycle is simple

Program code:

This is a code fragment
{
Foo F;
All kinds of code, some of which might throw exceptions
}

When F exceeds the range, whether or not it is accidental it will be cleared away this is natural.

When the object is in the management heap, you can't delete it, it will be cleared by the fragment collection, if you want to clear the object that manages the source file, you can call the Dispose () function, although C # provides the valid structure for it, but it is still not as simple as the stack.

In a new generation of languages (formerly C++/CLI), where you build objects without relying on the kind of objects you build, you can manage objects in the stack, it has a definite parsing, but it will be cleared when it crosses the line, and if you want you can build objects in the management heap.

This change leads to other results, the most profound is that you can put different objects in the touchpad or you can see it as a member of other classes, you can get the full C + + life cycle, rather than just assign it to the appropriate heap, and then wait for the debris collection to handle it.

Parse and Finalize

When you write a fragment collection object for another language, do you write a parse function for it? When you use C + +, you can construct the object on the stack, and the parse function will run when it crosses the line, what happens when other C # or VB programs call this object, the runtime only handles it from a simple way, it is resolved with Dispose (), and any c++/ CLI objects have an analytic function that can be invoked arbitrarily.

If you have the class of Dispose () in C # or VB, you may have written a conclusion, C++/CLI also has the simple grammar as the conclusion, just like Foo's parsing is ~foo,foo's verdict! Foo (~ is the not,! of bits is logical not, they are all reminders are opposed to constructors),

The finalizer will run when it is established in the management heap without being invoked, convinced that the unmanaged source files it contains are purged, even if other calling functions have forgotten to parse them.

Pointers and handles

In C + + management, the main limitations of C + + have not changed, the same symbols and syntax for complete things, * meaning depends on the other location in your code information, you can try the following code: foo* PF = new Foo ();
Where will the Foo object be built? Is that piece of memory cleared? Can I do the arithmetic on the pointer like the following:

pf++;

The answer depends on whether Foo is declared with the __gc keyword, and if it is a fragment collection object, it can only be built on the management heap, not in the heap and stack, on the other hand, if you do not use the __gc declaration to allocate memory to it in this heap, you must remember to clear it.

If the compiler has the freedom to change the language, as it happens on c++/cli, what type of class it can ignore where to live, you can show where it survives in a different syntax:

foo^ HF = gcnew Foo ();
This is called a handle, and many C + + teams seem to be labeled with the ^ symbol, and you can use * and-> to unlock the handle's reference, and you can get a life-time declaration from the declaration of the instance rather than back from the declaration of the class. For example:

Program code:

Ref class R
{
Private
int m_a;
Public
R (int a): M_a (a) {}
};

You may think ref is c++/cli new keyword, but it is not, "ref class" is the keyword, you can have the variable is ref without causing confusion, the other keywords are "value class", "Interface Class", "Enum class" , almost all of the C + + programs in the past will have the value variable, and I'm glad that value didn't turn into a keyword.

Ref class is a management class, a class that is designed as a survival management team and managed by a fragmented collection, and you can declare an instance in the stack, as I indicated earlier, and the compiler will help you find it, plus an invisible smart pointer.

Characteristics

There are a lot of changes in C + + features because I started with the awkward features of C + +, so I'm shutting down the relatively similar C + +

Program code:
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;

is the property a keyword? It's a bit like, it's a positional keyword, so you can have property variables and functions without causing confusion, it only has a special meaning in the class definition, now there is a separate unit in the C++/CLI to provide the definition of the feature, I'm sure you are.