Wrox Programmer Forums
|
BOOK: Professional Visual Basic 2008 ISBN: 978-0-470-19136-1
This is the forum to discuss the Wrox book Professional Visual Basic 2008 by Bill Evjen, Billy Hollis, Bill Sheldon, Kent Sharkey; ISBN: 9780470191361
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Professional Visual Basic 2008 ISBN: 978-0-470-19136-1 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old February 4th, 2009, 05:11 AM
Authorized User
 
Join Date: Dec 2008
Posts: 29
Thanks: 0
Thanked 0 Times in 0 Posts
Default Page 88 - Practice what you preach.

First let me quote page 45
"however, continued use of these methods is not considered best practice. That bears repeating: While you may find the following methods in existing code, you should strive to avoid and replace these call:
CBool() CChar() CDbl() CInt() CObj() CSng() CByte() CDate() CDec() CLng() CShort() CStr()"

Now let me quote page 88
"Messagebox.Show(CStr(Person.PersonCount))"

Although this line not really part of the lesson it it irks me that I paid a premium for a book called Professional Visual Basic 2008 and find recycled/hacked up VB6 samples.

How much effort would it have taken to update the code to read
Messagebox.Show(CType(Person.PersonCount,String)) which was already discussed in the prev chapter?

Last edited by Patrick Cambria; February 4th, 2009 at 05:15 AM..
 
Old February 5th, 2009, 07:47 PM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

Well, I'm a little curious as to why the author discourages the use of CSTR(), CDBL(), et al.

They *ARE* part of the VB.NET language/library [see post below]. And under the covers they do exactly the same thing that CTYPE( ) does. So why not use the "shorthand"??

So does the book explain *WHY* "continued use of these methods is not considered best practice"????

Last edited by Old Pedant; February 5th, 2009 at 07:55 PM..
 
Old February 5th, 2009, 07:54 PM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

I happen to have a copy of "Microsoft Visual Basic .NET Language Specification", version 7.1, by no less a person than Paul Vick. And his chapter 8, "Converions", begins with example of implicit and explicit conversions. Guess what he shows for the explicit conversion example??? Yep, you got it: CINT( )

So...the heck with it.

If Paul Vick can use CINT() then I sure as heck can! <grin style="smirking" />
 
Old February 6th, 2009, 02:19 AM
Authorized User
 
Join Date: Dec 2008
Posts: 29
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by Old Pedant View Post
Well, I'm a little curious as to why the author discourages the use of CSTR(), CDBL(), et al.

They *ARE* part of the VB.NET language/library [see post below]. And under the covers they do exactly the same thing that CTYPE( ) does. So why not use the "shorthand"??

So does the book explain *WHY* "continued use of these methods is not considered best practice"????
Page 45 "The disadvantage of these methods is that they have been designed to support any object. This means that if primative type is used, then the method automatically boxes the parameter prior to getting the new value. The result is a loss of performance. Finally, although these are available as methods within the VB language, the are actually implemented in a class (as with everything in the .NET Framework.) Because the class uses a series of type-specific overloaded methods, the conversions fun faster when the members of the Convert class are called explicitly."

Boxing (Page 34)
Normally, when a converion (implicit or explicit) occurs, the original value is read from its current memory location, and then the new value is assigned. For example, to convert a short to a Long, the system reads the two bytes of Short data and writes them to the appropriate bytes for the Long variable. However, under Visual Basic, if a vaule type needs to be managed as an object, then the system performs an intermediate step. This intermediate step involves taking the value on the stack and copying it to the heap, a process referred to as boxing. As noted earlier, the object class is implimented as a referrence type, so the system needs to convert value types into reference types for them to be objects. This doesn't cause any problems or require any special programming, because boxing isn;t something to declare or directly control, but it does affect performance."

Over loading methods (Not Quoted) means you have more then one version of the same method but they accept different parameters resulting in unique method signatures. Example your class can have both:
Code:
Function RetString(ByVal input as Integer) As string
    Return Ctype(input,String)
End Function

Function RetString(ByVal input as Long) As string
    Return Ctype(input,String)
End Function
I believe the speed differences between CInt() and CType are directly related to LateBinding vs. Early Binding

CInt(param) would be late binding because the compiler does not know in advance the type of param.

CType(param,Integer) would be an early binging referrence to the Integer class.

Page 56 "Early binding means that code directly interacts with an object by directly calling its methods. Because the Visual Basic compiler knows the object's data type ahead of time, it can directly compile code to invoke the methods on the object....."

"Late binding means your code interacts with an object dynamically at runtime."

Besides the obvious speed advantages of early binding, you need to provide exeception handling when you work with late binding code.

To make the topic even more complex we discuss DirectCast and TryCast which they say are both faster then CType.


Here is a simple test that runs two identical For Loops 1 uses CInt() the other uses CType()

Code:
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim DebugWatch As New Stopwatch

        Dim Counter As Object
        Dim CounterMin As Integer = 0
        Dim CounterMax As Integer = 10000         
        Dim ObjectOut As Object

        DebugWatch.Reset()
        DebugWatch.Start()
        For Counter = CounterMin To CounterMax
            ObjectOut = CInt(Counter)
        Next
        DebugWatch.Stop()
        Debug.Print("CInt Loop: " & DebugWatch.Elapsed.ToString)

        DebugWatch.Reset()
        DebugWatch.Start()
        For Counter2 = CounterMin To CounterMax
            ObjectOut = CType(Counter, Integer)
        Next
        DebugWatch.Stop()
        Debug.Print("CType Loop: " & DebugWatch.Elapsed.ToString)

    End Sub
My results:

CInt Loop: 00:00:00.0018095
CType Loop: 00:00:00.0002892

