Shulou(Shulou.com)06/02 Report--

The main content of this article is to explain "what is the version control of C#". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn "what is C# version control"!

C # version control is a process that constantly improves components in a compatible manner. If code that depends on an earlier version is recompiled to apply to the new version, the new version of the component is compatible with the previous version of the source code. Conversely, if an application that relies on an earlier version can be applied to the new version without recompilation, the new version of the component is binary compatible.

Most languages do not support binary compatibility at all, and many do little to promote source code compatibility. In fact, the defects contained in some languages make the components developed with it invalidate at least some client code that depends on the component in the process of continuous improvement.

For example, consider the case of a base class author who publishes a class named Base. In the * versions, Base does not contain any F methods. A component named Derived derives from Base and introduces F. This Derived class is released to the customer along with the Base class it depends on, and the customer deploys it to many clients and servers.

/ / Author A namespace A {public class Base / / version 1 {}} / / Author B namespace B {class Derived: A.Base {public virtual void F () {System.Console.WriteLine ("Derived.F");}

From then on, version problems began to arise. The author of Base has generated a new version of the F method of his own.

/ / Author A namespace A {public class Base / / version 2 {public virtual void F () {/ / added in version 2 System.Console.WriteLine ("Base.F");}}

This new version of Base should be compatible with the original version in both source and binary terms. If simply adding a new method creates compatibility issues, the base class may never be improved. Unfortunately, the new F in Base makes the meaning of the F of Derived unclear. Does Derived refer to the F that rewrites Base? This seems unlikely, because when Derived was compiled, Base did not have F! In addition, if the F of Derived does override the F of Base, it must comply with the agreement specified by Base (which was not specified at the time of writing Derived)! In some cases, this is impossible. For example, the F of Base might require its override to always call the base method. It is impossible for Derived's F to abide by such an agreement.

C # solves the issue of this version by requiring developers to clearly declare their intentions. In the original code example, the code is clear because Base doesn't even have an F. Obviously, since there is no base method named F, Derived's F is a new method rather than a rewrite of the base method.

If Base adds F and releases a new version, it is still clear what "F of Derived" is in the binary version of Derived: it has nothing to do with rewriting semantically and should not be regarded as rewriting.

However, when recompiling Derived, its meaning is still unclear: the author of Derived may intend to have its F rewrite the F of Base or hide it. Due to ambiguity of intent, the compiler generates a warning and by default causes the F of Derived to hide the F of Base. This compilation process creates semantic ambiguity (compared to before recompiling Derived). The generated warning alerts the author of Derived that there is an F method in Base.

At this point, I believe you have a deeper understanding of "what is the version control of C#". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.