|
The correct title of this article is Comparison of C# and Visual Basic .NET. The substitution or omission of a # sign is because of technical restrictions.
[edit] Language CompatibilityVisual Basic and Visual Basic .NET are completely different languages and are not backwards-compatible. Visual Basic .NET shares only syntax similarities with Visual Basic. However some features of Visual Basic have been ported over to Visual Basic .NET and are not available to other .NET languages. C# shares syntax similarities with Java. Both C# and Visual Basic .NET share structural similarities with other modern high level languages such as Java and C++. However the differences between Java and .NET are numerous, as can be seen in Comparison of Java and C Sharp. [edit] Runtime multi-language supportOne of the main goals of .NET has been its multi-language support. The intent of the design was that all of the various Microsoft languages should have the same level of access to all OS features, and should be able to expose the same level of power and usability. In implementation, all .NET programming languages share the same runtime engine, uniform Abstract syntax tree, and Common Intermediate Language. Additionally all .NET languages have access to platform features including garbage collection, cross language inheritance, exception handling, and debugging. This allows the same output binary to be produced from any .NET programming language. [edit] Development environmentVisual Studio provides minor differences in the development environment for C# and VB.Net. With each subsequent release of Visual Studio, the differences between development environments for these languages have been reduced. For instance early versions of Visual Studio had poor support for Intellisense in C# compared to Visual Basic .NET, and did not offer background compilation for C#[1]. Currently, the main differences in the development environments are additional features for Visual Basic .NET that originated in VB6, including:
[edit] Background CompilerBackground compilation is a feature of the Visual Studio IDE whereby code is compiled as it is written by the programmer with the purpose of identifying compilation errors without requiring the solution to be built. This feature has been available for Visual Basic since .NET 1.1 and was present in early versions of Visual Studio for Visual Basic .NET. However, background compilation is a relatively new concept for Visual C# and is available with service pack 1 for Visual Studio 2008 Standard Edition and above. A distinct disadvantage for C# is that the Error List panel does not update until the solution is rebuilt. Refactoring large projects is made more difficult by the need to frequently rebuild the solution in order to highlight compilation errors. Such is not the case with Visual Basic because the Error List panel is syncronised with the background compiler. [edit] Language featuresThe bulk of the differences between C# and VB.NET from a technical perspective are syntactic sugar. That is, most of the features are in both languages, but some things are easier to do in one language than another. Many of the differences between the two languages are actually centered around the IDE. [edit] Features of Visual Basic .NET not found in C#
[edit] Features of C# not found in Visual Basic .NET
[edit] Criticisms of Visual Basic .NET not applicable to C#
[edit] Criticisms of C# not applicable to Visual Basic .NET
[edit] Syntax comparisonsVisual Basic .NET terminates a block of code with C# is case sensitive while Visual Basic .NET is not. Thus in C# it is possible to have two variables with the same name, for example [edit] KeywordsKeywords are very different between the two languages.
Some C# keywords such as [edit] Comments
[edit] Conditionals
[edit] Loops
[edit] Comparers
[edit] Adoption and community supportBoth C# and VB.Net have high adoption rates, and very active developer communities and Microsoft fully supports both communities. However, C# does have an advantage in terms of the level of community activity on the Internet. Also, there are more books available for C# than VB.Net, and publishers report that C# books significantly outsell the VB.Net counterparts. Examples of the increased community and industry adoption include:
Counter-examples:
[edit] Other languages[edit] C++/CLI (formerly Managed C++)C++/CLI (a replacement for Managed Extensions for C++) does not have the adoption rate of C# or VB.NET, but does have a significant following. C++/CLI syntactically, stylistically, and culturally is closest to C#. However, C++/CLI stays closer to its C++ roots than C# does. C++/CLI directly supports pointers, destructors, and other unsafe program concepts which are not supported or limited in the other languages. It allows the direct use of both .NET code and standard C++ code. C++/CLI is used for porting native/legacy C++ applications into the .NET framework, or cases where the programmer wants to take more control of the code; but this control comes at a significant cost of ease of use and readability. Many of the automated tools that come with Visual Studio have reduced functionality when interacting with C++ code. This is because reflection cannot provide as much information about the code as it can for C# and VB.net [edit] J#J# runs a distant fourth in terms of adoption. J# is a language primarily designed to ease the transition of Java applications to the .NET framework; it allows developers to leave much of their Java or J++ code unchanged while still running it in the .NET framework, thus allowing them to migrate small pieces of it into another .NET language, such as C#, individually. J# does not receive the same level of updates as the other languages, and does not have the same level of community support. For example, Visual Studio 2005 Team System supports automatic generation of Unit Tests in C#, VB.Net, and C++, but excludes J#. J# has been discontinued and is not included with Visual Studio 2008. [edit] Additional .NET languages[edit] CILAll .NET languages compile down to Common Intermediate Language (CIL), which contains rich metadata and is functionally and logically equivalent to the original .NET language code. For these reasons, while it is possible to code directly in CIL, it is rarely done. The equivalency of CIL to .NET language code permits tools such as .NET Reflector to transform a .NET assembly into source code that is nearly identical to the original source. Code obfuscators are often used to guard against this, and operate by directly modifying the CIL of an assembly in order to make it difficult or impossible to de-compile to a higher level .NET language. [edit] References
[edit] External links
offerte voli | hoteles | precios | voli | die verzeichnis | annuarie web | stop smoking london | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||