CStr() vs. .ToString()

[Guest]

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.]

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.

 

[Guest]

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.

cheers

guy

 

[Guest]

for my clarification
..ToString() = native .Net methods
CStr() = vb String methods?

from my understanding in the book I am reading Cstr() etc is the perfered
way however it doesnt address .ToString()

 

[Scott M.]

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.

 

[CMM]

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).

 

[Bob Lehmann]

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

 

[Martin]

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.

 

[Stephany Young]

Give that man a Kewpie doll!

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

 

[Bob Lehmann]

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

Happy coding, pal.

Bob Lehmann

 

[Martin]

Just wondering... Have you ever contibuted anything positive to this
newsgroup? (or to anything else)

 

[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.

 

[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.
Yes, I don't write malware.

Bob Lehmann

 

[Martin]

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

 

[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.

 

[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]

 

[Herfried K. Wagner [MVP]]

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(...).

.... 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'.

 

[Herfried K. Wagner [MVP]]

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)
///

?

 

[Herfried K. Wagner [MVP]]

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