CStr() vs. .ToString()

[Sean]

Book I am reading says that Cstr() is best method for efficency and safety
however it doesnt compare that method of the .ToString() method.

Which is best.

Thanks

[Martin]

Just wondering... Have you ever contibuted anything positive to this
newsgroup? (or to anything else)
"Bob Lehmann" <no****@dontbot herme.zzz> wrote in message
news:e6******** ******@tk2msftn gp13.phx.gbl...

Checking if a variable actually contains data before doing a convert .. is simply too much code.
You aren't serious, are you?
If you can avoid that it makes the code a lot better readable. You mean like the sentence above? I'm sure you meant "a lot more better
readablest".

Happy coding, pal.

Bob Lehmann

"Martin" <[e-mail]> wrote in message
news:uu******** ******@TK2MSFTN GP11.phx.gbl...

Wow, what happened to put you in this mood?
Checking if a variable actually contains data before doing a convert to
upper case is simply too much code. If you can avoid that it makes the

code

a lot better readable.
"Bob Lehmann" <no****@dontbot herme.zzz> wrote in message
news:ep******** ******@TK2MSFTN GP12.phx.gbl...

>>> You can't use the OO methods on a string that is "Nothing"
>
> Why would you want to?
>
> Oh, I get it, you're too lazy to check the data before performing an
> operation it. Isn't checking your data a 100 level concept?
>
> I'm guessing that On Error Resume Next is one of your friends too.
>
> Bob Lehmann
>
> "CMM" <cm*@nospam.com > wrote in message
> news:%2******** **********@TK2M SFTNGP09.phx.gb l...
>> I don't think that's true at all. First off, CStr,CBool, Etc. are all
>> just
>> easier-to-read specialized wrappers around CType..... which in and of
> itself
>> is a special "VB" construct. The true "non-VB" casting operator is
>> DirectCast(...) .
>>
>> Contrary to what Scott M says you're SUPPOSED to use them. What's the
> point
>> of using VB if you're not going to use its special methods that make

your >> life easier? This is straight from the VB documentation:
>>
>> "As a rule, you should use the Visual Basic type conversion functions in >> preference to the .NET Framework methods such as ToString(), either on
>> the
>> Convert class or on an individual type structure or class. The Visual
> Basic
>> functions are designed for optimal interaction with Visual Basic code,
>> and
>> they also make your source code shorter and easier to read. In addition, > the
>> .NET Framework conversion methods do not always produce the same results > as
>> the Visual Basic functions, for example when converting Boolean to
> Integer.
>> For more information, see Troubleshooting Data Types."
>>
>> In addition, although I'm a guy who always initializes strings and
>> objects
>> as soon as possible rather than have them sit around until my
>> algorithm
> uses
>> them- so I don't really care about the following- but, there's an
> advantage
>> to using VB's functions: they interpret "Nothing." You can't use the
>> OO
>> methods on a string that is "Nothing" (s.ToUpper for instance won't
>> work).
>>
>> --
>> -C. Moya
>> www.cmoya.com
>> "Scott M." <s-***@nospam.nosp am> wrote in message
>> news:O7******** ******@TK2MSFTN GP14.phx.gbl...
>> > IMHO (and this has been debated for quite some time now), you should
> view
>> > all of the old "data-type" specific functions as legacy functions
>> > and
>> > no
>> > longer use them. Instead, use the more object-oriented methods of a
> type.
>> >
>> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
>> > .ToString
>> > All date/time functions would be replaced with methods and
>> > properties
>> > of
>> > the Date class
>> > All string functions would be replaced with methods and properties
>> > of
> the
>> > String class.
>> >
>> > et all.
>> >
>> >
>> > "Sean" <Se**@discussio ns.microsoft.co m> wrote in message
>> > news:68******** *************** ***********@mic rosoft.com...
>> >> Book I am reading says that Cstr() is best method for efficency and
>> >> safety
>> >> however it doesnt compare that method of the .ToString() method.
>> >>
>> >> Which is best.
>> >>
>> >> Thanks
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[CMM]

Nonsense. CStr is not some VB6 (better term is VB.Classic) legacy thing....
in .NET it's just a convenience wrapper around CType... which when used to
cast to a string is simply a wrapper around the object's ToString("G"). I
personally tend to use ToString() as well on my own strings.... but when I'm
handling strings that come from functions that I know might return nulls I'd
tend to use CStr().... it's the same exact thing as typing out all your "If
bla Is Nothing" code that I'm sure litters your nasty code (or maybe it
doesn't.... which is just as bad).