CInt Loop: 00:00:00.0014591
CType Loop: 00:00:00.0009015

CInt Loop: 00:00:00.0013791
CType Loop: 00:00:00.0002828

CInt Loop: 00:00:00.0023131
CType Loop: 00:00:00.0003122

CInt Loop: 00:00:00.0013799
CType Loop: 00:00:00.0007345

That is an insane difference.
Imagine running that loop over a million times say is you wanted to loop through the pixels of a 10 Megal Pixel photo and create an integer value based on the color of each pixel.
But if your writing apps to convert Dim x as Integer = 1 to to a Long once or twice I guess it doesnt matter.

Last edited by Patrick Cambria; February 7th, 2009 at 03:39 AM..
 
Old February 6th, 2009, 04:13 AM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

This post removed because the example suggested by Patrick using KeyUp event, et al., is a better proof than anything else I had come up with that the authors are wrong about the use of VB.NET's built-in CXXXX( ) functions.

Last edited by Old Pedant; February 6th, 2009 at 11:28 PM.. Reason: Better benchmark presented later.
 
Old February 6th, 2009, 04:38 AM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

This post removed because the example suggested by Patrick using KeyUp event, et al., is a better proof than anything else I had come up with that the authors are wrong about the use of VB.NET's built-in CXXXX( ) functions.

Last edited by Old Pedant; February 6th, 2009 at 11:29 PM.. Reason: Better benchmark presented later.
 
Old February 6th, 2009, 05:01 PM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

This post removed because the example suggested by Patrick using KeyUp event, et al., is a better proof than anything else I had come up with that the authors are wrong about the use of VB.NET's built-in CXXXX( ) functions.

Last edited by Old Pedant; February 6th, 2009 at 11:30 PM.. Reason: Better benchmark presented later.
 
Old February 6th, 2009, 09:53 PM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

This post removed because the example suggested by Patrick using KeyUp event, et al., is a better proof than anything else I had come up with that the authors are wrong about the use of VB.NET's built-in CXXXX( ) functions.

Last edited by Old Pedant; February 6th, 2009 at 11:31 PM.. Reason: Better benchmark presented later.
 
Old February 6th, 2009, 11:26 PM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default Well, since you asked...

There's no way one could measure the performance of the two functions that way, depending as it does on an event handler. Given what I saw, with the difference in performance between CXXX and CTYPE being miniscule, how would you ever measure a few nanoseconds accurately? If another process (or even thread) happened to interrupt in the middle, you could see a difference of milliseconds from that code.

Now, if we change it slightly, to execute each conversion 10,000,000 times, *then* you might get numbers you could compare.

Like this:
Code:
    Private Sub TextBox1_KeyUp(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyEventArgs) _
            Handles TextBox1.KeyUp
        Dim t1 As DateTime
        Dim t2 As DateTime
        Dim dif1 As String
        Dim dif2 As String
        Dim i As Integer
        Dim j As Integer


        t1 = Now
        For j = 1 To 10000000
            i = CType(e.KeyValue.ToString(), Integer)
        Next
        t2 = Now
        dif2 = CType(t2.Subtract(t1).ToString, String)

        t1 = Now
        For j = 1 To 10000000
            i = CInt(e.KeyValue().ToString)
        Next
        t2 = Now
        dif1 = CStr(t2.Subtract(t1).ToString)

        MsgBox("CTYPE: " & dif2 & vbCrLf & "CINT: " & dif1)
   End Sub
Here are some sample outputs from 5 runs of that code.
Code:
CTYPE: 00:00:07.8312608
CINT: 00:00:07.8012176

CTYPE: 00:00:07.8012176
CINT: 00:00:07.7411312

CTYPE: 00:00:07.8813328
CINT: 00:00:07.8312608

CTYPE: 00:00:07.9414192
CINT: 00:00:07.8512896

CTYPE: 00:00:07.8012176
CINT: 00:00:07.7411312
If you can conclude anything from that but that *MAYBE* CINT( ) is almost 1% faster than CTYPE( ) then you have better eyes than I do.

And now I really will go wipe out all my other posts and leave this one as proof of my contention that the authors of the book are most certainly wrong in their contention that the use of VB.NET "built-in" conversion methods is a bad idea. If anything, the opposite is true.

I will leave up for grabs that they are wrong about the boxing. I think they are, but it's too much work to try and prove it.

***************

By the by, I cloned your code as close as possible, even leaving in the extraneous call to CTYPE here:
Code:
dif2 = CType(t2.Subtract(t1).ToString, String)
Clearly if you have already called the ToString method the value is already a string, and so CTYPE has nothing at all to do.
Since this would have no impact on the results, I left it alone.

***************

And it's not terribly relevant, but it's interesting to note that the time required to do the integer-to-string conversion via your
Code:
e.KeyValue.ToString
is roughly the same as the time required to convert that string back to an integer.
 
Old February 6th, 2009, 11:37 PM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

Postscript: Just because I'm anal retentive (well, look at my "handle"), I had to run the test 10 more times.

Out of 10 tests, CTYPE() was faster than CINT() 3 times.

Never was either as much as a full 1% faster than the other.

I have to conclude that the performance differences are, indeed, immeasurably insignificant.





Similar Threads
Thread Thread Starter Forum Replies Last Post
An error for AJAX practice wen BOOK: Beginning Ajax with ASP.NET 0 December 13th, 2006 06:02 PM
Main.java:88: 'class' or 'interface' expected samnachilomo Java Basics 1 December 13th, 2006 09:07 AM
practice help with C++ mastrgamr C++ Programming 2 November 2nd, 2006 07:55 AM
Looking for some practice Vano2005 C++ Programming 2 July 7th, 2005 04:30 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.