CStr() vs. .ToString()

[Cor Ligthert [MVP]]

Carlos

If s is Nothing Then
Return ""
Else
Return s.ToString()
End If

This is in my opinion only nececarry if you declare s as Object and use
reflection or latebinding to do your job.

If s is a member of an object it is forever needed to test on the existence
of the object.

Because that the ToString is one of the base members and not much more
characthers to type do I use forever ToString, although I have to admit that
it is not consistent.

So seeing what you wrote in this thread we agree, with the exception of
course of doing instructions to instance not needed with an not used value.



Cor

 

[Cor Ligthert [MVP]]

Scott,

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.

What you write is true, however we are talking about dotNet her. In dotNet
all methods are Methods even if you call them functions. It does not matter
if they are placed in the System Namespace or placed in whatever namespace
including your own.

In the Visual Basic namespace are many methods which are more optimized in
whatever way than the standard system.Net methods. Some are just wrappers
with backward compatible reasons (but absolute not all).

This optimized can be to make it easier and more descripting writing a
program.
By instance IsDate what is nothing more than a convert in a try block,
however much easier to write or by instance a Find method which is twice as
fast as an IndexOf a full string.

Just my opinion

Cor

 

[Herfried K. Wagner [MVP]]

Which could be avoided if best practices were followed to begin with, and
not fueled by bad advice.

Using 'CStr' whenever it /makes sense/ is good practice.

 

[CMM]

Using 'CStr' whenever it /makes sense/ is good practice.

Always has been always will be. If one doesn't like VB's specialized helper
functions and methods, maybe they shouldn't be coding in VB. And, to call
them "legacy" is both ignorant and shortsighted. They are what make VB "VB."

Chances are at some point people like Scott M will realize what
"encapsulation" means and write their own SafeToString(object) helper
function... not really realizing (or caring) that they had this all along.

 

[CMM]

ToString scenario. And if you want to avoid the empty string possibility

of CStr(), you are going to need an IF statement to check the string, just
as you would need to check the string for Nothing using ToString, so
there's no code savings that others have indicated there would be.

Ever heard of encapsulation? If your code is littered with Is Nothing checks
all over the place just to process a string you've missed the point of
modern procedural programming.

That's all I've been trying to say...CStr() can get you into trouble in
certain situations. And when it does, it can be difficult to troubleshoot
where the problem is due to the *valid*, but empty string floating around
in memory.

Name one situation.

In almost all situations you'd usually want to treat a Nothing string as
Empty. Caring whether it's actually Nothing is the exception and not
something to base an entire coding practice on when it doesn't warrant it.

Again, this is one area (among many) that sets VB apart from its more
stripped down .NET sibling languages.

As for the additional behavior of CStr() being well known, I highly
disagree. This whole thread (and countless others) started off with the
OP confused over the difference between CStr() and .ToString.

Considering CStr and its older Str cousin have been around since B.A.S.I.C.
I'd chalk it up to just not understanding what VB as a high-level coding
language is versus the framework its latest incarnation rides on.

 

[Scott M.]

I'm not mixing up anything. Indicating that I am stupid for recommending
not to use CStr() is what you've both said. But at the same time, you've
both also admitted that CStr() can get you into trouble. So my advice is go
with the code that will satisfy all scenarios and for this you both call me
stupid.

They are your own words Herfried, just scroll down and read them if you've
forgotten.

 

[Scott M.]

Cor,

You are completely missing the point. My point is that writing
CStr(someString) over someObject.ToString is a throwback to the VB 6.0 style
of object BASED programming and not consistent with the object ORIENTED
style of programming.

In this context, yes there is a difference between a method and a language
function. As a teacher, when I have students new to this, the question is
always the same, "How do I know when you should use an object method vs.
using a language function and pass it some type's value?". Type CStr() in
VS.NET and it will turn blue. Blue is for language elements. Yes,
internally this "function" operates as a method, but from a coding *style*
perspective the developer is not using a method, they are using a language
construct.

For consistency sake as well as the fact that many of the old VB 6.0
"functions" don't offer any benefits over object methods, I prefer the OO
way.

As for CStr() in particular, I've said over and over that this is my
PREFERENCE and IMHO it doesn't need to be everyone's choice. Using ToString
on string values along with an Is Nothing check works in every single
situation. CStr() would need an IF Then check of its own to validate its
conversion, so the two approached amount to roughly the same amount of code.

Now, CMM and Herfried have changed their original stance and admitted that
if you need to process Nothing differently than a string, you will have
problems with CStr(). And in *my* travels, handling Nothing differently
than a string value is pretty darn common, which means using ToString makes
perfect sense in every situation I encounter. For advocating this, CMM and
Herfried have decided to get personal and call me stupid. I don't know CMM,
but I wouldn't have expected that from Herfried.