P.S. I'm not sure you know what a Method vs. a Function vs. a Statement
is... at least judging from the poppycock vomited in your post.

--
-C. Moya
www.cmoya.com
"Scott M." <s-***@nospam.nosp am> wrote in message
news:eB******** ******@TK2MSFTN GP15.phx.gbl...

"guy" <gu*@discussion s.microsoft.com > wrote in message
news:21******** *************** ***********@mic rosoft.com...

both points of view are valid, however i use the vb string methods as the
compiler makes optimzations that can improve performance over the native
.Net
methods, also i find the vb methods read better.

The VB 6.0 way are not methods, they are functions. The .NET way are
object methods. The VB.NET compiler does NOT optimize the VB 6.0
functions to work BETTER than the natvie .NET object methods.

To answer your question, ToString would be my suggestion, rather than
CStr(). ToString is a method of the Object Type, and since all classes
inherit from Object, all objects have this method.

cheers

guy

"Scott M." wrote:

IMHO (and this has been debated for quite some time now), you should
view
all of the old "data-type" specific functions as legacy functions and no
longer use them. Instead, use the more object-oriented methods of a
type.

CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
.ToString
All date/time functions would be replaced with methods and properties of
the
Date class
All string functions would be replaced with methods and properties of
the
String class.

et all.
"Sean" <Se**@discussio ns.microsoft.co m> wrote in message
news:68******** *************** ***********@mic rosoft.com...
> Book I am reading says that Cstr() is best method for efficency and
> safety
> however it doesnt compare that method of the .ToString() method.
>
> Which is best.
>
> Thanks
>
>

[Bob Lehmann]

>> Have you ever contibuted anything positive
Uh, yeah.

I suggested that checking your data before performing operations the data is
a best practice. I highly doubt that any competent programmer would
disagree. Apparently you are not in that group.

Or, is your specialty in buffer overruns?

At least you have a sound rationale -
"Checking if a variable actually contains data before doing a convert to
upper case is simply too much code."

Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo hard
to do. And besides, my code is better readable since you know I don't indent
If blocks.

Perhaps you should stick to scripting languages where you don't have all the
icky typed variable stuff going on. I mean, isn't it a hassle declaring all
those variable thingys, with all that code and stuff?

Maybe, after you've completed Junior High, you'll have a different
perspective.

(or to anything else) Yes, I don't write malware.

Bob Lehmann

"Martin" <[e-mail]> wrote in message
news:eF******** *****@TK2MSFTNG P09.phx.gbl...

Just wondering... Have you ever contibuted anything positive to this
newsgroup? (or to anything else)
"Bob Lehmann" <no****@dontbot herme.zzz> wrote in message
news:e6******** ******@tk2msftn gp13.phx.gbl... Checking if a variable actually contains data before doing a convert ...

is simply too much code.
You aren't serious, are you?

If you can avoid that it makes the code a lot better readable.

You mean like the sentence above? I'm sure you meant "a lot more better
readablest".

Happy coding, pal.

Bob Lehmann

"Martin" <[e-mail]> wrote in message
news:uu******** ******@TK2MSFTN GP11.phx.gbl...

Wow, what happened to put you in this mood?
Checking if a variable actually contains data before doing a convert to
upper case is simply too much code. If you can avoid that it makes the

code

a lot better readable.
"Bob Lehmann" <no****@dontbot herme.zzz> wrote in message
news:ep******** ******@TK2MSFTN GP12.phx.gbl...
>>> You can't use the OO methods on a string that is "Nothing"
>
> Why would you want to?
>
> Oh, I get it, you're too lazy to check the data before performing an
> operation it. Isn't checking your data a 100 level concept?
>
> I'm guessing that On Error Resume Next is one of your friends too.
>
> Bob Lehmann
>
> "CMM" <cm*@nospam.com > wrote in message
> news:%2******** **********@TK2M SFTNGP09.phx.gb l...
>> I don't think that's true at all. First off, CStr,CBool, Etc. are

all >> just
>> easier-to-read specialized wrappers around CType..... which in and of > itself
>> is a special "VB" construct. The true "non-VB" casting operator is
>> DirectCast(...) .
>>
>> Contrary to what Scott M says you're SUPPOSED to use them. What's the > point
>> of using VB if you're not going to use its special methods that make

your

>> life easier? This is straight from the VB documentation:
>>
>> "As a rule, you should use the Visual Basic type conversion functions in

>> preference to the .NET Framework methods such as ToString(), either

