Board index » Visual Studio » VB and implicit conversions

Visual Studio183
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) - www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at 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



"Chad Z. Hower aka Kudzu" <cpub@hower.org>schrieb im Newsbeitrag



-

"Klaus Löffelmann" <fornewsgroups@loeffelmann.de>wrote in

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) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

"Chad Z. Hower aka Kudzu" <cpub@hower.org>schrieb

Code?





--

Armin



How to quote and why:

www.plig.net/nnq/nquote.html">www.plig.net/nnq/nquote.html

www.netmeister.org/news/learn2quote.html">www.netmeister.org/news/learn2quote.html



-

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.









"Chad Z. Hower aka Kudzu" <cpub@hower.org>schrieb im Newsbeitrag



-

"Cor" <non@non.com>wrote in news:uSQ#Sty5DHA.2136@TK2MSFTNGP12.phx.gbl:

Thanks. A direct conversion will be much easier than that. :(



But thanks for the answer.





--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

"Armin Zingler" <az.nospam@freenet.de>wrote in news:uiS5Hoy5DHA.2392

@TK2MSFTNGP11.phx.gbl:

Its the very last VB example here:

www.atozed.com/indy/Texts/VSIntro.iwp">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) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

"Klaus Löffelmann" <fornewsgroups@loeffelmann.de>wrote in

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?



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) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

"Chad Z. Hower aka Kudzu" <cpub@hower.org>schrieb

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:

www.plig.net/nnq/nquote.html">www.plig.net/nnq/nquote.html

www.netmeister.org/news/learn2quote.html">www.netmeister.org/news/learn2quote.html



-

"Armin Zingler" <az.nospam@freenet.de>wrote in

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) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

Chad,



see inlines...



Klaus



"Chad Z. Hower aka Kudzu" <cpub@hower.org>schrieb im Newsbeitrag

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!





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?!





-

"Chad Z. Hower aka Kudzu" <cpub@hower.org>schrieb

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





--

Armin



-

"Klaus Löffelmann" <fornewsgroups@loeffelmann.de>wrote in news:401a61d7$0

$1039$9b622d9e@news.freenet.de:



Defeats the purpose unfortunately. It requires the user to interact

directly with the destination type.



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) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">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) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

"Klaus Löffelmann" <fornewsgroups@loeffelmann.de>wrote in news:401a61d7$0

$1039$9b622d9e@news.freenet.de:

Thanks. This works, but its not really much better.



LHTTP.Get("www.atozed.com",">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("www.atozed.com",">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("www.atozed.com",">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) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

"Chad Z. Hower aka Kudzu" <cpub@hower.org>wrote in

Ack. I just found out VB still has this option. :(



At least MS now reversed the default to explicit.





--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

"Armin Zingler" <az.nospam@freenet.de>wrote in news:Oea9wmz5DHA.2252

@TK2MSFTNGP10.phx.gbl:

No problem.



BTW - sorry if sounded forceful in my other replies. No disrespect intended -

Im just a very forceful in debates. :)





--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

Hi Kudzu,





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





-

Ok. New question, same thread as its related. Take a look at the code

below. The line with the .Get is really the only one of importance.



Imports System.IO

Imports System.Text

Imports Indy.Sockets.IndyHTTP



Module Module1



Sub Main()

Dim LResult As String

Dim LHTTP As New HTTP



Dim LStream As New MemoryStream

Dim LOutput As New FileStream( _

New FileInfo

(System.Windows.Forms.Application.ExecutablePath).DirectoryName _

+ "\index.html", FileMode.Create)

LHTTP.Get("www.atozed.com",">www.atozed.com", DirectCast(LOutput,

Borland.Vcl.Classes.TStream))

End Sub



End Module



Now I can chaneg it to:



LHTTP.Get("www.atozed.com",">www.atozed.com", DirectCast(LOutput, TStream))



If the user adds:

Imports Borland.Vcl.Classes;



In C# neither of these are necessary because of implicit coversion, its all

done transparently. They dont even need the Imports (using in C#). We've

esatablished that.



That being said - there are 3 options to present to VB users. Can you tell

me which do you think would be the most desirable to VB users?



a) The solution above. Either with fully qualified TStream or adding it to

the Imports.



b) Same issue as above, but instead of DirectCast calling:



LHTTP.Get("www.atozed.com",">www.atozed.com", new TCLRStream(LOutput))



This still needs to be fully qualified - or have the namespace added to

Imports.



c) We add a Convert function that is overloaded to Indy. Im pretty sure we

