VB and implicit conversions

  • Thread starter Thread starter Chad Z. Hower aka Kudzu
  • Start date Start date
C

Chad Z. Hower aka Kudzu

I have an implicit conversion set up in an assembly from a Stream to
something else. In C#, it works. In VB it does not.

Does VB support implicit conversions? And if so any idea why it would work in
a C# program but not VB?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
Chad,

no, VB doesn't support implicit castings in the current version. That is, it
doesn't support implicit castings from non-primitive types. Only Whidbey
will support that (and hopefully it will be produce code that is compatible
with the code generated by C# when using the implicit operator); in the
meanwhile, you have to use the DirectCast keyword to unbox an object.

Klaus
 
Klaus Löffelmann said:
Whidbey will support that (and hopefully it will be produce code that is
compatible with the code generated by C# when using the implicit
operator); in the meanwhile, you have to use the DirectCast keyword to
unbox an object.
Click to expand...

Ack. :(

I understand that there are differences between VB and C#. But how can MS
leave someting like this out? Esp from VB, the king language of anti type
safety. Where you could string = integer. :(

Can you give me an example of DirectCast?



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
Hi Kudzu,

Inclusive the integer to string, although it is originaly Armin territory
because of that sample.
:-))

Dim a As Object
a = 1
Dim b As Integer
b = DirectCast(a, Integer)
MessageBox.Show(b.ToString)

Cor
 
Chad,



I wouldn't call VB the king language of anti type safety. At least, not
anymore. And, of course, only if you set



Option Strict True



at the beginning of each source file or in the project settings.With this
setting, you can only cast those types implicitly, which are implicitly
castable in C#, too.



To provide more background: VB internally uses a special flag to recognize a
type for casting implicitly. When you write a static operator implicit
function with C#, C# generates a procedure called op_implicit, if I remember
correctly. You can use this function from VB, too, but only by this name (so
it's not implicitly usable, obviously...)



However, you can't set the flag from C# (and, unfortunately, neither from
VB), so a type conversion could be done implicitly from VB.

But DirectCast works fine in VB:



Dim var as mySpecialObject=DirectCast(specialObjectBoxedInWhatEverType,
mySpecialObject)



Keep in mind, that DirectCast only does the same as the cast operator does
in C#: (In this example specialObjectBoxedInWhatEverType boxed an object of
type mySpecialObject). It just unboxes a type. If you really want to do a
type conversion from one type to another, you should provide a constructor
with a parameter for your class, you could use like this:



Dim var as new mySpecialObject(OtherSpecialObjectToCastFrom).



In the constructor for mySpecialObject provide the code for the actual
conversion.



Klaus.
 
Armin Zingler said:
Code?
Click to expand...

Its the very last VB example here:
http://www.atozed.com/indy/Texts/VSIntro.iwp

You can see the C# version directly above it. The parameter type to the Get
method is Borland.VCL.Classes.TStrings, which has an implict operator added
to it that allows conversion to it from System.IO.Stream.

It looks like VB users might have to do direct conversions, which at least is
easyer than the DirectBox exmaple posted here.

That is something like:

new TCLRStream(MyStream)

instead of just:

MyStream

whenever TStrings is needed.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
Chad Z. Hower aka Kudzu said:
Its the very last VB example here:
http://www.atozed.com/indy/Texts/VSIntro.iwp

You can see the C# version directly above it. The parameter type to
the Get method is Borland.VCL.Classes.TStrings, which has an implict
operator added to it that allows conversion to it from
System.IO.Stream.

It looks like VB users might have to do direct conversions, which at
least is easyer than the DirectBox exmaple posted here.

That is something like:

new TCLRStream(MyStream)

instead of just:

MyStream

whenever TStrings is needed.
Click to expand...

What is an "implicit operator"? Currently I don't understand the problem.
I'm happy now that I have to cast explicitly, otherwise casting errors might
occur at runtime because I don't get a error message at compile time.


--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html
 
Klaus Löffelmann said:
I wouldn't call VB the king language of anti type safety. At least, not
anymore. And, of course, only if you set
Click to expand...