-Scott

 

[CMM]

I've never admitted CStr can "get you into trouble" and I'd like you to give
one example when it might.
As for "calling you stupid"... I don't think that it was anyone's intention
to level a personal insult. We're simply debating the merit of your claims
about CStr. Though I do think calling CStr "legacy" does sort of demonstate
a bit of ignorance considering it's entirely false.

 

[Scott M.]

Wow, you are just full of compliments CMM. Read the first 4 letters I wrote
in my OP. If I told you that I always want to treat a Nothing value
differently than a String value, what would you suggest I do?

 

[CMM]

Cor,

You are completely missing the point. My point is that writing
CStr(someString) over someObject.ToString is a throwback to the VB 6.0
style of object BASED programming and not consistent with the object
ORIENTED style of programming.

I hope you're teaching your students about encapsulation. Because that's
exactly what CStr is.

Also, the fact that by-design the .NET String object violates the strict
"object ORIENTED" notion that you seem to be harping on. For instance,
s.ToUpper() doesn't exactly perform a true OO operation (in that s isn't
modified). So there goes that.

In this context, yes there is a difference between a method and a language
function. As a teacher, when I have students new to this, the question is
always the same, "How do I know when you should use an object method vs.
using a language function and pass it some type's value?". Type CStr() in
VS.NET and it will turn blue. Blue is for language elements. Yes,
internally this "function" operates as a method, but from a coding *style*
perspective the developer is not using a method, they are using a language
construct.

Also known as a keyword, right? Well, that's what makes VB "VB."
Respectfully, if you don't like the things that make VB "VB," maybe you
shouldn't be using or teaching VB. C# seems much better suited to your
preferences, no?

For consistency sake as well as the fact that many of the old VB 6.0
"functions" don't offer any benefits over object methods, I prefer the OO
way.

They offer many benefits. Maybe it might help if somebody wrapped that all
up as Shared Methods in a "StringUtility" class? Does
StringUtility.CStr(...) make it easier for you to use? Would that make it
more "OO" to you?

As for CStr() in particular, I've said over and over that this is my
PREFERENCE and IMHO it doesn't need to be everyone's choice. Using
ToString on string values along with an Is Nothing check works in every
single situation. CStr() would need an IF Then check of its own to
validate its conversion, so the two approached amount to roughly the same
amount of code.

The latter accomplishes encapsulation. The former (your method) accomplishes
needlessly verbose code.

Now, CMM and Herfried have changed their original stance and admitted that
if you need to process Nothing differently than a string, you will have
problems with CStr().

I admitted nothing that isn't already obvious nor changed my stance. If you
need to treat Nothing differently than EmptyString then it's obvious you
wouldn't use CStr. Instead, it would behoove you to write your own helper
function.... like, SafeGetString(object, valueIfNothing) As String...
instead of littering If Is Nothing conditionals all over your code.

Again encapsulation is a good practice.

And in *my* travels, handling Nothing differently than a string value is
pretty darn common, which means using ToString makes perfect sense in
every situation I encounter.

In *my* travels, you usually want to treat Nothing as EmptyString. The
instance where this isn't true is rare and specialized. Indeed, the VB
language stresses this in that its Equality operators reinforce this notion.
I've alluded to this in another post in this thread... but, possibly VB is
not the language for you.

For advocating this, CMM and Herfried have decided to get personal and
call me stupid. I don't know CMM, but I wouldn't have expected that from
Herfried.

No one called you stupid... as a personal attack. If anything I said
offended you, I apologize.

 

[CMM]

SafeGetString(object, valueIfNothing) As String

Encapsulation, my friend. It's a great practice.

 

[Scott M.]

Considering CStr and its older Str cousin have been around since

B.A.S.I.C. I'd chalk it up to just not understanding what VB as a
high-level coding language is versus the framework its latest incarnation
rides on.

It's obvious that you are just not willing to entertain any point of view
that is different than yours and that anyone who disagrees is short-sighted,
ignorant and stupid. I feel that using the object oriented approach makes
my code more scalable and consistent with an all-purpose approach. I also
believe that people who have something to say that doesn't jive with my
approach shouldn't be insulted for expanding their minds.

 

[CMM]

It's obvious that you are just not willing to entertain any point of view
that is different than yours and that anyone who disagrees is
short-sighted, ignorant and stupid. I feel that using the object oriented
approach makes my code more scalable and consistent with an all-purpose
approach. I also believe that people who have something to say that
doesn't jive with my approach shouldn't be insulted for expanding their
minds.

I think I've given examples and fully explained why I *think* you're wrong.
You've offered no evidence or really explained why your suppositions are
correct other than you consider VB's keywords to be "legacy."

 

