Arghhh...strict, but not strict enough
John Whitworth
MSDN.
During the course, I kept wanting to just go home, and switch on Option
Strict, and see what happened. Hmmm...quite a lot of errors, but nothing
insurmountable. Apart from the following error, on the asterisked lines of
code.
Error 1 Option Strict On disallows implicit conversions from
'System.Windows.Forms.ToolStripItem' to
'System.Windows.Forms.ToolStripMenuItem'. C:\Users\John
Whitworth\Documents\Visual Studio 2008\Projects\SCPI 2009\Forms\ScpiMain.vb
120 38 SCPI 2009
Public SelectedReaderMenu As ToolStripMenuItem
Private Sub DetectReader()
Caller = "DetectReader"
szReaderLists = New System.String(Nothing, 1024)
nReaderCount = szReaderLists.Length
lResult = PCSC.SCardListReaders(hContext, mszGroups, szReaderLists,
nReaderCount)
ReadersAvailable = LoadListToMenu(ReaderSelectMenu, szReaderLists)
Select Case ReadersAvailable
Case 0
ReaderStatus.Text = "No Reader Connected"
ConnectButton.Enabled = False
Case Else
SelectedReaderMenu = ReaderSelectMenu.DropDownItems.Item(0)
*********
SelectedReaderMenu.Checked = True
szReaderName = SelectedReaderMenu.Text
ReaderStatus.Text = SelectedReaderMenu.Text
Call ConnectReader(szReaderName)
End Select
End Sub
Private Sub ReaderSelectMenu_DropDownItemClicked(ByVal sender As Object,
ByVal e As System.Windows.Forms.ToolStripItemClickedEventArgs) Handles
ReaderSelectMenu.DropDownItemClicked
ProtocolStatus.Text = ""
SelectedReaderMenu.Checked = False
SelectedReaderMenu = e.ClickedItem *********
SelectedReaderMenu.Checked = True
szReaderName = SelectedReaderMenu.Text
ReaderStatus.Text = SelectedReaderMenu.Text
Call ConnectReader(szReaderName)
ScpiMenu.Refresh()
End Sub
I'm sure it's probably glaringly obvious to someone, but I can't work out
what to do. I can see that a ToolStripItem isn't a ToolStripMenuItem, but
how do I get around this?
Next task is to switch off Microsoft.VisualBasic! :-)
Thanks
John
Patrice
With VB : CType(variable,type)
With C# : (type) variable
--
Patrice
"John Whitworth" <sexyjw@g_EEEEEEEEEEEEEEEEE_mail.com> a écrit dans le
message de groupe de discussion : uUIwhdcu...@TK2MSFTNGP04.phx.gbl...
Armin Zingler
> I'm sure it's probably glaringly obvious to someone, but I can't work
> out what to do. I can see that a ToolStripItem isn't a
> ToolStripMenuItem, but how do I get around this?
If you know that the reference will always reference a ToolStipMenuItem, use
type casting:
SelectedReaderMenu = directcast(e.ClickedItem, toolstripmenuitem)
Armin
John Whitworth
news:uE11Zqcu...@TK2MSFTNGP02.phx.gbl...
> You have to explicitely cast variables :
>
> With VB : CType(variable,type)
> With C# : (type) variable
>
Excellent - thanks Patrice. I now have a clean compile.
John
John Whitworth
news:uvuMWtcu...@TK2MSFTNGP02.phx.gbl...
Thanks Armin - I got there from Patrice's message. But is there a difference
between CType and directcast?
John
Cor Ligthert[MVP]
Cor
"John Whitworth" <sexyjw@g_EEEEEEEEEEEEEEEEE_mail.com> wrote in message
news:ufxIG0cu...@TK2MSFTNGP06.phx.gbl...
Cor Ligthert[MVP]
Did you try already what this does for you
Public SelectedReaderMenu as ToolStripItem
Cor
"John Whitworth" <sexyjw@g_EEEEEEEEEEEEEEEEE_mail.com> wrote in message
news:uUIwhdcu...@TK2MSFTNGP04.phx.gbl...
Armin Zingler
> Thanks Armin - I got there from Patrice's message. But is there a
> difference between CType and directcast?
DirectCast only casts. CType (also) converts if necessary. Even if both lead
to the same (IL) code in this case, I prefer Directcast - personal taste
only - if I want to cast. With CType, the VB compiler generates the code
required to do the conversion in other cases.
The difference between casting and converting is that a conversion creates a
new object while casting just changes the type of the reference.
Armin
Armin Zingler
> DirectCast is always casting while CType can be converting
You are quicker. ;)
Armin
sloan
I had a jr developer who (after I said you gotta turn it STRICT and EXPLICIT
ON) ... got about 239 code breaks.
He had a fun night.
"John Whitworth" <sexyjw@g_EEEEEEEEEEEEEEEEE_mail.com> wrote in message
news:uUIwhdcu...@TK2MSFTNGP04.phx.gbl...
John Whitworth
news:uE4qE8cu...@TK2MSFTNGP03.phx.gbl...
> John,
>
> Did you try already what this does for you
>
> Public SelectedReaderMenu as ToolStripItem
>
> Cor
>
Yes, I had tried that. It threw up errors elsewhere when I tried to access
properties of SelectedReaderMenu.
John
John Whitworth
Ah, OK...thanks all!
JW
(O)enone
> Next task is to switch off Microsoft.VisualBasic! :-)
Why would you want to do that..?
--
(O)enone
Michel Posseth [MCP]
>> Next task is to switch off Microsoft.VisualBasic! :-)
This is mostly said by people who do not understand the big difference
between Microsoft.VisualBasic.Compatibility and The Microsoft.VisualBasic
namespace
To those people i would say please do us and yourself a favor and switch
to C# !
read this
And see my replies on that subject
Michel Posseth
"(O)enone" <oen...@nospam.invalid> schreef in bericht
news:LbODl.25008$mh4....@newsfe19.ams2...
John Whitworth
news:%23hgVvhi...@TK2MSFTNGP06.phx.gbl...
> (O)enone
>
>
>>> Next task is to switch off Microsoft.VisualBasic! :-)
>
>
> This is mostly said by people who do not understand the big difference
> between Microsoft.VisualBasic.Compatibility and The Microsoft.VisualBasic
> namespace
>
>
> To those people i would say please do us and yourself a favor and switch
> to C# !
Yeah...thanks.
Actually, it's a little more constructive than that. I do not wish to move
to C#, but I would like a better understanding of it. By switching off
MS.VB, even if just temporarily, much of the pain of learning C# is taken
away. I.e. I can understand how to do LEFT, VAL etc using the dotnet
framework, rather than the comfortable old VB way, all whilst in the safety
of VB.
JW
Onur Güzel
> You have to explicitely cast variables :
>
> With VB : CType(variable,type)
> With C# : (type) variable
>
> --
> Patrice
Litte addition, for "conversion", also try System.Convert class to
with ConvertToXXX methods to convert whether your target type is
included in Convert class (such as common data types: int32, string,
double, boolean....) or in VB.NET you can also use CStr, CInt,
CDbl...etc... for converting to a commonly used data type.
Onur Güzel
Michel Posseth [MCP]
> I can understand how to do LEFT, VAL etc using the dotnet
> framework, rather than the comfortable old VB way, all whilst in the
> safety of VB.
The Microsoft.VisualBasic namespace isn`t old that is my point
the below is written by
Stephen Weatherford, Developer on the Visual Basic team
and
Cameron Beccario, Developer on the Visual Basic core compiler team
Host: Cameron (Microsoft)
Q: I didn't think the runtime was included if you didn't use it.
A: The VB runtime is always included for every VB program. The VB runtime
not only includes familiar functions like UCase and MsgBox, but also a host
of helper functions that the compiler uses. For example, the VB runtime has
a helper function for converting Strings to Booleans. And the entire
mechanism for latebinding also sits in the VB runtime. Note that the VB
runtime is different than the compatibility library
(Microsoft.VisualBasic.Compatiblity.dll), which you should reference only
when you need it (such as when upgrading your code from VB6 to VB.NET using
the upgrade tool).
Host: Stephen (Microsoft)
Q: Re: the question, "There are two VB namespaces, right? Compatibility and
regular VB?"
A: Let me add to this... There *are* two namespaces--Microsoft.VisualBasic
and Microsoft.VisualBasic.Compatibility. Microsoft.VisualBasic.Compatibility
is only used when you upgrade a VB6 application, and is for backwards
compatibility purposes (it is a separate DLL from
Microsoft.VisualBasic.dll). The Microsoft.VisualBasic namespace, however,
provides the runtime functions for Visual Basic. As Cameron pointed out, you
always get this reference for free (it is different from the VB
compatibility runtime). It is *not* for backwards compatibility, but rather
for current Visual Basic .NET programs.
regards
Michel
"John Whitworth" <sexyjw@g_EEEEEEEEEEEEEEEEE_mail.com> schreef in bericht
news:ODvVKEou...@TK2MSFTNGP05.phx.gbl...
Scott M.
Neither of them convert anything.
DirectCast is used when cating to the true underlying type that a reference
points to and the validity of the cast need not be verified before the cast
of the reference is done.
CType is used when you wish to *attempt* a cast of a reference from one type
to another. CType will first check to see if the cast is possible and then
perform the cast. Note that even if the cast is possible, it still may fail
at runtime due to null references, etc.
Also, CType works with both value and reference types, but DirectCast only
works with Reference Types.
-Scott
"Cor Ligthert[MVP]" <Notmyfi...@planet.nl> wrote in message
news:eD%23Y88cu...@TK2MSFTNGP03.phx.gbl...
Scott M.
NEVER use the legacy Cxyz() conversion methods brought over from VB 6.0.
When casting from a value type to a value type, these functions will result
in additional boxing and unboxing operations that use more CPU cycles and
memory than if you just use the appropriate overloaded Convert.Toxyz()
method.
In general, stay away from all legacy VB 6.0 functions & constants in VB
.NET (even though the code still may compile and *work*) as this code is not
portable to any of the other .NET languages and in many cases results in
more work for the CPU and more memory taken to perform an operation.
-Scott
"Onur Güzel" <kimirai...@gmail.com> wrote in message
news:89a7ad78-18f6-4d91...@o30g2000vbc.googlegroups.com...
Scott M.
duplication of data boxed or unboxed into a new type if your input and
output parametes are reference and value types or vice versa. When both of
the inputs are of the same fundamental type, you just get a cast of the
reference.
A conversion implies that the original data is transformed into something
else and CType doesn't do that. It *can* copy data and put that into a new
type, but it can't convert the data into a new type.
-Scott
"Armin Zingler" <az.n...@freenet.de> wrote in message
news:el6hWBdu...@TK2MSFTNGP05.phx.gbl...
Armin Zingler
> Not really Cor.
>
> Neither of them convert anything.
No, CType does convert if necessary. Otherwise this wouldn't work:
Dim s As Single
Dim i As Integer
s = 3.14
i = CType(s, Integer) 'Or CInt
Variable i will contain the value 3, not a copy of the binary presentation
of the same 4 bytes as in s.
> DirectCast is used when cating to the true underlying type that a
> reference points to and the validity of the cast need not be verified
> before the cast of the reference is done.
That's not true either. The check is done, too. Otherwise you wouldn't get
an InvalidCastException if the cast is invalid.
> CType is used when you wish to *attempt* a cast of a reference from
> one type to another. CType will first check to see if the cast is
> possible and then perform the cast.
DirectCast does the same.
> Note that even if the cast is
> possible, it still may fail at runtime due to null references, etc.
Sorry, not true again. You can cast Nothing to any type. While casting, you
will never get a NullReferenceException at runtime. Only at compile time -
when it is not yet known whether the value is Nothing - you might get an
error due to an invalid assignment.
> Also, CType works with both value and reference types, but DirectCast
> only works with Reference Types.
Right. :-)
In addition, don't forget the user defined CType operator.
Armin
Armin Zingler
> I just wrote about this in another post, but really, you should
> strive to NEVER use the legacy Cxyz() conversion methods brought over
> from VB 6.0.
>
> When casting from a value type to a value type, these functions will
> result in additional boxing and unboxing operations that use more CPU
> cycles and memory than if you just use the appropriate overloaded
> Convert.Toxyz() method.
Cxyz are still valid keywords. They are _not_ legacy VB 6.0 _functions_.
They are not even functions. They are even compiled inline if possible, so
Convert.* is usually more overhead. There is no reason not to use them at
all. At least, CInt() is shorter than CType(,Integer).
> In general, stay away from all legacy VB 6.0 functions & constants in
> VB .NET (even though the code still may compile and *work*) as this
> code is not portable to any of the other .NET languages and in many
> cases results in more work for the CPU and more memory taken to
> perform an operation.
What a strange reason. I would always try to use a language's features to
the full extent. Abstaining from a feature in a language because it doesn't
in a different language that you do not even use at that moment, doesn't
make sense to me.
Armin
Armin Zingler
> What a strange reason. I would always try to use a language's
> features to the full extent. Abstaining from a feature in a language
> because it doesn't in a different language that you do not even use
> at that moment, doesn't make sense to me.
Correction:
...because it doesn't *exist* in a different language...
Michel Posseth [MCP]
Scot
1. There is nothing legacy about common VB.Net syntax
2 . Every .Net coder could just as easy import the VB namespace
Armin is completely right with his statements
Michel Posseth [MCP]
http://www.vbdotnetcoder.com
"Armin Zingler" <az.n...@freenet.de> schreef in bericht
news:eEFg5Stu...@TK2MSFTNGP03.phx.gbl...
John Whitworth
>
>> I can understand how to do LEFT, VAL etc using the dotnet
>> framework, rather than the comfortable old VB way, all whilst in the
>> safety of VB.
>
>
> The Microsoft.VisualBasic namespace isn`t old that is my point
I'm really not sure what you are trying to prove here. I know that the
Microsoft.VisualBasic namespace isn't old. That it is just as optimised as
using a lot of the dotnet stuff, and, according to our tutor last week, the
Microsoft.VisualBasic stuff, in many instances, actually gives better
performance.
But LEFT and VAL have been with me since my Dragon 32 days, with Microsoft
Basic version 1.0. I didn't have a problem with them in 1983, and I don't
have a problem with them in 2009. But just as it is nice to be able to speak
some French when going to France, it is nice to be able to understand what
is going on outside of the VB world too. It was explained to us that there
is a multitude more advice and examples written in dotnet code, mainly in
C#, that even if we don't want to write in C#, it will be beneficial to be
able to read it.
If you want to be a VB purist, then that is fine with me. Just leave me to
try out what I want to do as well.
Cheers
JW
Cor Ligthert[MVP]
I see therefore CType is a shortcut for Convert Type. That is because it
does not convert, that is simple American logic.
They make it so difficult there in America for people outside the USA.
Although this page state something else, can it be that CType is to convert
and cast as that is possible instead.
http://msdn.microsoft.com/en-us/library/kca3w8x6.aspx
Cor
"Scott M." <s-...@nospam.nospam> wrote in message
news:uVmvb7su...@TK2MSFTNGP06.phx.gbl...
Cor Ligthert[MVP]
C# has simple less functions as Visual Basic, while C has not even a string.
It are in those languages simple parts of classes that you use. Visual Basic
gives you two possibilities, use the members of classes but beside that it
gives you optimized functions which do often almost the same.
Without those functions, which are a part of the Visual Basic language, VB
is simple not Visual Basic. It is like using the English language but tell
that you should use colour instead of color in the USA.
Cor
"John Whitworth" <sexyjw@g_EEEEEEEEEEEEEEEEE_mail.com> wrote in message
news:eBVVJ5vu...@TK2MSFTNGP02.phx.gbl...
John Whitworth
> John,
>
> C# has simple less functions as Visual Basic, while C has not even a
> string.
>
> It are in those languages simple parts of classes that you use. Visual
> Basic gives you two possibilities, use the members of classes but beside
> that it gives you optimized functions which do often almost the same.
>
> Without those functions, which are a part of the Visual Basic language, VB
> is simple not Visual Basic. It is like using the English language but
> tell that you should use colour instead of color in the USA.
Yes, all understood. But are you trying to tell me that just temporarily
cutting the apron strings, and forcing myself out of my comfort zone is a
bad thing?
All I hear on this thread is that trying to do anything in a way that isn't
VB is tantamount to heresy, and that anyone who wants to learn or understand
C# should just 'go away'!!
JW
Michel Posseth [MCP]
Hello John
First of all i am not a native english speaker and i do not know , how you
interpreted my reply to you but it sure wasn`t intended to drive you away
from this group
however we do have a lot of VB bashers coming here and maybe your sentence
>" Next task is to switch off Microsoft.VisualBasic! :-) " has triggered my
VB bash alert
but....
> Yes, all understood. But are you trying to tell me that just temporarily
> cutting the apron strings, and forcing myself out of my comfort zone is a
> bad thing?
No this isn`t bad at all , it is a good thing to understand the framework
classes
> All I hear on this thread is that trying to do anything in a way that
isn't
> VB is tantamount to heresy,
Well you are here in the VB.Net group , so it isn`t strange if experienced
VB.Net coders tell you to do it the VB.Net way
>and that anyone who wants to learn or understand C# should just 'go
>away'!!
Well i can program C# to , but have not learned it by cripling VB , if you
know the framework and can live with weird variable declaration and all the
horror of curly braces
then C# isn`t so hard at all for a experienced VB.Net progger , i would
recomend you to install redgate reflector and convert some classes back and
forwards to VB - C#
this would teach you a lot more . Also just start coding a few simple
programs in C# that you have also written in VB.Net then you see the
differnces pretty good
And yes if you favor C# or have questions about C# ( cause you notice that
certain things that were so easy in VB.Net are now so hard to do ) it would
be a good idea to switch to a C# group
I am pretty active in this group now for years and noticed that the people
who moved from VB ( 6 or .Net ) to C# become the biggest VB bashers we VB
people use the The Microsoft.VisualBasic namespace as it gives us a higher
productivity and it is what Visual Basic makes Visual Basic . And again NO
it isn`t there for backwards compatibility purposes in some situations they
even behave different as there counterpart legacy methods .
michel
"John Whitworth" <sexyjw@g_EEEEEEEEEEEEEEEEE_mail.com> schreef in bericht
news:%23tQd2m1...@TK2MSFTNGP05.phx.gbl...
Cor Ligthert[MVP]
It has nothing to do with C# or with VB.
There are namespaces, most of them starts in the namespace System and some
of them starts in the namespace Microsoft.
You can use those namespaces in any managed code Net language.
There is not any thing against it by using those in C# or C++ when you set a
reference to them, while that is by default done in Visual Basic.
There is in my opinion one disadvantage in using the Microsoft.VisualBasic
namespace, that is that it is compatible to every version of Visual Basic
which means that the indexer start at the first instead and not on the Zero.
Theoretical correct but in computing most people stayed from the days of
machine code using the zero as the first index number.
The Microsoft Visual Basic namespace keeps using the first as the indexer. I
am not comming from VB6, that is why I although it is theoretical correct
avoid those functions from Visual Basic. (This avoid not by instance Cint,
etc, Chrw) but very much the Find and the Mid.
Cor
"John Whitworth" <sexyjw@g_EEEEEEEEEEEEEEEEE_mail.com> wrote in message
news:%23tQd2m1...@TK2MSFTNGP05.phx.gbl...
John Whitworth
>
> Hello John
>
>
> First of all i am not a native english speaker and i do not know , how you
> interpreted my reply to you but it sure wasn`t intended to drive you away
> from this group
> however we do have a lot of VB bashers coming here and maybe your sentence
> >" Next task is to switch off Microsoft.VisualBasic! :-) " has triggered
> >my
> VB bash alert
OK - I think we are agreed. I will never become a VB-basher, so you needn't
worry. I have spent an absolute age defending VB against the C++ programmers
who think that C# must be so much superior.
Anyway - Happy Easter!
John
Scott M.
These functions may exist in Microsoft.VisualBasic, but that doesn't make
them the best vehicle to use.
They exist because legacy VB code relied on them and MS didn't want to
alienate the millions of VB developers that might want to come to .NET.
They are less effiecient (not more as Armin suggests) than their .NET
counterparts in many cases, they don't follow OO syntax, and aren't portable
to other .NET languages.
In short, the only reason to use them is that you may be used to using them.
-Scott
"Michel Posseth [MCP]" <ms...@posseth.com> wrote in message
news:eq6shEvu...@TK2MSFTNGP05.phx.gbl...
Scott M.
In your first example, there is new data created for the variable i that is
the integer representation of the s data, the s data is not directly
converted or affected. In my opinion, the term "converted" means that the
data in a memory location is directly modified to new data. That's not what
happens with CType. A new memory location is created with the desired data.
As for DirectCast, my description IS correct: "DirectCast does not include
any logic to actually check for and convert an objet to the requested type",
while CType does. This is because DirectCast is meant to be used in
situations where the type to be converted is already known to be the same
type as the target type and that's why it performs better (Professional
Visual Basic 2008; Bill Evjen - WROX, page 47).
My point about CType erroring out is that although it does perform a check
to see if the types are compatible, it can still error out at runtime (as
you point out).
-Scott
"Armin Zingler" <az.n...@freenet.de> wrote in message
news:O3hb4Stu...@TK2MSFTNGP03.phx.gbl...
Scott M.
IMHO the term "convert" is thrown around too easily. Convert implies that a
thing is transformed into a different thing. like a person can convert their
religion, they may do that, but they remain the same person.
That's not what happens with CType. With CType, you may get a duplication
of the original data, but with a different type of reference variable
pointing to that new data.
I just think that the term "convert" is used (even by Microsoft)
incorrectly. It gives the impression that something other that what is
actually happening is taking place.
-Scott
"Cor Ligthert[MVP]" <Notmyfi...@planet.nl> wrote in message
news:Ooaq29vu...@TK2MSFTNGP04.phx.gbl...
Scott M.
make as well, but I would disagree with one statement that your teacher has
made to you. None of the Microsoft.VisualBasic functions are going to work
better than their .NET Framework counterparts, quite the contrary. Ask your
tutor to explain how using CLng(10) is more effiecient than
Convert.ToInt64(10). It isn't, not by a long shot because CLng will have to
box the integer 10 into an object then unbox it into a long when it's done.
The Convert class's overlaoded methods don't do that.
This misinformation is generally spread by those VB purists who just can't
let go of the way they've always done things.
-Scott
"John Whitworth" <sexyjw@g_EEEEEEEEEEEEEEEEE_mail.com> wrote in message
news:eBVVJ5vu...@TK2MSFTNGP02.phx.gbl...
Scott M.
> John,
>
> C# has simple less functions as Visual Basic, while C has not even a
> string.
>
> It are in those languages simple parts of classes that you use. Visual
> Basic gives you two possibilities, use the members of classes but beside
> that it gives you optimized functions which do often almost the same.
Exactly what is optimized Cor? Tell me exactly what Microsoft.VisualBasic
has in it that is more efficient than the non VB.NET elements of the
framework. I think (if memory serves) there may be 1 or 2 items, but that
hardly justifies using all of this legacy stuff. VB had about 100 built-in
functions that were data type specific. .NET has replaced the need for all
of them with methods of types.
-Scott
Armin Zingler
> I disagree.
>
> These functions may exist in Microsoft.VisualBasic, but that doesn't
> make them the best vehicle to use.
No, they do not exist in MSVB namespace because they are not functions. They
are built-in VB language keywords just like If, Do, Select Case. The
compiler generates the appropriate code to perform the operation. This can
be type casting (IL "castclass"), or in the example that I've shown
Dim s As Single
Dim i As Integer
s = 3.14
i = CType(s, Integer) 'Or CInt
it generates a call to Math.Floor and a conversion of the rounded value to
integer (IL "conv.ovf.i4").
> They exist because legacy VB code relied on them and MS didn't want to
> alienate the millions of VB developers that might want to come to
> .NET. They are less effiecient (not more as Armin suggests) than
> their .NET counterparts in many cases, they don't follow OO syntax,
> and aren't portable to other .NET languages.
int i = (int) floatvalue;
"(int)" conversion does not work in VB either, so you really recommend not
to use it in C#?
Right, this has nothing to do with OO. Not every line in a source code file
is an OO operation. Still it's an OO language and it's still OOP.
The Cxyz keyword family has even been enhanced to support other types like
CUInt or CUShort.
There are about 40-50 lines of IL code for Convert.ToInt32(float) while
Math.Floor is as short as it can be compiled inline.
> In short, the only reason to use them is that you may be used to
> using them.
I use them because they are often the straightest way to do what I wanna do.
Armin
Armin Zingler
> Sorry Armin, I have to disagree with your assesments here.
>
> In your first example, there is new data created for the variable i
> that is the integer representation of the s data, the s data is not
> directly converted or affected. In my opinion, the term "converted"
> means that the data in a memory location is directly modified to new
> data. That's not what happens with CType.
IMO, conversion means
input object -> conversion -> output object
If it's type safe to store the output object in the same location as the
input object came from, it _can_ be stored there but it doesn't have to be.
> A new memory location is
> created with the desired data.
If I put another GB of RAM, then I create new memory locations. ;-) There is
no other way to create new space for data. You always have to overwrite
something, be it in RAM, in a CPU register, on HD,...
> As for DirectCast, my description IS correct: "DirectCast does not
> include any logic to actually check for and convert an objet to the
> requested type", while CType does. This is because DirectCast is
> meant to be used in situations where the type to be converted is
> already known to be the same type as the target type and that's why
> it performs better (Professional Visual Basic 2008; Bill Evjen -
> WROX, page 47).
> My point about CType erroring out is that although it does perform a
> check to see if the types are compatible, it can still error out at
> runtime (as you point out).
Try it and see this is wrong.
Dim o As Form
Dim c As Control
c = Me
o = DirectCast(c, Form)
o = CType(c, Form)
The directcast line is tranlated to:
IL_001f: ldloc.0
IL_0020: castclass [System.Windows.Forms]System.Windows.Forms.Form
IL_0025: stloc.2
The CType line is translated to:
IL_0026: ldloc.0
IL_0027: castclass [System.Windows.Forms]System.Windows.Forms.Form
IL_002c: stloc.2
I don't see a difference.
Armin
Armin Zingler
> I agree with your sentiment John, and that's the point I've been
> trying to make as well, but I would disagree with one statement that
> your teacher has made to you. None of the Microsoft.VisualBasic
> functions are going to work better than their .NET Framework
> counterparts, quite the contrary.
Concerning Microsoft.VisualBasic, this is a different issue. But, (as
already said), Cxyz are keywords, not functions in that namespace. IIRC, the
only thing from the MSVB namespace I use is "Msgbox". Different subject
anyway.
> Ask your tutor to explain how
> using CLng(10) is more effiecient than Convert.ToInt64(10). It
> isn't, not by a long shot because CLng will have to box the integer
> 10 into an object then unbox it into a long when it's done.
I don't know where your "boxing" knowledge comes from. It's plain wrong.
CLng is compiled inline:
dim l as integer
l = clng(10)
IL_0030: ldc.i4.s 10
IL_0032: conv.i8
IL_0033: stloc.2
while Convert.ToInt64 requires a function call. (which _can_ be optizmized
by being comipiled as inline machine code in this case. Though, why call a
function if the language offers a keyword that does the same?)
> The
> Convert class's overlaoded methods don't do that.
> This misinformation is generally spread by those VB purists who just
> can't let go of the way they've always done things.
In this case, you are misinformed.
Armin
Scott M.
> Scott M. wrote:
>> I disagree.
>>
>> These functions may exist in Microsoft.VisualBasic, but that doesn't
>> make them the best vehicle to use.
>
> No, they do not exist in MSVB namespace because they are not functions.
> They are built-in VB language keywords just like If, Do, Select Case. The
> compiler generates the appropriate code to perform the operation. This can
> be type casting (IL "castclass"), or in the example that I've shown
>
> Dim s As Single
> Dim i As Integer
> s = 3.14
> i = CType(s, Integer) 'Or CInt
>
> it generates a call to Math.Floor and a conversion of the rounded value to
> integer (IL "conv.ovf.i4").
I'm not sure what your point is here. Ok, I used the term "function". The
point is that they are unecssary.
>
>> They exist because legacy VB code relied on them and MS didn't want to
>> alienate the millions of VB developers that might want to come to
>> .NET. They are less effiecient (not more as Armin suggests) than
>> their .NET counterparts in many cases, they don't follow OO syntax,
>> and aren't portable to other .NET languages.
>
> int i = (int) floatvalue;
>
> "(int)" conversion does not work in VB either, so you really recommend not
> to use it in C#?
No, because in C#, there is no alternative. In VB.NET you have a choice, a
choice that opens your code up to flaws.
>
> Right, this has nothing to do with OO. Not every line in a source code
> file is an OO operation. Still it's an OO language and it's still OOP.
True, but CInt(10) is not as OO as it could be: Convert.ToInt16(10)
>
> The Cxyz keyword family has even been enhanced to support other types like
> CUInt or CUShort.
And, your point?
>
> There are about 40-50 lines of IL code for Convert.ToInt32(float) while
> Math.Floor is as short as it can be compiled inline.
I see that with ToInt32(float64), not ToInt32(float). But, reduced IL is
not always the best indicator of best performance - you must take memory
into account as well. Unnecessary Boxing/Unboxing results in additional
memory overhead as well as the CPU time to allocate that memory and update
the pointer table.
>
>> In short, the only reason to use them is that you may be used to
>> using them.
>
> I use them because they are often the straightest way to do what I wanna
> do.
And, that's why Microsoft includes them. Not because they are the best
choice.
>
>
> Armin
Scott M.
Nor, did I say you would. The resulting IL doesn't tell you how the IL was
gotten. Your simply saying that in your particular example, the results of
DirectCast and CType are the same. I'm talking about how the results are
obtained, not the results themselves. DirectCast (as its name implies) does
not contain any logic for checking and doing *conversions* it just attempts
the cast the reference to the requested type. This is why DirectCast is
more efficient in certain situations than CType. I never said you'd get a
different result than with CType.
-Scott
>
>
> Armin
Scott M.
I'll leave that possibility open, but there is a lot of documentation that
says otherwise (including the reference I already gave you).
If you simply look at the signature of any of the Cxyz() functions (yes,
functions), you'll see that they are set up to take in any "object" type.
If you pass in a value type, that value type MUST be implicitly boxed into
an object for the compiler to accept the argument. Just as clear is that if
the Cxyz() call was supposed to return a value type (like integer), then the
previously boxed value will now have to be implicitly unboxed to get your
data out of the function.
Here's an interesting article about DirecCast, which backs up my point that
DirectCast has less overhead than CType, but also it refers to the elements
that I've been calling functions as "functions".
http://www.panopticoncentral.net/archive/2003/07/10/149.aspx
-Scott
>
>
> Armin
Herfried K. Wagner [MVP]
"Scott M." <s-...@nospam.nospam> schrieb:
>> In this case, you are misinformed.
>
> I'll leave that possibility open, but there is a lot of documentation that
> says otherwise (including the reference I already gave you).
>
> If you simply look at the signature of any of the Cxyz() functions (yes,
> functions), you'll see that they are set up to take in any "object" type.
They are called functions, but actually they do not necessarily lead to
function calls.
From "Visual Basic Language Reference", "Type Conversion Functions",
<URL:http://msdn.microsoft.com/en-us/library/s2dy91zy.aspx>:
| These functions are compiled inline, meaning the conversion code
| is part of the code that evaluates the expression. Sometimes there
| is no call to a procedure to accomplish the conversion, which improves
| performance. Each function coerces an expression to a specific data type.
Thus I'd strongly recommend to use 'CInt' instead of 'Convert.ToInt32' if no
additional features 'Convert.ToInt32' provides are needed.
> If you pass in a value type, that value type MUST be implicitly boxed into
> an object for the compiler to accept the argument.
No! The 'C*' conversion operators are not implemented as simple function
calls. If you take a closer look at them, you'll see that they are colored
as keywords and that the IDE does not support "Go to definition" for the
conversion operators.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
Herfried K. Wagner [MVP]
>> C# has simple less functions as Visual Basic, while C has not even a
>> string.
>>
>> It are in those languages simple parts of classes that you use. Visual
>> Basic gives you two possibilities, use the members of classes but beside
>> that it gives you optimized functions which do often almost the same.
>
> Exactly what is optimized Cor? Tell me exactly what Microsoft.VisualBasic
> has in it that is more efficient than the non VB.NET elements of the
> framework.
IMO optimized for ease of use. 'MsgBox', for example, is much easier to use
than 'MessageBox.Show' with its whole set of overloads.
Cor Ligthert[MVP]
> I just think that the term "convert" is used (even by Microsoft)
> incorrectly. It gives the impression that something other that what is
> actually happening is taking place.
>
discussion.
Cor
Armin Zingler
>>> I disagree.
>>>
>>> These functions may exist in Microsoft.VisualBasic, but that doesn't
>>> make them the best vehicle to use.
>>
>> No, they do not exist in MSVB namespace because they are not
>> functions. They are built-in VB language keywords just like If, Do,
>> Select Case. The compiler generates the appropriate code to perform
>> the operation. This can be type casting (IL "castclass"), or in the
>> example that I've shown Dim s As Single
>> Dim i As Integer
>> s = 3.14
>> i = CType(s, Integer) 'Or CInt
>>
>> it generates a call to Math.Floor and a conversion of the rounded
>> value to integer (IL "conv.ovf.i4").
>
> I'm not sure what your point is here. Ok, I used the term
My point was to give you an example for what the compiler makes out of CType
in order to show you that they are not framework functions. But I see you
got it now. :-)
> The point is that they are unecssary
Why is something useful unnecessary? For-Next is unncessary too because you
can do the same with Do-Loop. Though, it's there, and not only for historic
reasons. It simplifies things.
I'd agree with you with the most MSVB classes/functions (because it's just
an indirection), and even more with most things in the My.Crap namespace,
but in this case, I don't know why remove basic keywords.
>>> They exist because legacy VB code relied on them and MS didn't want
>>> to alienate the millions of VB developers that might want to come to
>>> .NET. They are less effiecient (not more as Armin suggests) than
>>> their .NET counterparts in many cases, they don't follow OO syntax,
>>> and aren't portable to other .NET languages.
>>
>> int i = (int) floatvalue;
>>
>> "(int)" conversion does not work in VB either, so you really
>> recommend not to use it in C#?
>
> No, because in C#, there is no alternative. In VB.NET you have a
> choice, a choice that opens your code up to flaws.
I don't understand this. In C# you also have the choice to call
Convert.ToInt32. Which flaws do you mean?
In VB you have the choice to use CInt or Convert.ToInt32.
In C# you have the choice to use (int) or Convert.ToInt32.
I don't see any difference in the situation.
>> Right, this has nothing to do with OO. Not every line in a source
>> code file is an OO operation. Still it's an OO language and it's
>> still OOP.
>
> True, but CInt(10) is not as OO as it could be: Convert.ToInt16(10)
So what? I also use "if a=b" and not "if a.equals(b)" because it's so basic.
I'm still an OO proponent.
>> The Cxyz keyword family has even been enhanced to support other
>> types like CUInt or CUShort.
>
> And, your point?
It Cxyz was only there because we were used to it, there wouldn't be a
reason to introduce new Cxyz keywords. No, they have been added because
these are still valid keywords.
>> There are about 40-50 lines of IL code for Convert.ToInt32(float)
>> while Math.Floor is as short as it can be compiled inline.
>
> I see that with ToInt32(float64), not ToInt32(float). But, reduced
> IL is not always the best indicator of best performance - you must
> take memory into account as well. Unnecessary Boxing/Unboxing
> results in additional memory overhead as well as the CPU time to
> allocate that memory and update the pointer table.
I don't see any boxing here. Boxing means putting a value type into the heap
and holding a reference to that object. I can also image that 50 lines of IL
code are improbably faster than 3 lines.
>>> In short, the only reason to use them is that you may be used to
>>> using them.
>>
>> I use them because they are often the straightest way to do what I
>> wanna do.
>
> And, that's why Microsoft includes them. Not because they are the best
> choice.
Depends on what you consider "best". :-)
Armin
Armin Zingler
news:%23yy$Ea4uJH...@TK2MSFTNGP04.phx.gbl...
Then I don't see the point. You said DirectCast doesn't check before casting
while CType does the check. Now you write there is no difference.
Armin
Armin Zingler
>> In this case, you are misinformed.
>
> I'll leave that possibility open, but there is a lot of documentation
> that says otherwise (including the reference I already gave you).
>
> If you simply look at the signature of any of the Cxyz() functions
> (yes, functions), you'll see that they are set up to take in any
> "object" type. If you pass in a value type, that value type MUST be
> implicitly boxed into an object for the compiler to accept the
> argument.
Ah, now I see what you mean. Well, you misinterpreted this. If Cxyz were
functions, you would have been right. But as they are keywords, the compiler
knows how to handle whatever type is used with Cxyz. In addition, if you
have a closer look, after typing "CInt("), intellisense says:
"object As Expression".
Well, Expression is not a type name, it's an...expression.
> Just as clear is that if the Cxyz() call was supposed to
> return a value type (like integer), then the previously boxed value
> will now have to be implicitly unboxed to get your data out of the
> function.
If it's not necessary, nothing will be boxed.
> Here's an interesting article about DirecCast, which backs up my
> point that DirectCast has less overhead than CType, but also it
> refers to the elements that I've been calling functions as
> "functions".
> http://www.panopticoncentral.net/archive/2003/07/10/149.aspx
I've searched for "function" in the article but didn't find it related to
the Cxyz keywords.
I didn't say, Cxyz won't involve any function calls, but _if possible_, they
are omitted. The example with the Arraylist is one of those where conversion
may be necessary at runtime. Concerning boxing, it is necessary because an
Arraylist can contain any type of object, including value types. But this
has nothing to do with the Cxyz thing.
BTW, I wouldn't use
i = CInt(a(0))
in this case anyway. Even if I knew the value in the Arraylist is Double,
I'd write
i = CInt(DirectCast(a(0), Double))
Long story short: is there a function that does the same as, for example,
CInt does? Don't forget those special features like CInt("&H1234") which
also works. This _must_ be VB specific because the "&H" prefix is inferred
from the hex literals in VB source code.
Armin
Armin Zingler
> CType is not short for "convert" to a type. It's short for "cast" to
> type.
You can _never_ cast a Single value to an Int32 value. Nevertheless,
CType(singlevalue, Int32) works. So, if CType only meant casting, how would
you explain this?
> IMHO the term "convert" is thrown around too easily. Convert implies
> that a thing is transformed into a different thing. like a person can
> convert their religion, they may do that, but they remain the same
> person.
How can you "transform" a thing? A person will always be a person. An
Integer will always be an Integer. You _never_ can change the type of an
object. Not with type safe programming. You can only convert an object
to another object (by creating a new object). That's what CType does. Or
it casts, if possible. The "C" in "CType" stands for both: Cast and Convert.
> That's not what happens with CType. With CType, you may get a
> duplication of the original data, but with a different type of
> reference variable pointing to that new data.
No. This is neither correct when casting is done, nor if conversion is
necessary:
- if casting is done, *there is no new data*
- if conversion is done, the new data is *not* a duplication of the original
data (because then an assignment would have been sufficient)
Your understanding of conversion seems to be "unsafe casting".
Armin
J.B. Moreno
Scott M. <s-...@nospam.nospam> wrote:
> CType is not short for "convert" to a type. It's short for "cast" to type.
>
> IMHO the term "convert" is thrown around too easily. Convert implies that a
> thing is transformed into a different thing. like a person can convert their
> religion, they may do that, but they remain the same person.
No, that's what it means when referring to some things, not always.
For instance, currency conversion seldom involves transforming the
actual pieces of paper and when it does its called counterfeiting.
> That's not what happens with CType. With CType, you may get a duplication
> of the original data, but with a different type of reference variable
> pointing to that new data.
>
> I just think that the term "convert" is used (even by Microsoft)
> incorrectly. It gives the impression that something other that what is
> actually happening is taking place.
I think your definition of covert is too narrow. You seem to be
limiting it to loosely typed languages. In a strongly typed language
it's impossible to change the original data. The memory location used
by an integer variable will always treat treated as an integer by the
program, the memory location used by a character will always be treated
like a character.
(Not to mention that "thing" is rather imprecise when talking about
computer programs, do you mean the value on the stack or in the heap or
the value in the register?)
--
J.B. Moreno