Yes, its been cleaned up in .net. I just find it ironic that traditionaly
VB has been anything but typesafe, in fact explicitly breaking it. And now
that they've cleaned it up, they gave C# implicit covnersion, but not VB.
Option Strict True
Click to expand...

Yes I have this. But its my understanding that this applies to being able
to put integers into short ints, and the type off poor variations that VB
used to be rampant with.
at the beginning of each source file or in the project settings.With
this setting, you can only cast those types implicitly, which are
implicitly castable in C#, too.
Click to expand...

But it applies only to ordinals, etc AFAIK.
To provide more background: VB internally uses a special flag to
recognize a type for casting implicitly. When you write a static
operator implicit function with C#, C# generates a procedure called
op_implicit, if I remember correctly. You can use this function from VB,
too, but only by this name (so it's not implicitly usable, obviously...)
Click to expand...

Yes, exactly. :)
However, you can't set the flag from C# (and, unfortunately, neither
from VB), so a type conversion could be done implicitly from VB.
Click to expand...

Exactly the problem it seems. :(
But DirectCast works fine in VB:

Dim var as mySpecialObject=DirectCast(specialObjectBoxedInWhatEverType,
mySpecialObject)
Click to expand...

specialObjectBoxedInWhatEverType would be in my case System.IO.Stream
(Source) or Borland.VCL.Classes.TStrings (Destination)?
Keep in mind, that DirectCast only does the same as the cast operator
does in C#: (In this example specialObjectBoxedInWhatEverType boxed an
object of type mySpecialObject). It just unboxes a type. If you really
Click to expand...

Is this the destination type or the source tyep though?
want to do a type conversion from one type to another, you should
provide a constructor with a parameter for your class, you could use
like this:
Click to expand...

Already have that, and thats what the implicit operator does. However the
point is that this conversion is used often to pass in an argument, and the
idea was to free the user from needing to know there was even a difference.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
Armin Zingler said:
What is an "implicit operator"? Currently I don't understand the
problem. I'm happy now that I have to cast explicitly, otherwise casting
errors might occur at runtime because I don't get a error message at
compile time.
Click to expand...

An implicit conversion is performed by an implicit operator in C#.

That is when I need to convert between two types, .net "asks" the destination
if it know how to convert the source into a compatible type. This is how the
ordinal types work internally.

You could never get them at runtime - C# resolves them at compile time and
only allows conversions that have "handlers" to do so. Basically C# auto
"casts" (its not truly cast in the traditional sense, but more of a
conversion) to the other type.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
Chad Z. Hower aka Kudzu said:
An implicit conversion is performed by an implicit operator in C#.

That is when I need to convert between two types, .net "asks" the
destination if it know how to convert the source into a compatible
type. This is how the ordinal types work internally.

You could never get them at runtime - C# resolves them at compile
time and only allows conversions that have "handlers" to do so.
Basically C# auto "casts" (its not truly cast in the traditional
sense, but more of a conversion) to the other type.
Click to expand...

Thanks for the explanation. I know too little about C#
 
Chad,

see inlines...

Klaus

Chad Z. Hower aka Kudzu said:
Yes, its been cleaned up in .net. I just find it ironic that traditionaly
VB has been anything but typesafe, in fact explicitly breaking it. And now
that they've cleaned it up, they gave C# implicit covnersion, but not VB.


Yes I have this. But its my understanding that this applies to being able
to put integers into short ints, and the type off poor variations that VB
used to be rampant with.


But it applies only to ordinals, etc AFAIK.


Yes, exactly. :)