on >> the
>> Convert class or on an individual type structure or class. The Visual > Basic
>> functions are designed for optimal interaction with Visual Basic code, >> and
>> they also make your source code shorter and easier to read. In

addition,

> the
>> .NET Framework conversion methods do not always produce the same

results

> as
>> the Visual Basic functions, for example when converting Boolean to
> Integer.
>> For more information, see Troubleshooting Data Types."
>>
>> In addition, although I'm a guy who always initializes strings and
>> objects
>> as soon as possible rather than have them sit around until my
>> algorithm
> uses
>> them- so I don't really care about the following- but, there's an
> advantage
>> to using VB's functions: they interpret "Nothing." You can't use the
>> OO
>> methods on a string that is "Nothing" (s.ToUpper for instance won't
>> work).
>>
>> --
>> -C. Moya
>> www.cmoya.com
>> "Scott M." <s-***@nospam.nosp am> wrote in message
>> news:O7******** ******@TK2MSFTN GP14.phx.gbl...
>> > IMHO (and this has been debated for quite some time now), you should > view
>> > all of the old "data-type" specific functions as legacy functions
>> > and
>> > no
>> > longer use them. Instead, use the more object-oriented methods of a > type.
>> >
>> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
>> > .ToString
>> > All date/time functions would be replaced with methods and
>> > properties
>> > of
>> > the Date class
>> > All string functions would be replaced with methods and properties
>> > of
> the
>> > String class.
>> >
>> > et all.
>> >
>> >
>> > "Sean" <Se**@discussio ns.microsoft.co m> wrote in message
>> > news:68******** *************** ***********@mic rosoft.com...
>> >> Book I am reading says that Cstr() is best method for efficency and >> >> safety
>> >> however it doesnt compare that method of the .ToString() method.
>> >>
>> >> Which is best.
>> >>
>> >> Thanks
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[Martin]

Finishing junior high may be your problem. I have a real education ;-)

"Bob Lehmann" <no****@dontbot herme.zzz> wrote in message
news:ub******** ******@TK2MSFTN GP09.phx.gbl...

Have you ever contibuted anything positive Uh, yeah.

I suggested that checking your data before performing operations the data
is
a best practice. I highly doubt that any competent programmer would
disagree. Apparently you are not in that group.

Or, is your specialty in buffer overruns?

At least you have a sound rationale -
"Checking if a variable actually contains data before doing a convert to
upper case is simply too much code."

Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo
hard
to do. And besides, my code is better readable since you know I don't
indent
If blocks.

Perhaps you should stick to scripting languages where you don't have all
the
icky typed variable stuff going on. I mean, isn't it a hassle declaring
all
those variable thingys, with all that code and stuff?

Maybe, after you've completed Junior High, you'll have a different
perspective.
(or to anything else) Yes, I don't write malware.

Bob Lehmann

"Martin" <[e-mail]> wrote in message
news:eF******** *****@TK2MSFTNG P09.phx.gbl...

Just wondering... Have you ever contibuted anything positive to this
newsgroup? (or to anything else)
"Bob Lehmann" <no****@dontbot herme.zzz> wrote in message
news:e6******** ******@tk2msftn gp13.phx.gbl...

>>> Checking if a variable actually contains data before doing a convert