can do an overload (has different result types, but also different

arguemnts, should be fine for .net).



ie:

LHTTP.Get("www.atozed.com",">www.atozed.com", IndyConvert(LOutput))



The advantages with C are that:

1) User does not have to import any Borland namespaces, only Indy (albeit

an additional Indy one)

2) User does not need to know the destination type, or specify it.

3) Its a bit shorter and easier.



If c is the best - what should we call the function?





--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

"Cor" <non@non.com>wrote in news:ezkzh1z5DHA.2696@TK2MSFTNGP09.phx.gbl:

Its not a matter of fast - its a matter of producing encouraging code with

lots of bugs, and thus being unreliable.



By making it the default for 6 versions they told new programmers that it was

not only "good" but led them into many pitfalls and traps.





--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

"Cor" <non@non.com>wrote in news:ubc9v2z5DHA.3896@TK2MSFTNGP11.phx.gbl:

Dont get me wrong - VB.net is finally "good". My gripes lie mostly with VB

versions prior to .net.



I have gripes with C#.



Now if you want to talk langauges - lets talk Delphi. :)



Delphi's not perfect either - but even with using VB and C#, over all I like

it much better. But C# is just a Delphi form of C++ (Anders H no doubt) and

each version of C# gets closer and closer to Delphi. soo...





--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

"Chad Z. Hower aka Kudzu" <cpub@hower.org>schrieb

No problem either. Didn't sound forceful to me.





--

Armin



-

Hi Kudzu,



VB has one big benefit it is not a should language, but a could language..



Some people do not like it, the take C# others like it and they take VB.net



I can say I like it more to have some freedom.



Cor





-

*LOL*



No offense, Armin... :-)



Klaus





"Cor" <non@non.com>schrieb im Newsbeitrag



-

Chad,



why not writing a wrapper DLL for VB, that wraps around the related objects.

And about the Using- (Imports-) Business. How do you access a namespace in

c# without "Using" it?



Klaus



"Chad Z. Hower aka Kudzu" <cpub@hower.org>schrieb im Newsbeitrag



-

"Cor" <non@non.com>wrote in news:uRDwAB05DHA.1052@TK2MSFTNGP12.phx.gbl:

For 6 versions it was a "should have been, but isnt" language. :(



Only now is it a "can".





--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

"Klaus Löffelmann" <fornewsgroups@loeffelmann.de>wrote in

Its not just this one line. The source is 120 source files or so and like

60,000 lines of code. Its also not only for VB. So IFDEFFING say 300 places

with new overload JUST for VB is not a viable nor desirable option. :)



With implicit conversion the developer never references the target type of

the argument, and thus never needs the namespace. The developer passes in

System.IO.Stream, and C# does the implicit conversion (cast in VB terms).







--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

* "Klaus Löffelmann" <fornewsgroups@loeffelmann.de>scripsit:

'On', not 'True'.



;-)



--

Herfried K. Wagner [MVP]

<www.mvps.org/dotnet>">www.mvps.org/dotnet>

-

Any input on this one? :)



Subject: Re: VB and implicit conversions

From: "Chad Z. Hower aka Kudzu" <cpub@hower.org>

Newsgroups: microsoft.public.dotnet.languages.vb



Ok. New question, same thread as its related. Take a look at the code

below. The line with the .Get is really the only one of importance.



Imports System.IO

Imports System.Text

Imports Indy.Sockets.IndyHTTP



Module Module1



Sub Main()

Dim LResult As String

Dim LHTTP As New HTTP



Dim LStream As New MemoryStream

Dim LOutput As New FileStream( _

New FileInfo

(System.Windows.Forms.Application.ExecutablePath).DirectoryName _

+ "\index.html", FileMode.Create)

