By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,261 Members | 1,317 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,261 IT Pros & Developers. It's quick & easy.

Option strict require more casting?

P: n/a
I find there is more casting required in C# than VB.NET. If Option
Strict/Explicit is turned on, will this basically create the same
environment as C# - uppercase, more casting required, must build event
handlers?

Thanks,
Brett
Nov 21 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Brett,

No Option Strict does not make from VBNet a kind of C#. To answer you direct
on your lower/uppercase question. The distinct between uppercase and
lowercase is not CLS compliant. However when used in private values in C
languages no problem.

With option strict on, the casting is exactly the same. However by instance
unsafe code is still not possible with VBNet, while in there stays
background compiling to help you direct with errors and auto complete what
is not in C#.

I hope this helps,

Cor
Nov 21 '05 #2

P: n/a
The only thing it will do is require you to declare your variables and
perform the casts. It does not affect the way event handlers are hooked up
for you (static or dynamic) and has no affect on case sensitivity. It is
highly recommended to Set Explicit ON and Set Option Strict ON for any new
VB.NET project. You may need to set them off when converting old VB6 code or
if you are doing late binding and you know what you are working with.

HTH,
-B

"Brett" <no@spam.com> wrote in message
news:uu**************@TK2MSFTNGP15.phx.gbl...
I find there is more casting required in C# than VB.NET. If Option
Strict/Explicit is turned on, will this basically create the same
environment as C# - uppercase, more casting required, must build event
handlers?

Thanks,
Brett

Nov 21 '05 #3

P: n/a
VB with Option Strict On is actually *more* strict than C#, believe it or
not. That is, C# will let you get away with a lot more implicit casting than
VB with option strict on.

David Anton
www.tangiblesoftwaresolutions.com
Home of the Instant C# VB.NET to C# converter
and the Instant VB C# to VB.NET converter

"Brett" wrote:
I find there is more casting required in C# than VB.NET. If Option
Strict/Explicit is turned on, will this basically create the same
environment as C# - uppercase, more casting required, must build event
handlers?

Thanks,
Brett

Nov 21 '05 #4

P: n/a
Well i have some different thoughts about this
I set Option explicit and Option strict on by default above every code
block and not default in the project cause in some circumstances option
explicit is more a pain in the but and i want to have control over it where
to use it or not

when would i not use option strict ???
Well those of you ever involved in writing a remoting project or writing
there own proxy class for webservices will know why ,,,,, cause there are
situations where late binding is actually handy
and it sure is not bad to use it ... that is why remoting is so much
easier to acomplish in VB as in C#

happy coding

M. Posseth [MCP Developer]

"Beth Massi [Architect MVP]" <bm****@comcast.net> wrote in message
news:eo**************@TK2MSFTNGP10.phx.gbl...
The only thing it will do is require you to declare your variables and
perform the casts. It does not affect the way event handlers are hooked up
for you (static or dynamic) and has no affect on case sensitivity. It is
highly recommended to Set Explicit ON and Set Option Strict ON for any new
VB.NET project. You may need to set them off when converting old VB6 code or if you are doing late binding and you know what you are working with.

HTH,
-B

"Brett" <no@spam.com> wrote in message
news:uu**************@TK2MSFTNGP15.phx.gbl...
I find there is more casting required in C# than VB.NET. If Option
Strict/Explicit is turned on, will this basically create the same
environment as C# - uppercase, more casting required, must build event
handlers?

Thanks,
Brett


Nov 21 '05 #5

P: n/a
I agree. That's why I said you may want to set Option Strict Off if you are
doing late binding. Like it comes in handy when you have to write a lot of
Reflection code too. You just need to be really careful because potential
errors won't spring up until runtime.

"M. Posseth" <mi*****@nohausystems.nl> wrote in message
news:d5**********@reader08.wxs.nl...
Well i have some different thoughts about this
I set Option explicit and Option strict on by default above every code
block and not default in the project cause in some circumstances option
explicit is more a pain in the but and i want to have control over it
where
to use it or not

when would i not use option strict ???
Well those of you ever involved in writing a remoting project or writing
there own proxy class for webservices will know why ,,,,, cause there are
situations where late binding is actually handy
and it sure is not bad to use it ... that is why remoting is so much
easier to acomplish in VB as in C#

happy coding

M. Posseth [MCP Developer]

"Beth Massi [Architect MVP]" <bm****@comcast.net> wrote in message
news:eo**************@TK2MSFTNGP10.phx.gbl...
The only thing it will do is require you to declare your variables and
perform the casts. It does not affect the way event handlers are hooked
up
for you (static or dynamic) and has no affect on case sensitivity. It is
highly recommended to Set Explicit ON and Set Option Strict ON for any
new
VB.NET project. You may need to set them off when converting old VB6 code

or
if you are doing late binding and you know what you are working with.

HTH,
-B

"Brett" <no@spam.com> wrote in message
news:uu**************@TK2MSFTNGP15.phx.gbl...
>I find there is more casting required in C# than VB.NET. If Option
>Strict/Explicit is turned on, will this basically create the same
>environment as C# - uppercase, more casting required, must build event
>handlers?
>
> Thanks,
> Brett
>



Nov 21 '05 #6

P: n/a

Then we speak the same Language :-)

"Beth Massi [Architect MVP]" <bm****@comcast.net> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I agree. That's why I said you may want to set Option Strict Off if you are doing late binding. Like it comes in handy when you have to write a lot of
Reflection code too. You just need to be really careful because potential
errors won't spring up until runtime.

"M. Posseth" <mi*****@nohausystems.nl> wrote in message
news:d5**********@reader08.wxs.nl...
Well i have some different thoughts about this
I set Option explicit and Option strict on by default above every code
block and not default in the project cause in some circumstances option explicit is more a pain in the but and i want to have control over it
where
to use it or not

when would i not use option strict ???
Well those of you ever involved in writing a remoting project or writing
there own proxy class for webservices will know why ,,,,, cause there are situations where late binding is actually handy
and it sure is not bad to use it ... that is why remoting is so much
easier to acomplish in VB as in C#

happy coding

M. Posseth [MCP Developer]

"Beth Massi [Architect MVP]" <bm****@comcast.net> wrote in message
news:eo**************@TK2MSFTNGP10.phx.gbl...
The only thing it will do is require you to declare your variables and
perform the casts. It does not affect the way event handlers are hooked
up
for you (static or dynamic) and has no affect on case sensitivity. It is highly recommended to Set Explicit ON and Set Option Strict ON for any
new
VB.NET project. You may need to set them off when converting old VB6
code or
if you are doing late binding and you know what you are working with.

HTH,
-B

"Brett" <no@spam.com> wrote in message
news:uu**************@TK2MSFTNGP15.phx.gbl...
>I find there is more casting required in C# than VB.NET. If Option
>Strict/Explicit is turned on, will this basically create the same
>environment as C# - uppercase, more casting required, must build event
>handlers?
>
> Thanks,
> Brett
>



Nov 21 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.