.. > is simply too much code.
> You aren't serious, are you?
>
>>> If you can avoid that it makes the code a lot better readable.
> You mean like the sentence above? I'm sure you meant "a lot more better
> readablest".
>
> Happy coding, pal.
>
> Bob Lehmann
>
> "Martin" <[e-mail]> wrote in message
> news:uu******** ******@TK2MSFTN GP11.phx.gbl...
>> Wow, what happened to put you in this mood?
>> Checking if a variable actually contains data before doing a convert
>> to
>> upper case is simply too much code. If you can avoid that it makes the
> code
>> a lot better readable.
>>
>>
>> "Bob Lehmann" <no****@dontbot herme.zzz> wrote in message
>> news:ep******** ******@TK2MSFTN GP12.phx.gbl...
>> >>> You can't use the OO methods on a string that is "Nothing"
>> >
>> > Why would you want to?
>> >
>> > Oh, I get it, you're too lazy to check the data before performing an
>> > operation it. Isn't checking your data a 100 level concept?
>> >
>> > I'm guessing that On Error Resume Next is one of your friends too.
>> >
>> > Bob Lehmann
>> >
>> > "CMM" <cm*@nospam.com > wrote in message
>> > news:%2******** **********@TK2M SFTNGP09.phx.gb l...
>> >> I don't think that's true at all. First off, CStr,CBool, Etc. are all >> >> just
>> >> easier-to-read specialized wrappers around CType..... which in and of >> > itself
>> >> is a special "VB" construct. The true "non-VB" casting operator is
>> >> DirectCast(...) .
>> >>
>> >> Contrary to what Scott M says you're SUPPOSED to use them. What's the >> > point
>> >> of using VB if you're not going to use its special methods that
>> >> make
> your
>> >> life easier? This is straight from the VB documentation:
>> >>
>> >> "As a rule, you should use the Visual Basic type conversion functions > in
>> >> preference to the .NET Framework methods such as ToString(), either on >> >> the
>> >> Convert class or on an individual type structure or class. The Visual >> > Basic
>> >> functions are designed for optimal interaction with Visual Basic code, >> >> and
>> >> they also make your source code shorter and easier to read. In
> addition,
>> > the
>> >> .NET Framework conversion methods do not always produce the same
> results
>> > as
>> >> the Visual Basic functions, for example when converting Boolean to
>> > Integer.
>> >> For more information, see Troubleshooting Data Types."
>> >>
>> >> In addition, although I'm a guy who always initializes strings and
>> >> objects
>> >> as soon as possible rather than have them sit around until my
>> >> algorithm
>> > uses
>> >> them- so I don't really care about the following- but, there's an
>> > advantage
>> >> to using VB's functions: they interpret "Nothing." You can't use
>> >> the
>> >> OO
>> >> methods on a string that is "Nothing" (s.ToUpper for instance won't
>> >> work).
>> >>
>> >> --
>> >> -C. Moya
>> >> www.cmoya.com
>> >> "Scott M." <s-***@nospam.nosp am> wrote in message
>> >> news:O7******** ******@TK2MSFTN GP14.phx.gbl...
>> >> > IMHO (and this has been debated for quite some time now), you should >> > view
>> >> > all of the old "data-type" specific functions as legacy functions
>> >> > and
>> >> > no
>> >> > longer use them. Instead, use the more object-oriented methods
>> >> > of a >> > type.
>> >> >
>> >> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
>> >> > .ToString
>> >> > All date/time functions would be replaced with methods and
>> >> > properties
>> >> > of
>> >> > the Date class
>> >> > All string functions would be replaced with methods and
>> >> > properties
>> >> > of
>> > the
>> >> > String class.
>> >> >
>> >> > et all.
>> >> >
>> >> >
>> >> > "Sean" <Se**@discussio ns.microsoft.co m> wrote in message
>> >> > news:68******** *************** ***********@mic rosoft.com...
>> >> >> Book I am reading says that Cstr() is best method for efficency and >> >> >> safety
>> >> >> however it doesnt compare that method of the .ToString() method.
>> >> >>
>> >> >> Which is best.
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[Scott M.]

I think you better read your own post. CStr() is a built-in function of the
VB 6 language. It is not a method. ToString is a method of the Object type
(which all classes in .NET derive from). So, I'm not sure why you feel the
need to call this poppycock and suggest that I don't know what a function
vs. a method is.

As for which is better... As I said in my first post, it is a matter of
choice and I prefer the more object-oriented ToString object method.
"CMM" <cm*@nospam.com > wrote in message
news:ed******** ******@TK2MSFTN GP11.phx.gbl...

