Code change skin (1) - 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 they are most difficult to transplant:
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, such as the C # statement below:
(System.Button) Sender .Text = "Start";
It is to be implemented using 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, and then call the Sender object with later binding, this is not in line with the programs that cannot change the requirements.
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. The keywords corresponding to VB and C # are given below:
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 achieve ByVal free ByRef ref use other methods 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 be directly equal to a function, such as:
Public Delegate Void Functype (Object E)
...
Functype func;
Func = new functype (this.samplefunction1);
//transfer
Func (Something);
/ / Change to another function
Func = this.samplefunction2
However, in VB, the delegated type is like a general object, with its method, and the function is significantly different. You can't give the name of the process directly to a delegated type, but you must use the Addressof operator. The following example is the VB version of the above C # program, pay attention to those achieved different places:
Public Delegate Sub Functype (Byval E as Object)
...
DIM FUNC AS FUNCTYPE
Func = new functype (addressof me.samplefunc1)
' transfer
Func.invoke (Something)
'Change 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 definitions, both languages are a delegate type plus an event property, such as:
[C #]
Public Delegate Void MyEventHandler (Object Sender, Eventargs E);
Public evenet myeventhandler myevent;
[Visual Basic]
Public Delegate Sub MyEventHandler (Byval E 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 E AS Object, ByVal E as Eventargs)
When transplantation, you should separate the parameters part and become a delegate type, and then define an event according to a normal method.
About event response, C # is the same as language such as Delphi, is a dynamic binding event process, its syntax is similar to:
INTERNAL MyClass myobj;
...
Myobj = new myclass (); ...
MYOBJ.MYEVENT = this.myobj_myevent;
...
Protected void myobj_myevent (Object Sender, Eventargs E)
{
// statement
}
It can be seen 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_MYVENT
The syntax that releases the binding is similar to this, 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:
'Use the witHevents key when defining variables
Friend Withevents myobj as aclass
'Direct writing event procedure, pay attention to Handles's grammar:
Protected Sub Myobj_myevent (Byval E AS Object, BYVAL E as Eventargs)
Handles myobj.myevent
'Statement
End Sub
It represents the process of MyObj_myevent only responding to myobj.myevent. If a process is to respond to many events, listed them behind Handles, separated by commas, such as Handles Event1, Event2, ...
In this case, you must see all objects and events behind your handles, and change them into dynamic binding statements by one by one.
Protected Sub xxx (...) Handles myobj1.myevent, myobj2.myevent
==>
Myobj1.myevent = this.xxx;
Myobj2.myevent = this.xxx;
...
protected void xxx (...) {}
When the event is more, C # is significantly more trouble. Fortunately, a process responds to a lot of incidents. There is not much (but I have written a process corresponding to 8 events, transplanted, so trouble!). 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. Programs for VB their own error numbers are hardly ported to C #, so they should try to use the .NET framework, such as the VB statement below:
Try
'Code of error
Catch gen err.number = 52
'Solve the wrong code
END TRY
This code cannot be transplanted directly into C #, only replacing the ERR object with an Exception object to obtain exception information, 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 tips: [Visual Basic]
Try
'Some statement
EXITTY
Finally
'Some statement
END TRY
[C #]
Try
{
// Some statements
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. Overall, all statements are transferred to the TRY block and then handle errors with a CATCH. When you encounter the return statement, you have to Copy code. Anyway, it is not an easy thing, slowly change it.
7, module. VB support module, C # does not support. But there is no relationship, as long as you create an Abstract class in C #, share all members, just like the module. Of course, it is not possible to directly access members in the module as VB, and you need to use the "class name. Member name" usage.
8, interface. C # There is no VB power in the interface (how to make such an important function is not a good one?), VB uses the implementation member of the member and class of the IMPLEMENTS statement, and C # is combined with name. Therefore, VB can then modify the access level and name of the member, and C # can not change the name. When you migrate C # to VB, it is best to directly implement the interface directly, relatively simple. When you transplanted VB into C #, you must change the changed name. I hate the name conflict (I almost don't want to transplant it to C # at this time). Give an example:
[Visual Basic]
Public Class Class1: Implements ImyInterface
Public Sub Dosth () Implements ImyInterface.Method1
End Sub
END CLASS
[C #]
Public Class Class1: ImyInterface
{
Public void method1 ()
{
}
}
9, operator overload. This will encounter VB head pain. Since VB does not support operator overload, then operator must be used to simulate operators. Establish an operation of Establishing PLUS and Minus Method Simulation and -. Of course, there are still many situations (for example, an Explicit and Implicit statement) really have no way, so you have to be planted. The operator overload is a very good function, which makes a lot of operations simply, if VB supports it, it is really a perfect language.
Ok, if you want the most trouble, you have finished, the rest is simple Copy. Although some places have not been clear, they basically clarify the difference between the two languages (a look, there are quite a lot), no need to transplant the project, understand these contents mainly in order to use double utilization Existing code, I hope this article is useful to you. Because of the poor level, if there is any mistake, please prawn correctly, the younger brother will be touched.
