Re: vb.net vs c#.net, the SQL
From: Greg Young (greg.young_at_planetbeach.com)
Date: 06/22/04
- Next message: Moheb: "AppSettings"
- Previous message: z_learning_tester: "Re: public vs private access, quick question-"
- In reply to: John Wood: "Re: vb.net vs c#.net, the SQL"
- Next in thread: Saga: "Re: vb.net vs c#.net, the SQL"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 22 Jun 2004 12:59:43 -0500
I believe that this is one of the most minor things I listed. Although I
have found that v does a better job of doing this (and removing them as it
goes).
"John Wood" <spam@isannoying.com> wrote in message
news:OzGn5UHWEHA.3120@TK2MSFTNGP12.phx.gbl...
> >> VB better supports compilation while you type.If you misspelled keyword
> and move to another line the error will appear in the Task List. <<
>
> I think you'll find C# does this too. That's not really compilation
though,
> more a simple syntax check.
>
> --
> John Wood
> EMail: first name, dot, second name at priorganize.com
>
>
> "Greg Young" <greg.young@planetbeach.com> wrote in message
> news:eNMLeQHWEHA.2840@TK2MSFTNGP11.phx.gbl...
> > There are some fairly big differences although they are not huge.
> >
> > example: VB.NET will not let you reimplement an interface ... C# will
this
> > is important when dealing with serialization of certain classes (namely
> > datatables). There are a ton of other things but here is a partial list.
> >
> > C# has pointer operations
> > VB is case insensitive. In C# MyA and myA are differnt variables
> > VB supportd late binding and optional parameters, C# does not
> > C# doesn't support optional paramters
> > ------------------------------------------------------------
> > VB supports automatic variable conversion between types (you can assign
> Long
> > to Integer without conversion)
> > VB has richer IntelliSense and better automatic formatting
> > VB better supports compilation while you type.If you misspelled keyword
> and
> > move to another line
> > the error will appear in the Task List.
> >
> > ================================================
> > Productivity
> > ============
> > - C# is as equally suited to application program development as VB.NET
> > - Productivity between the two languages is comparable
> > - Execution speed of programs written in both languages is comparable
> > - VB offers improved as-you-type checking, but inferior compile-time
> > checking (relying on runtime checks instead)
> > - Both languages have advanced Intellisense features (resolving case
> > issues in C#) with the VB Intellisense being slightly more advanced
> > for Booleans and Enums
> > - Comparable statements can be up to 266% shorter in C# - with or
> > without Intellisense
> >
> > Ease of use
> > ===========
> > - C# has half the number of reserved words to learn
> > - Both languages have identical class, method, and function names (the
> > Framework)
> > - To be used properly, both languages require knowledge of object
> > orientation, event driven programming, and exception handling
> > - Both languages are not immediately accessible to non-programmers
> >
> > Technology
> > ==========
> > - C# is fully object orientated, ie 'int.Parse(x)' whereas VB uses
> > some legacy non-OO function calls
> > - VB supports as-you-run modifications
> > - C# supports XML commenting
> > - C# is supported by other platforms (Borland C#Builder, and 'Mono' on
> > Linux http://www.go-mono.com)
> >
> > Knowledge-reuse
> > ===============
> > - Knowledge of VB is useful for programming Office and VBScript
> > - Knowledge of C# is useful for programming Javascript, Jscript, PHP,
> > Perl, Java, C and C++ (currently the dominant language for native-code
> > development on both Windows and non-windows platforms)
> >
> >
> > from Marco Bellinaso article
> > What C# has that Vb does not
> > ===========================
> > 1.Unsafe code:
> > with C# you can write blocks of unsafe code, that is,
> > code that can use pointers and directly access memory, use low level
> > system calls and do the sort of things that are not verified by the CLR.
> > Use of this feature should be avoided to limit the possibilities of
> > runtime errors, but it may turn out to be an important feature when
> > writing code for algorithms that must have good performance, or need to
> > interface with the operating system (of course, operating system
> > portability would be lost by doing so).
> >
> > 2. Operator overloading:
> > C# allows the developer to define a custom
> > implementation for many mathematical, unary, binary and comparison
> > operators that a class may support, such as +, -, *, /, true, false, ==,
> > !=, >>, <<, !, ~. For example, say that you have a class Matrix: you
> > can redefine the meaning of the + operator for this class, so that if
> > you have three instances of Matrix - m1, m2 and m3 - you can do m3 = m1
> > + m2;. While this is certainly a very cool feature, you must be aware
> > that if you later use the Matrix class from a VB.NET client, you won't
> > be able to use the overloaded + operator to sum two matrixes, since the
> > operator overloading feature is not part of the CLS. If you're 100% sure
> > that all your code will be in C#, good, you can safely overload the
> > operators and assign them the meaning you want. Otherwise, you should
> > provide instance or static methods such as Add, Subtract etc., so that
> > all the possible operations are accessible to VB.NET too.
> >
> > 3. XML documentation: (Whidbey will have it)
> > in C# code comments can be added in XML-like
> > format--with a /// prefix instead of the usual single-line // comment
> > prefix--within tags such as <summary>, <para>, <returns> and so on. At
> > compile time you can specify to extract all the XML comments and save
> > them to an XML file, so that it will be easy to write a XSL
> > transformation file to create HTML documentation. If you program with
> > Visual Studio .NET, under the Tools menu you find a Build Comment Web
> > Pages item, that generates the help files without requiring you to
> > manually write a XSL file and leave the IDE. Once the developer gets
> > used to writing their comments between these tags, they will soon
> > realize that they already have good documentation of their classes,
> > separated from the source code and thus easier to read and consult. This
> > powerful and helpful feature unfortunately is not present in VB.NET.
> > Hopefully it will be added in a future release, but I'm pretty sure
> > someone will soon provide an add-in to support this feature in any
> > language, if it doesn't already exist.
> >
> > 4. Unsigned integers:
> > the uint, ulong and ushort data types. Unsigned
> > integers may be useful in some situations, when you want to handle just
> > positive values, but I wouldn't say it's a vital feature. Also, as for
> > the operator overloading, unsigned integers are not part of the CLS, so
> > if you define a method that requires an argument of this type, you won't
> > be able to call it from VB.NET. You can safely use them within the
> > method's body though, without compromising the compatibility with other
> > languages, the important thing is just that they are not exposes in
> > public methods' signatures.
> >
> > 5. The using statement:
> > defines a block of validity for an object
> > variable. As soon as the execution goes outside this block the object is
> > destroyed and disposed. This is good when the developer uses limited
> > resources, and wants to free them as soon as possible.
> >
> > 6 The checked and unchecked statements:
> > specify whether the expressions
> > and constants within the defined blocks raise compile-time errors or
> > runtime exceptions in case of an overflow.
> >
> > 7 The ? : conditional operator:
> > this is a ternary operator, used in the
> > form of op1 ? op2 : op3, that evaluates and returns the result of the
> > second operand if the evaluation of the first operand returned true,
> > while evaluates and returns the result of the third operand otherwise.
> > This is really useful when you want to return a value or set a variable
> > with a different value according to some condition. In VB6 you have the
> > IIf operator that does the same--in VB.NET the IIf operator is still
> > available, but only in the Visual Basic compatibility assembly, so it's
> > not really part of the language itself or the framework library, and its
> > use should be avoided. Personally, this is something I'd be very glad
> > to have built-in in the VB.NET language, I miss it when I program with
> > VB.NET!
> >
> > 8. The ++ and -- operators:
> > these operators increment or decrement a
> > variable by one. For example, instead of writing x += 1 (the += is
> > supported by both C# and VB.NET) you can write x++. While they may be a
> > little bit clearer to use the more verbose syntax in single statements,
> > they are particularly handy to use in for blocks to increment/decrement
> > the index variable.
> >
> > 9 add/remove accessors and the EventHandlerList class:
> > just like the
> > get/set accessors for properties, C# also has the add/remove accessors
> > for events. As you can easily guess, they are used to add fine-grained
> > control to the addition/removal of event listeners. You can use them in
> > conjunction with the EventHandlerList class, that represents a list of
> > key/value pairs, where the key is an object that identifies an event,
> > and the value is a delegate. This class in often used in components and
> > controls that expose a lot of events, because they avoid having an event
> > member for each class event, thus making a more efficient use of
memory.
> > There is no VB.NET counterpart to the add/remove accessors, so the
> > EventHandlerList class is of little use in VB.NET. This is a significant
> > defect if you are a class/component/controls developer.
> >
> > 10. Non-serializable events:
> > when you serialize an object (an instance of
> > a class marked by the Serializable attribute) you'll also serialize all
> > the objects that are references. If your class exposes events, this is
> > a problem, because its listener objects are actually referenced by the
> > object (since the events are implemented through delegates), and thus
> > the serialization mechanist tries to serialize them as well! If the
> > listener is a serializable class you'll "simply" end up serializing more
> > objects than you really want, but if the listener is a Windows Form
> you'll
> > get no less than a runtime exception, because forms aren't
serializable.
> > C# has a very elegant way to solve the problem: you just need to apply
> > a [field: NonSerialized()] attribute to the event declaration, and the
> > event will not be serialized. Unfortunately, VB.NET does not support the
> > "field" target for the NonSerialized attribute. Check out the article
> > at http://archive.devx.com/devxpress/gurl.asp?i=1X8968461X94458 for more
> > information and a couple of proposed workarounds for VB.NET.
> > 11. C# has been submitted to the ECMA committee to become a standard.
> > This also means that
> > other vendors will be able to develop and sell their own compilers and
> > IDEs for C#, while
> > this won't be possible with VB.NET, as it is Microsoft-proprietary. If
> > the .NET Framework
> > will ever be successfully ported to other operating systems
> >
> > ==================================================
> > What VB.NET Does Have That C# Doesn't
> >
> > 1. As in VB6, with VB.NET you can still use the CreateObject function
to
> > create an object
> > instance of a class defined in a COM component with late binding. In C#
> > instead, you necessarily need to create a .NET wrapper assembly and
> > reference it, or
> > use reflection to access the wrapper assembly if you want some sort of
> late
> > binding. It is
> > of course much easier in VB.NET, even though you should avoid the
> > CreateObject function
> > if you want to write code can than be easily translated to other
> > .NET-compliant languages.
> > 2. If in C# you want to handle events raised by some objects, you
> > necessarily need to use
> > delegates to programmatically and explicitly associate a custom method
> > to the class instance, and say that that's the event handler procedure
for
> > some
> > method. This technique is possible in VB.NET too, but VB.NET also allows
> you
> > to declare object
> > variables with the WithEvents keyword, that hides the use of delegation
to
> > associate a
> > custom method to the object instance, and instead allows to write a
method
> > and directly
> > associate it to the proper object instance by means of the Handles
> keyword,
> > that specify the
> > event that the procedure handles. This really makes it faster to write
> code
> > to handle
> > events, especially if you use Visual Studio .NET because it lets you
> select
> > the event name
> > from a drop-down list, and autogenerates the required code.
> > 3. VB.NET supports optional arguments, with a default value if they are
> > not passed to the method. While this may be useful at times, this is not
a
> > CLS-compliant
> > feature, and C# clients won't be able to take advantage of the default
> value
> > for the
> > optional arguments and will always need to pass all the arguments. If
you
> > think there is
> > the possibility that your classes will be called by C# clients the best
> > practice is writing
> > overloaded versions of the same methods, with a different number of
> > parameters, to simulate
> > optional parameters. Here's an example, instead of writing:
> >
> > Public Sub DoSomething(Optional ByVal arg As Integer = -1)
> > ' ...
> > End Sub
> >
> > You can write these two overloads for the DoSomething method:
> >
> > [Overloads] Public Sub DoSomething(ByVal arg As Integer)
> > ' ...
> > End Sub
> >
> > [Overloads] Public Sub DoSomething()
> > ' call the version that takes one argument, and pass in the default
> > value
> > DoSomething(-1)
> > End Sub
> >
> > Overloads is between square brackets in the code above because it's
> > optional, but if you use it in one declaration, then you must use it in
> the
> > other overloaded
> > versions as well. This way, C# clients will also be able to call the
> > overloaded method
> > with a variable number of arguments.
> >
> > However, there is one case in which this feature is very, very
handy--when
> > you use COM Interop to access COM components that expose a lot of
methods
> > with
> > optional parameters.
> > If you do a lot of add-in programming, this point might be enough to
make
> > you choose VB.NET!
> > In addition, note that you can't write VS.NET macros in C# as you do
with
> > VB.NET, and
> > this makes it much more difficult to run and test snippets of code--you
> > have to
> > compile the full add-in and debug it. Alternately, if you want to test a
> > piece of VB.NET code,
> > you can just extract and save it as a macro and run it. Try to compile,
> > register and
> > run everything dozens of times just to find and fix one bug in a
routine,
> > and you'll
> > really appreciate what VB.NET offers in the add-ins development field!
> >
> > 4. VB.NET's With...End With block executes a set of statements on the
> > defined object. Practically, if you're settings a lot of properties or
> > calling a lot of
> > methods of the same object, you declare a With block for that object,
and
> > within the
> > block you access its members without writing the object name, but only
> with
> > a dot (.) prefix.
> > This is a nice feature that can make your code lines a bit shorter and
> > faster to write.
> > You'll also have is a slight performance benefit, because when you use
> the
> > With syntax
> > you have a temporary reference to the bottom-level object which can
speed
> > things up.
> > 5. VB.NET still supports modules (defined within a ModuleEnd Module
> > block, and not identified by a .bas file as in all the previous releases
> of
> > VB) to
> > define application-level variables and global routines/functions. C#
> doesn't
> > support modules, but you can do the same with static class members. In
> > VB.NET you have both
> > options, but modules are good because the caller code doesn't need to
> prefix
> > the
> > procedure name with the module name, as it must do with a static class's
> > members instead. C#
> > callers will see the module as a class with static members (at a lower
> > level modules are
> > implemented that way, in fact), so the compatibility is fully preserved.
> > 6. VB.NET's ReDim statement allows you to change the dimension of an
> > existing array and to maintain the current values. This is not directly
> > possible with C#--you
> > should create a new array with the new size and then copy the values
from
> > the old array
> > to the new instance. Or you could use an ArrayList and when you're done
> > adding
> > elements you can use its ToArray method to get a real array.
> > 7. VB.NET's Select statement is more flexible than C#'s switch
statement,
> > in that it allows you to specify intervals of values (Case 1 To 50) or
> > other
> > conditions (Case Is >10), while C# only allows you to use simple
constants
> > (you have to use
> > the if statement if you need more flexible conditions). C#'s case blocks
> > must also end with
> > an explicit break statement.
> > 8. VB.NET's Catch statement of a Try...Catch...Finally block is more
> > flexible than the C#'s counterpart, in that it allows you to specify a
> > further condition
> > that must be met to have the exception being handled by that Catch
block.
> > For example, you
> > can have something like the following in VB.NET:
> > 9. VB.NET fully supports the structured exception handling, like C#, it
> > is even more flexible as explained in the previous point. However, it
also
> > still
> > supports the infamous On Error statement. Although it has a bad
> reputation,
> > it may actually be
> > useful in certain situations, when you need to resume the execution
after
> > the statement
> > that caused the exception, and not just after all the statements of a
> > Try...Catch...Finally
> > block. This is not to suggest using the On Error option, structured
> > exception handling
> > is a better solution (in terms of performance as well) in many cases,
just
> > not
> > always. The choice is always yours, and personally I like to have one
more
> > option than one less.
> > 10. VB.NET has the ^ operator to do operations with exponents, while C#
> > doesn't have a counterpart for this operator. You necessarily must use
the
> > Math.Pow
> > static method. Ok, this is not a very important feature, but it may make
> > your code a bit
> > shorter in math-intensive algorithms.
> > 11. In VB.NET you can declare and create a new object instance with a
> > single statement: Dim o As New MyObject, while in C# you must first
> declare
> > a new object
> > variable, and then instance it (even if you can still do this in the
same
> > line, as in
> > MyObject o = new MyObject();). The VB.NET's way is faster to write, and
> > keeps the lines
> > shorter.
> > 12. This point concerns VB.NET programming with Visual Studio .NET, so
it
> > is not really about the VB.NET language itself, but I feel it's a quite
> > important
> > point. When in C# you add a method to an existent class, you must
> recompile
> > the project before
> > seeing that new method in the list that the Intellisense pops up when
you
> > write the
> > class instance name followed by a dot. Instead, in VB.NET the new member
> is
> > immediately
> > available in the list. Similarly, when you write invalid code in
C#--such
> as
> > referring to an
> > invalid variable name, calling a non-existent method or passing a wrong
> > number of
> > arguments--the error is signaled only at compile time. Instead, in
VB.Net
> > the invalid code is
> > immediately underlined in red, and you can correct it before compiling.
> This
> > is
> > because the VB.NET is compiled in background while you write it. This is
> > very, very useful,
> > but it also makes the code editor much slower than in C# because of the
> > background work...
> > so you must have a fast machine to really appreciate this feature,
> > otherwise you'll be
> > bothered by the slow editor!
> > 13. VB.NET has the CType function and other casting operators that you
> > can use instead of
> > the Convert class, and that make the casting easier.
> > 14. Instead of importing/including the same list of common namespace in
> > all your source
> > files, as you do in C#, in VB.NET you can define this list at project
> > level, and add just
> > the file-specific imports in the source files. This is very handy when
> > you realize that
> > you can remove an unused namespace or you have to add another one.
> > However, I must say
> > that if you need to import a certain source file later into another
> > project, you might
> > find yourself spending time wondering which project-level imports you
> > need in the new
> > project. This issue does not present in C#, of course, where all the
> > imports are declared
> > at the top of each file.
> > 15. In a VB.NET Windows Forms project where you have a lot of forms you
> > can set the startup
> > forms from the project's Properties dialog, or set a Sub Main procedure
> > as startup object.
> > In C# you don't have this possibility, the startup form is always
> > created and launched
> > from a static Main procedure defined somewhere, typically in the first
> > form class added by
> > VS.NET. When you have a lot of forms and don't remember where the Main
> > function is
> > defined, and you want to change the startup form, you first have to find
> > the Main
> > procedure, and then you have to edit it, and possibly move it to an
> > external class or the
> > startup form class, if you want your code to be well organized.
> > 16. VB.NET still supports the Declare statement you're used to from the
> > previous version.
> > C# doesn't have it and you must declare the signature of the API
> > routine/function
> > and then
> > link it to its implementation using the DllImport attribute. VB.NET
> > developers can use
> > this attribute as well (and they should), but still keep the other
> > possibility, which is
> > useful especially when you're porting to .NET from existing VB code.
> > 17. VB.NET still supports many VB functions, such as AppActivate,
Shell,
> > PrevInstance,
> > StrComp and others, that either don't have a direct .NET counterpart, or
> > provide a quick
> > shortcut to something that would require more code in C#.
> >
> > "Saga" <antiSpam@somewhere.com> wrote in message
> > news:OyVjZIHWEHA.1380@TK2MSFTNGP12.phx.gbl...
> > >
> > > Hi all, I just read the thread by the same name posted on Jun 15, 9:45
> AM,
> > > but
> > > I am looking at it from a different point of view. I came across this
> > > question in
> > > terms of functionality. Are VB and C# (.NET) really functionally
> > equivalent?
> > >
> > > I had read that although they are very similar, C# does extend
> > functionality
> > > further than VB.NET; however, when I searched for pages regarding
this,
> > > I could not find any.
> > >
> > > Any recommendation where I read about this further?
> > >
> > > Thanks all!
> > > Saga
> > >
> > >
> >
> >
>
>
- Next message: Moheb: "AppSettings"
- Previous message: z_learning_tester: "Re: public vs private access, quick question-"
- In reply to: John Wood: "Re: vb.net vs c#.net, the SQL"
- Next in thread: Saga: "Re: vb.net vs c#.net, the SQL"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