LHTTP.Get("www.atozed.com",">www.atozed.com", DirectCast(LOutput,

Borland.Vcl.Classes.TStream))

End Sub



End Module



Now I can chaneg it to:



LHTTP.Get("www.atozed.com",">www.atozed.com", DirectCast(LOutput, TStream))



If the user adds:

Imports Borland.Vcl.Classes;



In C# neither of these are necessary because of implicit coversion, its all

done transparently. They dont even need the Imports (using in C#). We've

esatablished that.



That being said - there are 3 options to present to VB users. Can you tell

me which do you think would be the most desirable to VB users?



a) The solution above. Either with fully qualified TStream or adding it to

the Imports.



b) Same issue as above, but instead of DirectCast calling:



LHTTP.Get("www.atozed.com",">www.atozed.com", new TCLRStream(LOutput))



This still needs to be fully qualified - or have the namespace added to

Imports.



c) We add a Convert function that is overloaded to Indy. Im pretty sure we

can do an overload (has different result types, but also different

arguemnts, should be fine for .net).



ie:

LHTTP.Get("www.atozed.com",">www.atozed.com", IndyConvert(LOutput))



The advantages with C are that:

1) User does not have to import any Borland namespaces, only Indy (albeit

an additional Indy one)

2) User does not need to know the destination type, or specify it.

3) Its a bit shorter and easier.



If c is the best - what should we call the function?





--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com







--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

Operator overloading is something of a mixed blessing at best and

overloading the implicit operator is probably the diciest of all. In

general, using an implicit conversion operator on a custom type is not a

good idea and should be restricted at most to a few specialized value types.

Using an implicit conversion operator between reference types is almost

always a very bad idea since it makes reference types act as value types

without warning (i.e. a reference is no longer copied, a new object is

created) along with several other problems to do with readability, etc.

Implicit casts should really be used only for casting to a base class. In

fact, if faced with a library that used implicit conversion to any great

extent, or used it between reference types without a very good reason I

would probably pass on it.



That having been said, in your scenario a) won't work: DirectCast can only

cast to a type that the object already is, for example upcasting or casting

to an interface that the object implements. CType does other conversions as

well as casting but it also can't use your custom operator. Choice b) is

better it makes clear that you are creating a new object based on the input

object but it is a little non-standard. Choice c) is, in my opinion, clearly

the best. As to the name of the conversion function you already have a

static function (your operator) called op_Implicit that can be called from

VB but it would be better to implement functions along the lines of FromXXX

and ToXXX when you want to implement custom conversion routines.



I've used operator overloading a fair amount in C++ and C# and I must say

that I am awaiting its arrival in VB with some trepidation. While it will be

useful occasionally it will almost certainly lead to a proliferation of

garbage code similar to, and possibly worse than, that created by the

introduction of simple multi-threading and a few other things.





"Chad Z. Hower aka Kudzu" <cpub@hower.org>wrote in message



-

"Stephen Martin" <smartin@removethis.emsoft.andthis.ca>wrote in

Operator overloading certainly can be abused. So can the with statement.



Not at all. In fact when you do not have access to alter base classes, its

very important in providing conversions.



Also - a true OOP system cannot function without it. Floats, integers, etc

are ALL implemented this way internally to .net.



You misunderstand how they are used. They are not limited to value types,

and you do not convert the reference.



Think of them as adaptors, It allows one interface to morph onto another.



There is no need to cast to a base class. And this is not the same. It

appears that you do not understand what happens in implicit conversions of

non valued objects.



Again - you dont seem to understand what is going on. DirectCast most

certainly DOES work. There is no upcasting occurring. You can download the

demo and play with it if you want.



C is the one I prefer as well, since there is no implicit conversion.



ToXXX would require the user to understand what it is going to - Where as

we can easily overload them and automatically select for the user based on

the condition.







--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

Yeah, that's on.

I mean true.

Whatever.



;-)



Klaus





"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at>schrieb im Newsbeitrag



-

Hi Chad,



You might want to re-read my post. It might just be me but your responses