[Cor Ligthert [MVP]]

Scott,

internally this "function" operates as a method, but from a coding *style*
perspective the developer is not using a method, they are using a language
construct.

With that you want to say that this in C# should not be used to cast

DataTable MyTable = ((DataSet) DataGrid.DataSource).Tables[0];

I don't know another method by the way in C#.

As I have often said is for me a language grown up when it has synoniems to
express the same things. Otherwise it is not a language but a code system.

However, as you probably know, just an often by me told thought,

Herfried and Carlos did not tell that you are stupid. They found the
construction you made stupid, what tells nothing about you. That we do we
all I hope sometimes (at least me).

Cor

 

[Scott M.]

As for "calling you stupid"... I don't think that it was anyone's

intention to level a personal insult.

Then your communication skills leave much to be desired. Go back and read
what you've written.

 

[CMM]

Well, I think at one point I confused your posts with Bob Lehmann's posts
for some reason. So, for that I apologize. The tone of your posts did not
merit my pugnacious responses.

(I still think you're wrong. )

 

[Scott M.]

I hope you're teaching your students about encapsulation. Because that's

exactly what CStr is.

I am and I do. But CStr() is not an object method as such. It is a
language element that (as this thread has shown) confuses many who encounter
it. My OPINION and PREFERENCE is to avoid it. I could easily turn your
statements around to say that to not use ToString is being ignorant of the
underlying framework that VB runs on.

Also, the fact that by-design the .NET String object violates the strict
"object ORIENTED" notion that you seem to be harping on. For instance,
s.ToUpper() doesn't exactly perform a true OO operation (in that s isn't
modified). So there goes that.

The immutable nature of the String class does not break any OO doctrine. It
simply has to do with memory management. There goes nothing.

In this context, yes there is a difference between a method and a language

Also known as a keyword, right? Well, that's what makes VB "VB."
Respectfully, if you don't like the things that make VB "VB," maybe you
shouldn't be using or teaching VB. C# seems much better suited to your
preferences, no?

That's your opinion and you are entitled to it. There are many things that
are part of VB.NET because MS hasn't found an appropriate way of losing it
from the language. I call CStr(), LCase(), UCase(), Time(), Hour(),
Replace(), Split() et all legacy functions because I believe that's what
they are. I believe they exist as part of the VB language syntax to provide
VB 6.0 developers (and the millions of lines of code written by them) a
transition into the .NET programming platform. I do firmly believe that,
over time, they will be phased out of the language and so I steer clear of
them.

They offer many benefits. Maybe it might help if somebody wrapped that all
up as Shared Methods in a "StringUtility" class? Does
StringUtility.CStr(...) make it easier for you to use? Would that make it
more "OO" to you?
Yes.


The latter accomplishes encapsulation. The former (your method)
accomplishes needlessly verbose code.

Your opinion. There are those that say that the entire VB language is
verbose. If you don't like verboseness, may I respectfully suggest you try
C# and that maybe VB.NET isn't for you?

 

[Scott M.]

I don't disagree at all, but now SafeGetString does what I want, it is an
object method and is not in danger of being deprecated at some point, right?

 

[Scott M.]

If you really believe that, then you have shown that you haven't really read
my posts. I've said over and over that if you want to treat Nothing
differently than and empty string that CStr() is not a good idea. I've also
indicated *why* I call CStr() and its friends legacy functions. You just
haven't bothered to read what I've written.

 

[Cor Ligthert [MVP]]

Scott,

That's your opinion and you are entitled to it. There are many things
that are part of VB.NET because MS hasn't found an appropriate way of
losing it from the language. I call CStr(), LCase(), UCase(), Time(),
Hour(), Replace(), Split() et all legacy functions because I believe
that's what they are. I believe they exist as part of the VB language
syntax to provide VB 6.0 developers (and the millions of lines of code
written by them) a transition into the .NET programming platform. I do
firmly believe that, over time, they will be phased out of the language
and so I steer clear of them.

You can find that, which is your own right. However it is not an official
Microsoft statement.

Those methods you mention are from Visual Basic not VB6.

For upgrading from VB6 is the Microsoft VisualBasic Compatible Namespace.
However that is completely something different. The methods you name above
are not in that.

That the Visual Basic methods are not in the standard namespace is for me
obvious. In past you would never had a Java or C++ programmer who would look
to a program language that had statements like Visual Basic. So they are
probably therefore kept hidden in C#. (This last is just my own idea, I
think that this will ever be committed).

There is no problem to use the by you so avoided methods in C# or C++
managed.

However to be clear, there is no reason that you "should" use them, although
a student who does not know them, does not know Visual Basic Net.

Cor