To elaborate on VB. NET (medium)

To elaborate on VB. NET (medium)
(Author: Green Apple Studio compiled March 07, 2001 14:47)

Intermediate languages that are easy to decompile
Whether you use VB, C # or anything else. NET language to write applications VS. NET code is compiled into intermediate language (IL). When the application is running, an instant compiler (jitter) processes the IL code and compiles it into machine language. This means that the. NET runtime may theoretically be created for platforms other than Windows, but there is no official information on similar issues now. One of the drawbacks of the intermediate language is that it is as easy to decompile as the VB5 previous version of VB. This possibility has led many developers to question it in general. NET architecture security.

The CLR affects code both inside and outside the Il hierarchy, and modifications to it will benefit all languages that use the CLR. However, language is concerned only with how the code is interpreted as IL, and the optimization of a particular language can be written according to the syntax of a particular language, which is technically possible. NET languages have very little performance differences. In any case, the blueprint is generally beautiful. For example, the CLR makes VB debugging and monitoring tools equal to the corresponding tools in C #, and it does this because they are the same tool.

The CLR provides not parallel cross-language integration, including the ability to inherit code across languages. All languages that use the CLR share a common type system that makes it easier to develop applications in multiple languages. I don't like to translate the C API declaration into a form that can be used in VB, so I appreciate the benefits of the common type System.

Code that runs in the CLR is called managed code, and the memory used by the managed code is completely controlled by the CLR. Managed code offers a number of benefits, including Cross-language integration, cross-language exception handling, and simplified component interaction models. Visual Basic is limited to work in the way that code is managed, but C # has the ability to jump to unmanaged code (outside the runtime) and to do things like pointer manipulation. This is one of the different situations of VB and C #. How much this ability depends on what you want to do.

The architecture differences created by the CLR are more profound than cross-language integration, shared functionality, and managed code. First, the Visual Studio.NET support structure is not COM. In addition, VB. NET everything, even strings are objects. For these and other reasons, Microsoft has changed the way the support structure handles objects. COM implements a reference counting scheme, which increments the counter each time an object is referenced. When an object reference goes out of scope or is freed, the counter decrements, and the object is terminated when the reference count is reduced to 0 o'clock. Microsoft claims that the overhead of reference counting under the. NET schema is too high to be able to. NET, so it abandons the reference count instead of using garbage collection.

Garbage collection requires a new architecture
The CLR garbage collector primarily monitors the resources of a program, searches for unwanted objects when the available resources reach a defined threshold, and clears those objects when they are found. One of the great benefits of garbage collection is that you no longer need to worry about most ordinary circular references, where the child object references the parent object, and then the parent object references the child object. Under the reference counting scheme, circular references allow two objects to be freed and cleared. However, the garbage collector finds circular references and clears them. This also means that when you release the last reference to an object, you no longer need to clear the object immediately.

One consequence of garbage collection is that you can no longer expect a class of Terminate events to be issued at the right time. In fact, if the thread is blocked, the Terminate event may not be emitted at all. In contrast to the finalization of COM offers, it is called an indeterminate termination. The lack of a definite termination, and the fact that the garbage collector rearranged and compressed memory so that pointers cannot be used, sparked a lively debate in newsgroups. I think these new restrictions may make you hate because you have to rely on certainty to terminate, or you may be indifferent because you do not rely on Terminate events. Garbage collection is not a panacea, and the implementation of weak references still requires some consideration.

Counting from references to garbage collection is just one of the manifestations of the fact that Visual Studio.NET's support structure is not COM. You can use COM objects in vb.net, such as ActiveX servers or ActiveX controls. However, you must access these objects by wrapping them. Any time you hear the term "packaging," you should understand that you are facing a performance loss and that the behavior of the object may be different. If you plan to migrate a project that uses a large number of COM objects, you need to test and plan carefully, and you may need to redesign your application's structure to successfully migrate. To be frank, you have to be prepared to suffer setbacks. Do you remember the process of migrating from VBX to OCX? I remember, as my psychiatrist remembers. I'm going to see him again soon;--)

