Reposted (Tianji Forum): Code Surgery - C # and VB
Nowadays, the popular program "Surge" is now a way to make the operating interface look, and the procedure is of course the original program. The transplantation of the code can also be referred to as a "skin skin", the content is not changed, but it has become another language. This article describes how popular C # and VB.NETs are technically transplanted from today's hottest C #NET. It is reasonable that there is no need to transplant in these two languages, because the code they generate can be fully universal. But if a project is basically written by VB, it takes a little existing C # process, which is not a high efficiency. Even learning C # or VB, learn the transplant between them can double the existing code (such as the fun Donkey.net only VB version). Some people have compared these two languages, and the conclusion that they have been very similar. But even if the VB beginner sees, such as (button) sender .Text = "Start"; the syntax, which does not know how to transplant to VB, and C # beginners see Handles Button1.Click et al. Will also I feel headache in transplantation. Let's take a look at the parts of their most difficult portation: 1, Option statement. The VB's OPTION statement can open or close variable declaration checks and type conversion checks. Especially after the Option Strict is turned off, VB becomes a weak type of language, and many types of conversions are automatically, and countless errors are generated in the transplantation to C #. Therefore, if you want to transplant the VB program with an OPTION STRICT OFF statement to C #, it is best to open the option strict in the VB, then turn all types of conversion error into a strong type conversion, and then transplant. 2, type conversion. VB provides a lot of type conversion function type operators, such as CINT (), CSNG (), CSTR (), etc., only (int), (float), (string) in C #. However, if it is not a standard type, as the C # statement below: (System.Button) .Text = "Start"; you should use the VB's function type operator CType. The correct migration method of the above code is: ctype (sender, system.button) .Text = "Start" Don't use some people recommended, turn the option strict, then use the later binding to call the Sender object, this Fundamentally does not meet the requirements of programs that cannot be changed. 3, modifiers and attribute labels. The modifiers of VB and C # are completely equal, but spelling is often different, bringing a lot of trouble to transplant, especially the keywords that represent the same meaning are completely different from the literal understanding.
Below are given VB and C # keywords corresponding to: VB C # VB C # Inherits: Implements: MustInherit abstract NotInheritable sealed Overridable virtual NotOverridable sealed MustOverride abstract Overrides override [Overloads] No Shadows new Shared static Public public Protected protected Friend internal Protected Friend protected Internal Private Private Static uses other methods BYVAL None Byref Ref Optional None Paramarray Params Unable to implement unsafe Unable to implement Fixed It can be seen that the keywords of VB are relatively long, and it is more stringent than C #. When transferring from C # to VB, pay attention to which VBs have no keywords, and the C # notble is the same, spelling different keywords (such as Mustoverride and Mustinherit) in VB. Some keywords are like Unsafe, if C # uses them, will not be ported to VB. Fortunately, these keywords are not commonly used in business applications. Attribute tags are very similar in these two languages, there should be no difficulty on transplantation, just know that in square brackets [] in square brackets [], in VB is used in a vb number <>. Also, if you want to deliver parameters with name, C # directly use = number, and VB uses: = (colon, and equal sign). 4, delegate type. The delegation type is a safe function pointer type. In C #, it is difficult to distinguish whether the function pointer is working or the function itself is working because their syntax is the same. When you want to copy a delegated type of variable, you can wait directly, such as: public delegate Void Functype (Object E) ... func = new functype (this.samplefunction1); // Call Func ( Something); // For another function func = this.samplefunction2 However, the delegated type is like a general object, and there is a method, and the function itself is significantly different.
You can't assign the name of the process directly to a delegated type object, but you must use the Addressof operator. The following example is the VB version of the above C # program, pay attention to those implementation of different places: public delegate subunctype (Byval e as Object) ... DIM FUNC AS FUNCTYPE FUNC = New functype (addressof me.samplefunc1) 'call func.invoke (Something)' Turn to another function func = addressof me.samplefunction2 5, event processing. This is one of the two largest differences. VB is inherited with a powerful event processing mechanism for previous versions, and many grammar is more flexible than C #. Ok, no matter what, they can be transplanted with each other. For event definition, a delegate two languages are added to an event type attributes, such as: [C #] public delegate void MyEventHandler (Object sender, EventArgs e); public event MyEventHandler MyEvent; [Visual Basic] Public Delegate Sub MyEventHandler (ByVal sender As Object, BYVAL E AS Eventargs) Public Event MyEvent As MyEventHandler VB also supports another more compact definition method, only one statement: PUBLIC EVENT MyEvent (Byval EVENTARGS) When transplant, parameters Partially separated, becoming a delegate type, and then define an event according to a normal method. With regard to the event response, C # is the same as the language such as Delphi, is a dynamic binding event process, its syntax is similar to the following: internal myclass myobj; ... myobj = new myclass (); ... myobj.myevent = this.myobj_myevent ... protected void myobj_myevent (Object sender, evenetargs e) {// statement} You can see that C # is the use of operator connection event procedures and event properties. Thereafter, it is also possible to use the - = operator to release the event process and the binding of the event attribute. VB does not support operator overload, but still supports this dynamic binding event process, the method is to use the AddHandler and RemoveHandler keywords. As the above black body portion can be transplanted as: addHandler myobj.myevent, addressof me.myobj_myevent unbinded syntax, just the keyword is RemoveHandler. Don't forget that there is an AddressOf keyword in front of the process! Dynamic binding event processes work relatively slow, VB supports a faster static binding event process. Once a static event process is set for an object, it cannot be released, which is generally the case.
The syntax is as follows: 'When you define a variable using the WithEvents keyword Friend WithEvents myobj As MyClass' direct writing event procedures, attention Handles syntax: Protected Sub myobj_MyEvent (ByVal sender As Object, ByVal e As EventArgs) _ Handles myobj.MyEvent' statements End Sub It represents the process of MyObj_myevent only responding to myobj.myevent. If a process should respond to many events, listed them behind Handles, separated by commas, such as Handles Event1, Event2, ... encounter this situation, to see all objects and events behind the handles, will A rewritten to dynamically bound statement: protected subxx (...) Handles myobj1.myevent, myobj2.myevent ==> myobj1.myevent = this.xxx; myobj2.myevent = this.xxx; ... protected Void xxx (...) {} When the event is more than the incident, C # is significantly more trouble. Fortunately, a process responds to a lot of incident, not much (but I have written a process corresponding to 8 events, transplanted So complicated!). In principle, the process of transplanting the static event process as a dynamic event process is not fully complied with the stipulations of the transplant, but I estimate that the principles they achieve will not differ too much, so don't worry. 6, abnormal handling. VB supports two forms of exceptions, ie .NET frameworks and VB's own error numbers. And C # only supports the first one. The programs for VB their own error numbers are hard to be ported to C #, so they should try to use the .NET framework, such as the following VB statement: try 'error code catch when err.number = 52' resolves the error code end This code cannot be transplanted directly into C #, and only replacing the ERR object with an Exception object to obtain exception information, it can be granted smoothly. In addition, VB's WHEN statement brings a very flexible use of the TRY statement. It must be implemented in C # with high skills, which requires a specific problem to analyze. VB supports the exit try statement, you can jump directly from the TRY block or catch block to the Finally block. C # does not provide similar syntax, you can use the following skills: [Visual Basic] Try 'Some statement EXIT TRY FINALLE' Some statement END TRY [C #] Try {// Some statement goto __leave;} finally {// Some statements} __leave: // Don't forget it here! In summary, the feature that cannot be skipped by the Finally block is used, and the EXIT TRY statement is simulated with the GOTO statement. If the VB program is used by the error handling of the VB unique on Error Goto statement, the problem is troublesome. The code may jump up and down in the process, and cannot expect the statement of the statement. This kind of code understands that it will not be transplanted.
