|
Christian Graus wrote:
The core issue then is the convert to a float64. I wonder if these conversions behind the scenes are a reason for the argument that VB.NET is slower than C# ?
It'll definitely contribute to the speed difference because of the conversion process and the 64-bit floating division. But I think the problem lies in the fact that the people who want to bash VB.NET so bad just write some ad-hoc test code for both languages, like in my post, don't realize that they're not comparing apples to apples. When the difference comes up, wow!, they just jump all over the language.
Christian Graus wrote:
Does this mean that C# can't divide using IEEE 754 rules ? Or is it just that VB.NET, being loosely typed, does conversions behind the scenes that C# does not.
No. C#, being based on the same Framework, using the same types and generating the same IL, uses the exact same math rules VB.NET does. C# just has a syntax advantage in the compiler where is will recognize the division situation, since it only has a single division operator, and generate the correct code automatically, (for example when dividing an int32 by an int32, assume the result required is an int32 and generate code for integer division), where VB.NET puts more of that decision process on the coder. The coder is responsible for explicitly telling VB.NET which type of division to use, integer (\) or floating-point (/).
I guess you could make a case for that being a simpler advantage for VB.NET, I don't know. In C#, if you wanted to force floating-point division on two int32's, you'd have to cast the operands to some floating-point type in the expression. IMHO, I'd say it might be slightly simpler to control in VB.NET, but more readable and comprehendable in C#.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Dave Kreskowiak wrote:
IMHO, I'd say it might be slightly simpler to control in VB.NET, but more readable and comprehendable in C#.
Fair enough - thanks for taking the time to look into this, I've found it quite fascinating.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
|
Thanks for the links.
Mathematically, you CAN divide by zero, but what you get is "infinity".
Actually, this is not true. Google some maths sites if you don't believe me. Either way, as the article states, this leaves the way open for some serious problems in business apps that don't work hard to avoid this happening.
I don't understand the integer divide ( \ ) thing. Does that stop VB from implicitly converting ints to floats ? I guess C#, being more strongly typed, wouldn't need that, and that would go *some* way to explaining why C# and VB.NET behave so differently from one another in this instance.
Thanks for the info.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
|
Thanks 
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
If you cast n1 / n2 to an integer...
lblOut.Text = CInt(n1 / n2)
It will throw a divide by zero exception.
Not sure why that is, but setting a labels text returns 'Infinity'.
Dont forget, despite the huge, widespread use of VB, its not a real programming language.
You cant write halfway decent programs with VB.net because it sucks so much.
(Sarcasm intended)
|
|
|
|
|
Daniel1324 wrote:
If you cast n1 / n2 to an integer...
lblOut.Text = CInt(n1 / n2)
It will throw a divide by zero exception
So the problem is with the Single object ? C# behaves differently in this case though, with the same object. It still threw an exception, as it should.
Daniel1324 wrote:
Not sure why that is, but setting a labels text returns 'Infinity'.
Because in VB.NET, an int divided by 0 = infinity when passed to a Single. I don't know why, or why this conversion is obviously implicit. It's the stupidest thing I've ever seen. Like I said, everyone here is still laughing about it.
Here's more fun. If you make n3 an Integer instead of a Single, this code will throw what exception ?
Dim n1, n2 As Integer
Dim n3 As Integer
Dim s As String
n1 = CInt("5")
n2 = CInt("0")
Try
n3 = n1 / n2
s = n3
Catch ex As Exception
s = "Warning!"
End Try
The answer is NOT the 'DivideByZeroException', but an 'OverflowException'. Oh yeah, VB.NET is a real programming language...
Daniel1324 wrote:
Dont forget, despite the huge, widespread use of VB, its not a real programming language.
VB is widely used because it was designed for people who can't program to be able to knock something out. For that, it works. What percentage of applications you bought and run on your desktop were written in VB ?
Daniel1324 wrote:
You cant write halfway decent programs with VB.net because it sucks so much.
Yes, you can write a decent program in VB. Hell, you can write a decent program in almost any language. But that doesn't make it a good tool for the job. On the other end of the coin, you can write any program you like in C. But why would you want to ? C is at least useful, but like VB, it has a lot of hidden traps for the unwary traveller. And that would be my main point. A language for beginners that is rife with hidden gotchas, unexplainable syntax and inexcusable behavour ? Give me a break.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
What percentage of applications you bought and run on your desktop were written in VB ?
Good point.
I actually prefer C# and I am at least as good in C# as I am in VB. But I'm starting college Monday and part of the course is learning VB.net.
I have a love hate relaionship with it... On one hand, I love writing programs in it because, well... its easy. On the other hand, I hate having to tell people that its written Visual Basic.
|
|
|
|
|
Daniel1324 wrote:
Good point.
*grin*
Daniel1324 wrote:
On one hand, I love writing programs in it because, well... its easy.
I don't think C# is any harder. In fact, I think it's easier, because of the many traps in VB.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Now that the rest of you are done, trying to thrash VB.Net
Here is the reason the lblOut Has Infinity in it.
Exception
Invalid operation Exception - An operand is invalid for the operation to be performed.
Return Value: NaN
Division by zero Exception
An attempt is made to divide a non-zero value by zero.
Returns: Infinity (1/-0 = negative infinity)
Overflow Exception
The result of an operation is too large to be represented.
Returns: Positive or negative infinity.
Underflow Exception
The result of an operation is too small to be represented.
Returns: Positive or negative zero.
Inexact Exception
The rounded result of an operation is not exact.
Returns: The calculated value.
cref: IEEE-754/IEC 60559
progload
|
|
|
|
|
Did I stumble into the wrong forum? No wait, it still says Visual "Basic / VB.NET" across the top. Are there any VB programmers in here? That's sort of what I was, you know, expecting. 
So anyways. Progload, if division by zero *is* an exception thrown, why did it not get caught?
________________________________________________________________________
Dave
Y10K bug! Let's not get caught with our pants down **AGAIN**! (DC 02002)
|
|
|
|
|
Dave,
The Divide-by Function("\") caught the exception, and produced a Text Message = "Infinity"
Thus the statement "ex" would be false, No Exception.
That is by design... It's no "trick or trap".
You can test this by doing this, It will now throw the exception to "ex":
Dim n1, n2, n3 as integer
Try
n3 = n1 \ n2
Catch ex As Exception
Label2.Text = "Warning! " & ex.Message
End Try
Hope this helps dave.
Progoad
|
|
|
|
|
So, the key is making n3 an integer. If it's anything else, it won't throw the exception.
It's confusing, but it's really just an example from the book, so no big deal. I should have checked out the book more carefully before purchasing - it's 3 years old.
Anyway, now that I'm into it, I'm seeing that this book is covering basic stuff I already know about VB. (The first time I looked at VB.NET code, I was terrified by all the "Region / Friend WithEvents Button1 As System.Windows.Forms.Button" stuff - I thought I was starting at square one.)
Once the object-oriented stuff from my little bit of Java programming comes back, I'll be more comfortable.
________________________________________________________________________
Dave
Y10K bug! Let's not get caught with our pants down **AGAIN**! (DC 02002)
|
|
|
|
|
Yes,
The label control is a text control, thus if you return the text ("Infinity") into it, why would it throw an exeception (to ex) because it is text?
The author was not following proper basic syntax coding...
and created his own "bug".
By the Way, I realy enjoy VB and VB.Net, and it's Math capability.
Beyond what you see a lot of folks saying... I think it is a very powerfull language.
Have fun learning it.. I am..
progload
|
|
|
|
|
progload wrote:
thus if you return the text ("Infinity") into it
Ah, well I'd assumed it would be the / operation that would throw it.
I see what you're saying now. The / operation catches the error internally and simply returns 'infinity'. Thus, externally, it is not an error at all until I attempt to do something with it.
In fact, the error it's been coded to throw isn't arithmetical at all, it is a type error - I can't assume that the / operation will return a numerical value; it could return a string.
Small potatoes. This is actually baby steps towards developing an app that will access the Windows Media Services 9 SDK to manipulate broadcast media publishing points. And even THAT is an intermediate step to transposing it to ASP.NET so I can do it from a web app.
Can you say 'out of my league'? Why do I do this to myself?
________________________________________________________________________
Dave
Y10K bug! Let's not get caught with our pants down **AGAIN**! (DC 02002)
|
|
|
|
|
Sorry Dave, you seem to have stumbled upon an amazingly illogical and inconsistent piece of VB.NET behaviour, hence the discussion. I thought I did in fact explain how to get the exception to throw though, didn't I ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
1] The book says Catch e As Exception, but Visual Studio defaults to 'ex' instead of 'e'. If I deliberately put in 'e', I get a build error: "Variable 'e' hides a variable in an enclosing block." What is wrong here?
The book that you are using may have a different definition in its parameters for your code block.
For example:
public sub Test(byval sender as object, byval e as system.eventargs)<br />
Dim n1, n2 As Integer<br />
Dim n3 As Single<br />
n1 = CInt(txtIn1.Text)<br />
n2 = CInt(txtIn2.Text)<br />
Try<br />
lblOut.Text = n1 / n2<br />
Catch e As Exception<br />
lblWarn.Text = "Warning!"<br />
End Try<br />
end sub<br />
If you tried to catch 'e as an exception' than the e would override the 'e as system.eventargs' which is in the sub parameter. So you can change either of the two variables but they cannot be the same. Look in your book and see if the parameters for the sub or function use an e variable.
|
|
|
|
|
In addition to the comment above, I would advide just assuming "ex" as a standard way for naming exceptions, because for all practical purposes you should just consider "e" as a system reserved variable because NET always declares event arguments as "e".
As far as the "VB is crap" comments, you'll get use to that. It happens on a regular basis. This is a tired, no longer relevant pet argument that some tired, no longer relevant people seem to be unable to let go of.
The reality is that although there are some very minor differences between C# and VB.NET, once you learn to program against the NET framework, you will discover that there is essentially no practical difference.
They both compile to exactly the same machine level code, and they both have for all practical purposes the same level of functionality.
Just tune it out.
|
|
|
|
|
hellow to all ..
can i combien an MS.office command like Save file , or Open file with a program .
for example if i click Save File from the office , the program will Run ?
and one have anyideas ?
Thxx a lott
|
|
|
|
|
if no one have answer for me at least tell me where i can find the answer ..
thxx a lott ..
|
|
|
|
|
Well, we really are not on this message board to be at your beck and call and so a little patience will go a long way to endearing yourself to the rest of the community. Not all of us 'live and breathe' to answer questions.
Now that I have that off my chest, yes you can run your own program (in almost any language) in place of the MS Word-supplied menus. You will need to override the MS one with your own. Exactly how to do this I am not sure as it has been a looooooong time since I have touched Word. Your best bet is to look at the MS Office Tools and/or MSDN web sites for the methods to achieve this.
In fact this was the first hit on Google... http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnword2k2/html/odc_wdoverride.asp[^]
...Steve
|
|
|
|
|
Hello
Is there anyone who can tell me how to use the mtgccombobox in datagridview in vb.net 2005 to replace the combobox that comes with the datagridview
soren lovgren
|
|
|
|
|
Here is my problem :
On a PC there is a software that I do not control that is writing a line text in a file every time it receive data.
My software, in VB .net, should read this file and recover only the last line. I made a routine that read the file every 5 secondes.
It's running under WinDows XP.
The problem is that the soft that is writing into the file do not give me access to the file, even in read only. I use a streamreader .
The solution I currently use consist in making a copy of the original data file, then read the copy. This is ugly !!
Any idea to do it the proper way ?
Thanks for help,
Loïc
|
|
|
|
|
Can't be done. If it's open for writing, you can't read it.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