The language itself changes far beyond the architectural changes. Most of the changes make sense, but I don't think all the changes are the same. Previous versions of VB allow you to do a lot of things in many ways, so that a unified coding standard either does not exist or is difficult to impose. Microsoft has made a lot of changes to VB that is "clear" the language. In many cases, there are several ways you can do one thing. Billy Hollis provides a detailed list of syntax changes, including a list of discarded keywords, but something needs to be repeated here.

First, the default method of passing data to a procedure parameter is changed from a reference (BYREF) to a pass value (ByVal). The main reason for this change is that the reference is much riskier than the value of the pass. The main risk is that the data in the call process may be inadvertently tampered with. You can still pass data by reference, but this change allows you to modify the new default invocation method to use the reference.

The SET statement disappears.
Second, the Set statement disappears. In vb.net if you need to pass an object reference to a variable, all you need is an equal sign, and the object is treated like any other value. This is cool, but there are side effects: The default properties are gone. For example, you can no longer refer to an attribute in this way:

Text1 = "What, me worry?"

Instead, you must explicitly refer to the attribute:

Text1.Text = "What, me worry?"

Maybe at first glance you don't need this change, but you do have to remove the default attributes. For example, suppose you have an object variable called Objfoo, and without the SET statement, the reference set by the following statement creates ambiguity:

Objfoo = Text1

Should this statement be set to the TEXT1 reference, or will the Text1 Text property fill the Objfoo? You can't be sure, the compiler can't. Discarding the SET statement also requires discarding the default property.

There's a change I don't like: You can no longer declare property gets and property set procedures in different scopes. Note that vb.net does not have a Property Let statement: Both objects and values are in property Set. This means that you cannot use a Friend property Let procedure to correspond to a public property get. You may have trouble building a component with VB. Many component developers create the Friend property Set procedures so that their applications can change a value, but provide a public property Get procedure to enable their clients to retrieve the value. I wish I could find a suitable reason for this change, but I can't find it.

Microsoft says it is trying to keep the language clear and modern-most of it doing well-but the scope and other issues are confusing. For example, while ... Wend should have disappeared long ago, because do ... Loop completes the same function. However, Microsoft has not only failed to remove the while ... Wend, and changed it to a while ... End while to find yourself more trouble. How strange!

My least favorite change is that Microsoft has changed the meaning of the data type that you have already used. In. NET, the Integer is now 32 digits, and Long has become 64 bits. I wondered how often developers (including myself) would use the wrong variables. Does that API accept a 16-bit integer or 32-bit? Oh, my God! I want Microsoft to reconsider this decision and use the new variant types, such as Int32 and Long64. Either migrate to VB. NET porting tool is so good that it does not change the memory of the developer. Why would you force us to learn the normal data type again?

Finally, one of the most needed changes is that vb.net introduces the option Strict keyword, which you can use instead of option Explicit. Option Strict ends the evil type Coercion (tm), through which VB is happy to let you assign a value to a string, and then do another operation like a crime. Set Option Strict tells Visual Basic.NET not to do any type coercion for you. Note that vb.net is not a complete control freak, it allows type downward conversion, but does not allow upward. For example, if you do not use a statement like sngvariable = CSng (dblvariable) for explicit type conversions, you cannot assign a variable declared as single to a variable that is declared Double. Because this has the risk of losing data. However, you can assign a variable declared as Double to a variable that is declared as single without using an explicit type conversion, because there is no risk of losing data. Using Option Strict can help developers reduce many types of errors, including those that are difficult to debug. But there is an additional flaw: After using Option Strict in the project, it cannot be edited.

<<<<< prev: Overview, VB has acquired the ability to inherit, everything is the object, the danger of free thread
>>>>> Next: Forms and new IDE faces, creating a compiled server-side code, the right path