Exactly the problem it seems. :(


specialObjectBoxedInWhatEverType would be in my case System.IO.Stream
(Source) or Borland.VCL.Classes.TStrings (Destination)?


Is this the destination type or the source tyep though?
Click to expand...

mySpecialObject is the one, you like other types being casted to.
Further provide Toxxx-Methods for your "Special"-Object, to cast them back
to other types, and your done!
Already have that, and thats what the implicit operator does. However the
point is that this conversion is used often to pass in an argument, and the
idea was to free the user from needing to know there was even a
Click to expand...
difference.

But wouldn't you then create a "new old Visual Basic" behaviour, that you
don't like? I think, explicit casting does more for type safety than
implicit casting?!
 
Klaus Löffelmann said:
mySpecialObject is the one, you like other types being casted to.
Further provide Toxxx-Methods for your "Special"-Object, to cast them
Click to expand...
back

Defeats the purpose unfortunately. It requires the user to interact
directly with the destination type.
But wouldn't you then create a "new old Visual Basic" behaviour, that you
don't like? I think, explicit casting does more for type safety than
implicit casting?!
Click to expand...

No, because behaviour is well defined and among truly convertible types.
Formerly in VB you could do 2 + 2 + 1 and sometimes get 23 because of the
rules of conversion of data types when added / concatted. And the fact that
concat and add were the same symbol. | was only added later and they still
preverved +.

These conversions are well defined with rules about what can go where, and
do not create commonly abmigous circumstance. They also do not allow data
loss, or if they do they have strict rules about it and only at the
override of the user.

Im all too well acquainted with VB prior to .net.

I know I will offend some people - but VB *was* a horrible mess of a
language. VB.net finally fixed things - but unfortunately MS also seems to
have just tinkered in some spots too for no reason.

I started work in VB 1 for DOS, long before most of you probably ever heard
of VB. Prior to that in PDS which was VB's successor, at least in language.

I've worked very heavily in VB all the way up to 4 and did some work in 5
and 6 as well.

VB 3 was a decent language with some pitfalls. As a very active VB person
at the time and regular VB magazine contributor I was with the rest of the
community hopeful. But then MS totally let us down with 4.

VB4 was not only incredibly buggy (Curse of MS and version 4) but it was
abboration. They should have taken this opportunity to fix some of the
issues in VB3 as a langauge. Instead they did not fix them, but actually
took the language BACKWARDS.

I went Delphi as it came out at the same time. It had everything VB4 should
have had and more.

Its nice to see that VB.net has finally "Fixed" VB.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
And dont even get me started on the fact that VB had a "Option Implicit" in
it - let alone that it was the DEFAULT.

The number of bugs that this leads to is truly incredible, and only has a
place in scripting languages, if that.

Any mispelled variable becomes a new instance and instantly evaluates to 0.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
Thanks. This works, but its not really much better.

LHTTP.Get("http://www.atozed.com", DirectCast(LOutput,
Borland.Vcl.Classes.TStream))

As to you question of "isnt this the behaviour you hate?". The above would
not work if the two types were not compatible right? Well in C#, the same is
possible - but it does it automatically (And again, only if permitted):

LHTTP.Get("http://www.atozed.com", LOutput);

The difference is that C# does the direct cast automatically, while in VB the
user must perform it manually. Its still not desirable, but the other option
is:

LHTTP.Get("http://www.atozed.com", new Borland.Vcl.Classes.TCLRStream
(LOutput))

Im assuming the DirectCast is more preferable to a VB.net user? The one
disadvantage is not they must reference the Borland unit directly which as
you can see in the C# example is completely eliminated.





--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
Hi Kudzu,
And dont even get me started on the fact that VB had a "Option Implicit" in
it - let alone that it was the DEFAULT.

The number of bugs that this leads to is truly incredible, and only has a
place in scripting languages, if that.
Click to expand...
Should be, but it is introduced as a full upgradable product from VB6.

And it is widely is, but with a lot of disadvantages from VB6, and to make
it faster, you have to do a lot.

VB6 programs where never as fast as C++ and that is nowhere written.

The ones who start with a new program should set option Strict On in the
VS.net options, than you have not even to declare it and behaviour is as
you wish.

Just my 2Eurocent

Cor
 
Hi Kudzu,

Start a debat that is about VB.net without C# with Armin, than you will see
what is forceful
:-) although for this I can use the one Armin sometimes uses :->

Cor
 
Back
Top