Nonsense. CStr is not some VB6 (better term is VB.Classic) legacy
thing.... in .NET it's just a convenience wrapper around CType... which
when used to cast to a string is simply a wrapper around the object's
ToString("G"). I personally tend to use ToString() as well on my own
strings.... but when I'm handling strings that come from functions that I
know might return nulls I'd tend to use CStr().... it's the same exact
thing as typing out all your "If bla Is Nothing" code that I'm sure
litters your nasty code (or maybe it doesn't.... which is just as bad).

P.S. I'm not sure you know what a Method vs. a Function vs. a Statement
is... at least judging from the poppycock vomited in your post.

--
-C. Moya
www.cmoya.com
"Scott M." <s-***@nospam.nosp am> wrote in message
news:eB******** ******@TK2MSFTN GP15.phx.gbl...

"guy" <gu*@discussion s.microsoft.com > wrote in message
news:21******** *************** ***********@mic rosoft.com...

both points of view are valid, however i use the vb string methods as
the
compiler makes optimzations that can improve performance over the native
.Net
methods, also i find the vb methods read better.

The VB 6.0 way are not methods, they are functions. The .NET way are
object methods. The VB.NET compiler does NOT optimize the VB 6.0
functions to work BETTER than the natvie .NET object methods.

To answer your question, ToString would be my suggestion, rather than
CStr(). ToString is a method of the Object Type, and since all classes
inherit from Object, all objects have this method.

cheers

guy

"Scott M." wrote:

IMHO (and this has been debated for quite some time now), you should
view
all of the old "data-type" specific functions as legacy functions and
no
longer use them. Instead, use the more object-oriented methods of a
type.

CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
.ToString
All date/time functions would be replaced with methods and properties
of the
Date class
All string functions would be replaced with methods and properties of
the
String class.

et all.
"Sean" <Se**@discussio ns.microsoft.co m> wrote in message
news:68******** *************** ***********@mic rosoft.com...
> Book I am reading says that Cstr() is best method for efficency and
> safety
> however it doesnt compare that method of the .ToString() method.
>
> Which is best.
>
> Thanks
>
>

[Scott M.]

> Contrary to what Scott M says you're SUPPOSED to use them. What's the

point of using VB if you're not going to use its special methods that make
your life easier?

You should really relax and read what was posted. If you were supposed to
use the legacy conversion functions and not the .NET ToString and CType,
then why would MS add them in the first place.

My post started with IMHO and that much has been debated about this before.

Your opinion is fine, but it is just that. Wrappers have their own
downside, which tend to be more CPU cycles.

[m.posseth]

well .........

option 1

dim x as string
----- some stuff here that might or might not fill the string
if not x is nothing then
if x.length>0 then
---- do your stuff
end if
end if

option 2

dim x as string = ""
----- some stuff here that might or might not fill the string
if x.length>0 then
---- do your stuff
end if

option 3

dim x as string
----- some stuff here that might or might not fill the string
if len(x)>0 then
---- do your stuff
end if
Well In My Homble Opinion it all depends on a few factors what should favor
you

1. your personal coding style
2. design of your app ( if constructs like this happen a lot you might save
some typing with option 2 or 3 )
3. portability need to other .Net languages

I believe that option 1 and 3 are the same , although it is written
different option 2 is the practical guideline for VB and C# and is probably
the fastest and time sparing ( prevents RSI the most :-) )

regards

Michel Posseth [MCP]



"Scott M." <s-***@nospam.nosp am> schreef in bericht
news:um******** ******@TK2MSFTN GP14.phx.gbl...

Contrary to what Scott M says you're SUPPOSED to use them. What's the
point of using VB if you're not going to use its special methods that
make your life easier?

You should really relax and read what was posted. If you were supposed to
use the legacy conversion functions and not the .NET ToString and CType,
then why would MS add them in the first place.

My post started with IMHO and that much has been debated about this
before.

Your opinion is fine, but it is just that. Wrappers have their own
downside, which tend to be more CPU cycles.

[Herfried K. Wagner [MVP]]

"CMM" <cm*@nospam.com > schrieb:

I don't think that's true at all. First off, CStr,CBool, Etc. are all just
easier-to-read specialized wrappers around CType..... which in and of
itself is a special "VB" construct.
ACK. While it doesn't matter if you use 'C<Type>' or 'CType(..., <Type>)',
I strongly recommend to use them instead of 'Convert.To*'.
The true "non-VB" casting operator is DirectCast(...) .

.... which doesn't mean that 'DirectCast' should not be used. Personally I
prefer 'CType' for value types (type conversions) and 'DirectCast' for type
casts (reference types). However, some other people prefer to use 'CType'
instead of 'DirectCast'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

"Bob Lehmann" <no****@dontbot herme.zzz> schrieb:

You can't use the OO methods on a string that is "Nothing"

Why would you want to?

Oh, I get it, you're too lazy to check the data before performing an
operation it. Isn't checking your data a 100 level concept?

Why type 'If s IsNot Nothing AndAlso s.Length > 0 Then' if you could shorten
it to 'If Len(s) > 0 Then'? The same applies to 'ToString' vs. 'CStr': Why
type

\\\
If o Is Nothing Then
s = ""
Else
s = o.ToString()
End If
///

if you could archieve the same by using

\\\
s = CStr(o)
///

?

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

"Bob Lehmann" <no****@dontbot herme.zzz> schrieb:

At least you have a sound rationale -
"Checking if a variable actually contains data before doing a convert to
upper case is simply too much code."

Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo
hard
to do. And besides, my code is better readable since you know I don't
indent
If blocks.

Well, why duplicate this checking code all over the source code if it is
possible to encapsulate it cleanly in high-level wrappers/functions like
'CStr'?

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>