|
aberglas wrote:
+ Optional parameters. Come on guys, this is a basic feature of just about every modern language ... except C/C++. Polymorphism is a painful and cryptic alternative.
There is a reason these were left out. It's for version compatibility. You see, the default parameters would have to be compiled into the calling code and then if the parameter's default value changes in the module containing the function, the calling code still uses the old one.
Using multiple overloads that (usually) call the one with most parameters is a good solution.
aberglas wrote:
+ No need to explicitly cast down, ie. no need for
MyType foo = (MyType)MyArrayList[x]
This casting is a pain if you start using more generalized data structures. And contrary to popular belief it adds very little. In C it is important because the runtime does not check and disaster easily results. But with managed code it is just a legacy idea.
Yea, it can be a bit annoying. I can't see why the compiler can't check for the validity of the conversion and just report an error if it is invalid... hmm or maybe...
aberglas wrote:
+ End * syntax ragher than {}s. {}s are a pain if you get them wrong -- it can be hard to see what a "}" matches in a larger block of code.
Well this is purely a matter of style, some like things different. I totally hate End *, but I guess you like it. Maybe someone can do a VS.Net plugin for turning the Ends into {}s automatically on build?
aberglas wrote:
+ dim x = new MyDataType(...)
avoids the redundancy of
MyDataType x = new MyDataType(...) // note the redundancy!
(And the Dim is normally redundant
Nono, that is bad.
dim x = 3; // What data type is this?
And of course assuming that pointers will only be used for the types that they are is bad also.
What if you want to make an interface pointer?
|
|
|
|
|
Locked Ghost wrote:
+ Optional parameters. Come on guys, this is a basic feature of just about every modern language ... except C/C++. Polymorphism is a painful and cryptic alternative.
There is a reason these were left out. It's for version compatibility. You see, the default parameters would have to be compiled into the calling code and then if the parameter's default value changes in the module containing the function, the calling code still uses the old one.
Using multiple overloads that (usually) call the one with most parameters is a good solution.
This is oft stated but wrong. There is absolutely no need for the default parameters to be compiled into the calling code. One easy way is to just retrieve the default values from defining class. And the JIT compiler can then optimize this away where appropriate. (What the C++ people miss is that the JIT works at run time, so it knows what the optional parameter values really are.)
Locked Ghost wrote:
Nono, that is bad.
dim x = 3; // What data type is this?
Integer, obviously. C++/Java/C# relies on the exact types of constants for expression evaluation, eg.
long lng = 1000000 * 1000000; // Bug!
(One of the few advantages of .Net over Java is that at least the above error will be trapped, iff you enable integer overflow detection (very cheap).)
But really, fixed precission arithmetic is a legacy idea most of the time. Lisp got this right -- the default is indefinite preciession, implemented very efficiently using the fixnum trick.
It seems like the legacy of bad ideas from C/C++ will outlive the languages. Eg. will comments ever nest (/*../*..*/..*/)?
|
|
|
|
|
I am sorry to hear of your displeasure with C# and a preference for VB. I'm a long-time VB guy and I initially objected when my company chose C# over VB when we began to study .NET. After a short time, to my amazement, I was quickly converted and have never looked back.
To comment on your comments:
+ Optional parameters.
Good in VB6 where there was no overloading, but now is just a lazy alternative to overloads. The parameters for a method indicate what's required. If it isn't required there shouldn't be a parameter. This creates confusion about how to properly call the method.
+ No need to explicitly cast down ...
Strongly typed languages are a Godsend. Numerous times have I seen bugs due to incorrect typing. Frankly, I want to know what types I'm working with, not what the runtime can figure out (implicit type casting). Dan Appleman talks/rants at length on this one aspect). Also, the compiler can enforce typing. I think it was a mistake for MS to have Option Strict Off by default.
+ End * syntax ragher than {}s.
Purely preference. I love the clean syntax of C#. The verbosity of VB annoys me to no end.
To add a real difference between the two languages, I'v found two technical areas that cannot be achieved with VB:
1. Operator Overloads - True many won't use this, but I did in implementing a custom structure in a recent app.
2. Adding NonSerializedAttribute to public events - Because of the syntax of VB surrounding events, the NonSerializedAttribute cannot be applied to a public event delegate. This is a critical problem when an instance of the class is serialized because the CLR tries to serialize the entire object graph, including any other classes that have delegates linked to the public event. If any object in the graph is not serializable, a SerializationException will be thrown.
The second point is the real clincher for me. I'm through with getting backed into technical corners because of shortfalls in a platform. I feel totally betrayed by classic VB and the way it was supposed to hide the technical details of Windows programming, only to find that even moderately sophisticated UIs required knowledge and useage of the Win32 API.
I appreciate your comments and enjoy the lively discussion that your article generated.
Good luck!
|
|
|
|
|
>... because C# has been designed by C
IIRC, C# was designed by the creator of DELPHI. This becomes obvious if you work with both languages.
|
|
|
|
|
>> + Optional parameters. Come on guys, this is a basic feature of just about every modern language ... except C/C++. Polymorphism is a painful and cryptic alternative. <<
Actually, C++ allows default parameters. And operator overloading has very bupkis to do with polymorphism. But operator overloading is clearer, for certain. It decreasesbugs on both ends when done properly.
>> + No need to explicitly cast down, ie. no need for
MyType foo = (MyType)MyArrayList[x]
This casting is a pain if you start using more generalized data structures. And contrary to popular belief it adds very little. In C it is important because the runtime does not check and disaster easily results. But with managed code it is just a legacy idea. <<
Strongly typed languages should not allow such trash. (And weakly typed languages are trash.)
>> + End * syntax ragher than {}s. {}s are a pain if you get them wrong -- it can be hard to see what a "}" matches in a larger block of code. <<
Meh. You need glasses if you can't see the '}'.
>> + dim x = new MyDataType(...)
avoids the redundancy of
MyDataType x = new MyDataType(...) // note the redundancy!
(And the Dim is normally redundant <<
Also trash.
|
|
|
|
|
I started into .Net (from Vb6) with VB.net but, have since found C# a much better development language for a lot of reasons. But I really do miss:
- optional parameters - sometimes much easier than overloaded functions
- the 'with' keyword
- VB's 'Select Case' - easier to work with then 'switch'
and in VS.net 2003:
- function divider bars in the editor window
and VS.net Whidbey:
- edit and continue
Will choosing C# over VB.NET or VB.NET over C# always be a compromise?
|
|
|
|
|
Dear Anonymous and ALL Developers:
It sure is difficult to unlearn one language and get steady with another. But look on the brighter side you have already managed to do so.
In VB.NET optional parameters are a definite plus... But you can also have optional parameters in C# methods using what is collectively called a “parameter-array”.
A parameter-array consists of an optional set of attributes, a params modifier, an array-type, and an identifier. A parameter array declares a single parameter of the given array type with the given name.
Read more about it on MSDN: "10.5.1 Method parameters"
This also supports the claim that languages have differences in syntax alone and a few in the IL too. (I say IL as it’s no longer a Microsoft only implementation).
The 'with' and 'select' syntax are respectively not used much or are actually not considered as good programming and therefore were ignored and not adopted in the design of C#. On the brighter side C# switch is much neater and allows mulitlpe fallthroughs.
INTERESTING FIND
Here’s an interesting find (I found this in one of my endless coding sessions) I am sure most of you might already be familiar with it but fot those who are not here it is.
Did you know... that C# and VB.NET have tons of things different at IDE level also. Let alone the syntax.
For example Visual Basic .NET IntelliSense feature will not show the Region or the ClientRectangle members of the Windows form. C# IntelliSense, on the other hand, exposes these members as expected.
This behavior can be taken care of by simply changing your options. To do this, select Options from Visual Studio's Tools menu, and then open the Text Editor item. Select All Languages (or just Basic if you want to limit the effects to VB.NET) and uncheck the "Hide advanced members" checkbox. Click OK to close the Options dialog. The change takes effect immediately.
Thank you for pointing to these issues.
, Happy Coding.
Rai Umair
What is now proved, was once only imagened...
|
|
|
|
|
Thanks for the reply, but sorry, I don't buy your arguments:
Although I know both Vb.net and C#, I find it a royal pain to switch back and forth (..what is the Vb keyword for static again?). this is very counter productive.
A param array is not the same as an optional paramater because the exposed interface is not as intuitive to the user of a class:
eg:
VB:
Public Sub DoSomething(optional byval Name as String="", optional byVal Age as integer=0)
C# Equivalent(???):
public void DoSomething(params object[] userDetails)
Also, you can't tell me that:
myObject.Property1 = 32
myObject.Property2 = "fsdfsdfs"
myObject.DoSomething()
is better programming form than:
With myObject
.Property1 = 32
.Property2 = "fsdfsdfs"
.DoSomething()
End with
|
|
|
|
|
Dear Anonymous:
You are right about the counter productive nature of programming the same thing in different languages. But then that's the reason we developers prefer one language from another in the first place.
I think I was not able to make self clear; in the last message what I actually meant was:
That the C# designers found ‘With’ practical but found that it provided small or non-existent readability benefits, increased language complexity and the simple reason that it did not go with C++ heritage.
While in C#, the switch statement requires that explicit flow control occur at the end of a case, either a break, goto, return, or throw. If the developer desires fall-through semantics, it can be achieved by an explicit goto at the end of a case statement.
The other thing you have referred to is the optional parameter support, you are right its not easy to do so in C# and VB.NET but it certainly makes optional parameters possible.
Thank you for your insight and opinion.
, Happy Coding.
Rai Umair
What is now proved, was once only imagened...
|
|
|
|
|
I like that C# requires explicit flow control statements. I once spent an entire weekend trying to fid a bug in a C++ program, only to find that I had accidentally left out a 'break;' in a switch statement. Very annoying and time-consuming, and C# prevents this type of bug from ever showing up in your code.
|
|
|
|
|
//Also, you can't tell me that:
//
//myObject.Property1 = 32
//myObject.Property2 = "fsdfsdfs"
//myObject.DoSomething()
//
//is better programming form than:
//
//With myObject
//.Property1 = 32
//.Property2 = "fsdfsdfs"
//.DoSomething()
//End with
I can. :p That's terribly ugly, and not really any faster on the fingers, since you have to add the new keywords. Also, you forgot your semicolons.
|
|
|
|
|
If you compile the "same" code in different .NET languages and view the IL code generated, you'll notice that it differs between compilers. C++ still produces the fastest code, and VB.NET the slowest one. You may also want to check This article[^] for some experimental results between languages.
|
|
|
|
|
Dear Nemanja Trifunovic:
Well I agree that plain old C++ compiler produces the fastest code, but when we talk about managed code C# or VB (I guess I need to stress that you can code differently for better results) are the fastest and the relative difference between the two is also negligible.
Some interesting points from the above referred Article: http://www.codeproject.com/dotnet/PrimeNumbersProjects.asp
- The C# compiler seems to be markedly better than the MC++ compiler (pure managed code).
- Using ngen has most impact on VB.NET assemblies and least impact on MC++ assemblies
- Mixing unmanaged and managed code with C++ is far more efficient than pure -MC++. In fact pure MC++ is much slower than C# for fully managed projects. ---- Thus unless you plan to integrate MFC or ATL, C# is the better choice over MC++.
, Keep Smiling.
Rai Umair
What is now proved, was once only imagened...
|
|
|
|
|
Yes, but in your article you wrote:
Rai Umair wrote:
As mentioned earlier the only difference that remains among languages like C# and VB.NET are cosmetic ones; they solely depend on the semantics and languages structs of each language.
and also
Rai Umair wrote:
Many developers believe that VB.NET is slower then C#. That’s not entirely true. The only place I see VB.NET slower than C# is where developers use old-style functions like Len and Mid instead of calling reciprocal methods available within the .NET Framework library classes.
And that is simply not the case. Different compilers produce different IL. In *most* cases C# will produce better code than VB.NET, and MC++ better code than C#. Of course, in most cases this difference will be a non-issue.
More about this you can find in This book[^].
Or, like I said before, compile "Hello world" in C#, VB.NET and MC++ and compare the IL code.
|
|
|
|
|
Dear Nemanja Trifunovic:
I see your point, you are rightly concerned about the difference of IL code and I guess no change of programming practice in VB.NET can achieve 100% IL match with an app in C#. But I would like to clear one thing with all the example programs and benchmarks that have crossed my eyes I have never seen ‘MC++’ surpassing C# in performance, I am really interested in pure MC++ relative performance with C# so If you have some bench marks please do share them.
Thanks for the nice book reference; I guess it’s the only book that promotes programming with MSIL. Highly recommended reading for all advanced developers.
http://www.amazon.com/exec/obidos/tg/detail/-/1861006292/qid=1057894174/sr=1-9/ref=sr_1_9/103-2177118-3999000?v=glance&s=books[^]
, Keep Smiling.
Rai Umair
What is now proved, was once only imagened...
|
|
|
|
|
Rai Umair wrote:
Some interesting points from the above referred Article: http://www.codeproject.com/dotnet/PrimeNumbersProjects.asp
Thats a flawed study. I should know as it was my idea originaly back in March 02.
http://www.codeproject.com/lounge.asp?forumid=1159&select=138663&tid=138624[^]
I posted my first results in the lounge a while before they did the article, along with the code for C#, C++, Java, VB6 and Perl I think. Can't be bothered about going into the details, but you should read up on benchmarking in general. All that study does it tell you that one is better than the other at looping around and finding prime numbers in simple way. And its only examining integer performance.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table.
Shameless Plug - Distributed Database Transactions in .NET using COM+
|
|
|
|
|
First, there are some differences in how the languages compile that can improve speed and size. VB.NET, for example, still allows for the old syntax of FunctionName = ReturnValue and - whether or not you use it - adds an extra local variable to the IL for the method of the return Type. Also, different language compilers optimize differently, but you're absolutely right: the end result is IL (MSIL to be exact). Some things are also forced by certain languages. C# and VB.NET don't let you have have global methods even though IL supports it (I've written source in IL at times to avoid having useless class being JITted in whole). C++ compilers must do this, in fact, for executables (i.e., exe's, dll's, etc.).
Also, I think that C# is better for newbies because it opens the doors for more languages (C/C++, PERL, Java, and many more) and it's easier to read. I know hardened VB programmers (I know it well, but I'm not crazy about it) that even hate reading code samples online in VB because it's difficult to determine where statements begin and end, especially when lazy publishers won't tabify their source!
Also, the other important thing to point-out is that .NET is actually bad marketing lingo that has been more of a detriment. The .NET Framework is actually class library that all languages targeting the CLR can use - in the same way. The CLR is the Common Language Runtime and actually JITs (just-in-time compiling) and executes the IL (intermediate language) on-demand. The CTS is the common type system that aids in a great many things, like class types, reflection, inheritence, and more. The marketing department typically wraps this all up under the .NET logo.
So, as you are searching for and using libraries, remember that it DOES NOT MATTER what language it was written in! The classes, structs, interfaces, enums, properties, methods, etc. are exactly the same. This is a feature of IL and the CLR - not the language in which it was authored.
So, to all those people out there asking for VB code for a C# article or vice-versa, quit asking! It doesn't matter if you have the assemblies from the demo zips or something. If you want to include them in your project or are forced to compile the source, learn both languages! Remember, the class library is EXACTLY the same for all languages targeting the CLR. The syntax is the only thing different, and that's just a slight bit of reworking. Using the class library is easy to translate and usually makes-up most of the program.
Besides, it's good to know as many languages as you can. As the poster below me stated, he uses whatever language the client requests. Can you do that? Think about how much marketable you'll be. But remember, knowing how to code isn't the same as knowing how to develop: that takes experience and research. Don't forget to read the docs and don't guess at implementations using all the "nifty" features of the IDE like IntelliSense. There's often code right in the .NET class library that does what you need to and most of the time and can help you do it more efficiently. Reading the docs is important to understand - otherwise you're just guessing and that'll never amount to anything.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Dear Heath Stewart:
Thank you for your in-depth review and educated opinions.
On another note please help me with the following:
Actually there are a few typos the CLS mentioned in the second paragraph is supposed to be CLR the ‘Common Language Runtime.’
Secondly the moving of the article to its new home directory has left the link to the image obsolete.
Well how can I edit my article, I can’t see the update link any more?
Thank you for your time.
, Keep Smiling.
Rai Umair
What is now proved, was once only imagened...
|
|
|
|
|
For some reason, the image didn't transfer correctly during editing. I'll fix that and your typo.
As far as editing, you no longer have the ability to edit your articles directly. That is the price authors pay for editing, which solidifies your article in the anals of CodeProject, and make it look better since it is now edited. For information about how to submit updates, see "Contribute" at the top of the base (between "Lounce" and "Message Forums").
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Heath Stewart wrote:
Some things are also forced by certain languages. C# and VB.NET don't let you have have global methods even though IL supports it (I've written source in IL at times to avoid having useless class being JITted in whole). C++ compilers must do this, in fact, for executables (i.e., exe's, dll's, etc.).
Correct me if I'm wrong, but wouldn't static C# classes and methods be the parallel of global methods in C++?
|
|
|
|
|
Dear Furty:
Thanks for bringing up this interesting point, I have confirmed with the MSDN documentation and I find my self agreeing with you.
C# does not offer global methods. Well the designers have been very careful to avoid all the trouble some pitfalls in C++. I guess static members are more power full then C++ global methods in the sense that they lead to good 100% OOP code and the developer has more control on them in the corm of various attributes and access levels. Thats one reason 'Main' in CSharp is a static (keeps value for the lifetime) method.
, Keep Coding.
Rai Umair
What is now proved, was once only imagened...
|
|
|
|
|
No, the reason that main is static is because it is an entry point. When your app starts, it has to start somewhere and what is going to tell it to instantiate what class and call what instance method? Besides, Main is a method - there's no value to keep. Even if you were to call Form.ShowDialog inside Main, the app would close immediately because Main keeps going. The only way to get it to execute during the app's lifetime is to start a message pump, which is essentially an infinite loop with a way out (WM_QUIT).
As far as global methods, I guess you could say it's parallel. It serves the same purpose. What I was referring to, though, was a single method with absolutely no class. Perhaps calling it "global" wasn't correct. I'll post the source IL file below, though, to show you exactly what I mean. Otherwise, I would have to agree with you, too.
.assembly extern mscorlib {}
.assembly ToUpper
{
.ver 1:0:0:0
}
.module ToUpper.exe
.method static void main(string[]) cil managed
{
.maxstack 2
.entrypoint
ldarg.0
ldlen
conv.i4
ldc.i4.1
beq Capitalize
ldstr "You must specify a string to convert to upper case."
call void [mscorlib]System.Console::WriteLine(string)
ret
Capitalize:
ldarg.0
ldc.i4.0
ldelem.ref
call instance string [mscorlib]System.String::ToUpper()
call void [mscorlib]System.Console::WriteLine(string)
ret
}
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Heath Stewart wrote:
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
This is more reminiscent of mine..
; Input filename<br />
0AB1 A2 00 LDX #$00<br />
0AB3 86 C6 STX $C6 ; clear buffer<br />
0AB5 86 CC STX $CC ; cursor on<br />
0AB7 86 8D STX $8D<br />
0AB9 20 E4 FF JSR $FFE4<br />
0ABC C9 03 CMP #$03 ; RUN STOP key<br />
0ABE F0 82 BEQ $0A42 ; If so then restart<br />
0AC0 A6 8D LDX $8D<br />
0AC2 F0 08 BEQ $0ACC ; branch if X = 0<br />
0AC4 C9 14 CMP #$14 ; Delete key<br />
0AC6 F0 18 BEQ $0AE0<br />
0AC8 C9 0D CMP #$0D ; Return key<br />
0ACA F0 17 BEQ $0AE3 ; If so then End input<br />
0ACC 29 7F AND #$7F ; Remove high byte<br />
0ACE C9 20 CMP #$20 ; ignore spaces<br />
0AD0 90 E7 BCC $0AB9<br />
0AD2 E0 10 CPX #$10 ; upto 16 characters<br />
0AD4 F0 E3 BEQ $0AB9<br />
0AD6 E8 INX<br />
0AD7 0A ASL<br />
0AD8 C9 82 CMP #$82<br />
0ADA 6A ROR<br />
0ADB 20 D2 FF JSR $FFD2 ; display character<br />
0ADE 90 D7 BCC $0AB7<br />
0AE0 CA DEX ; reduce filename length<br />
0AE1 10 F8 BPL $0ADB ; branch back (always)
Unfortuantely time has seen all my old 6502 assembly lost, but the memories are still there!
|
|
|
|
|
Dear Matthew Davison:
People like to make a big deal about which lang to use but in reality .Net is all about the class libs and APIs not which lang you use... That was the whole point of .Net in the first place.
I totally agree with you.
the client normally decides which language I will be writing in...
Well, it’s really unfortunate that the clients are mostly oblivious of the language independence of .NET instead insist on doing the project in their choice of programming language.
Some of them make educated decisions based on maintenance and long term benefits but the majority just want their project developed in the same language as their 'competition'.
Well I guess for an individual developer to be the master of more then one programming language is quite possible but is not common practice among developers and I reckon only software shops excelling if not all but majority of the languages can succeed in entertaining such clientele.
Thank you for your two cents.
, Keep Smiling.
Rai Umair
What is now proved, was once only imagened...
|
|
|
|
|
Rai wrote:
Well, it’s really unfortunate that the clients are mostly oblivious of the language independence of .NET instead insist on doing the project in their choice of programming language.
When you've finally convinced a client that they should ditch the Access 97 application and convert it to MSDE with .NET, you don't want to tell them that they'll need to learn C# as well. Go with VB.NET. Full-stop.
Rai wrote:
Well I guess for an individual developer to be the master of more then one programming language is quite possible but is not common practice among developers
Unless you can imagine working in the same position for eternity. People usually learn another language, or ten. I mean, practically, you learn C, then C++, then Java, then C# then J#, apart from some cosmetic and syntactic differences there's not much else that's 'different'. Most university CS graduates know at least 5 languages to start with anyway.
|
|
|
|
|