don't seem to make much sense in the context they are in. But just to

clarify a couple of things:



It's actually only one of (and in my opinion the least preferable) method of

doing conversions. Explicit conversion operators, conversion functions and

conversion constructors are all superior.



That a 'true' OOP system requires implicit conversion operators is certainly

highly debatable. Also, your reference to floats, integers, etc. is somewhat

disingenuous, I was explicitly speaking of custom types not primitives and I

added that there are some instances where an implicit conversion operator is

useful for value types.



I didn't say anything about them being limited to value types. But if you

have an assignment statement (or method parameter) that involves an implicit

conversion operator then unlike the standard for reference types of simply

copying a reference to the original object into the new variable you are

actually creating a new object and then assigning its reference to the

variable (unless of course your conversion operator returned a this

reference but that would be rather unusual). This then makes your reference

types act like value types (copy on assignment), at least an explicit

conversion operator gives you warning (though a conversion function or

conversion constructor would be better).



object then the default explicit conversion operator already does that and

there is no reason to make it implicit. If you are creating a new object

that implements a similar interface or has the same base class but

additional interfaces, etc. then you are much better off implementing

conversion constructors or static conversion functions (or if you must an

explicit conversion operator).



Also, again I might be misunderstanding, but your code listing states that

LOutput is of type System.IO.FileStream. In order to pass it to your method

you are casting it to type Borland.Vcl.Classes.TStream. If this is correct

then DirectCast should only work if LOuput is already of type

Borland.Vcl.Classes.TStream, but this isn't the case since it is dimmed and

created the line above as a FileStream and I know that FileStream does not

inherit from Borland.Vcl.Classes.TStream nor does it implement an interface

called Borland.Vcl.Classes.TStream. So, either DirectCast isn't working as

it is supposed to or something is going over my head here.



It's possible we're not understanding each other, talking past each other so

to speak. To clarify what you are talking about perhaps you could post the

code here for your implicit operator and a link to the 'demo' to which you

referred.





"Chad Z. Hower aka Kudzu" <cpub@hower.org>wrote in message

<snip>







-

"Stephen Martin" <smartin@removethis.emsoft.andthis.ca>wrote in

Not always - its always good to have them, but often they are just PITA.

Imagine if you had to cast to go from a byte into an integer? Or a

character into a string? Conversions that are straightforward and well

defined should be automatic.



In .net there is no difference. Internally an integer is pretty much an

object, and the conversions to other types are handled the same as any

other object. The only "Special" part is that simple types have literals

that the compiler understands.



Incorrect - The case in point is not so.



TCLRStream constructor accepts a System.IO.Stream. TCLRStream implements

TStream abstract. All calls from the overridden methods in TCLRStream are

mapped onto (translated) to System.IO.Stream's equivalent on that instance.

There is no value, and nothing is lost.



DirectCast does in fact fail. It compiles but throws an exception. The

documentation I read on it led me to beleive it looks for the implicit

casts, that is its doing what C# does automatically. Evidently it does not

and it uses IConvertable and some differetn mechanisms. What a shame.



I could swear I ran the VB version before. I did a compiler update at the

same time. Id love to back that out to verify, but that would take hours.

And the C# version still works anyways.



It seems that VB has not support for the implicit overloads, even through

explicit calls.



The code is here:

downloads.atozed.com/indy/10/VSIntroStream.zip">downloads.atozed.com/indy/10/VSIntroStream.zip



It requires this assembly:

www.atozed.com/indy.html">www.atozed.com/indy.html



Looks like Im down to 2 options now - Covert method overload or explicit

creation. The convert overloads are much friendlier.





--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-

FYI,



We went with option C.



www.atozed.com/indy/Texts/VSIntro.iwp">www.atozed.com/indy/Texts/VSIntro.iwp



See the last two examples under "Using Streams". Compare the C# and the VB

and you can see the difference. Also see the note about "Conversion - Visual

Basic".





--

Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/">www.hower.org/Kudzu/

"Programming is an art form that fights back"





ELKNews - Get your free copy at www.atozedsoftware.com">www.atozedsoftware.com



-