what the c# equivalent of ...

  • Thread starter Thread starter Guest
  • Start date Start date
This could be :

double c = double.Parse(a) + double.Parse(b)

Fabien

"jose g. de jesus jr mcp, mcdba"
 
given VB's tendency to hide errors, the Val() call would return a zero if
the string couldn't be parsed.

Therefore, the equivalent would more likely be:

string a = "233";
string b = "abc";
double conv_a, conv_b;
double.TryParse(a,NumberStyles.Integer,
CultureInfo.CurrentCulture.NumberFormat, conv_a);
double.TryParse(b,NumberStyles.Integer,
CultureInfo.CurrentCulture.NumberFormat, conv_b);
double c = conv_a + conv_b;


--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
 
Actually, I would think that the best choice would be to actually use
the Val function in VB, by adding a reference to Microsoft.VisualBasic.dll
and then use the static Val method on the Conversion class in the
Microsoft.VisualBasic namespace?

Hope this helps.
 
Actually, I would think that the best choice would be
to actually use the Val function in VB, by adding a
reference to Microsoft.VisualBasic.dll and then use
the static Val method on the Conversion class in the
Microsoft.VisualBasic namespace?
Click to expand...

Since C# is supposed to be a complete language in its own right, I'd
advise against using the contents of this namespace unless you're in a
big hurry to port some old code. Yeah, I know this is a matter of
debate, but IMHO when you include the VisualBasic namespace you might
as well be flagging your code with ObsoleteAttribute.

P.
 
But as another poster pointed out, many VB backward-compatibility functions
have subtle (and sometimes evil) behaviors that are designed for VB6
compatibility, and if the code expressly or unconsciously relies on these
behaviors, then using straightforward CLR code may get the job done but
without the VB6 side effects and therefore without the exact same execution
path.

I don't know how much of a newbie the OP was but really the simplest answer
is:

string a = "123";
int c = Convert.ToInt32(a);

.... or the equivalent ToDouble() or whatever. But you have to ask yourself
what happens with boundary conditions such as an empty, null or non-integer
string with the original Val() function, and then if the behavior is
different you have to decide whether it matters, or whether you want to use
more standard or robust methods of dealing with those boundary conditions.

One of VB.NET's dirty secrets is that in an effort to ease the VB6 to VB.NET
transition, developers have been encouraged to use Val() and CInt() and
CType() and so forth, rather than write standard .NET API calls. And it
creates issues such as what we're now discussing when you want to port code,
and sometimes creates issues in mixed-language projects. Since I never did
much VB6 and learned C# as my first and primary .NET language, when I get
involved in a VB.NET project I tend to write VB.NET versions of how
something would be done in C#. This produces somewhat different code than
most VB coders tend to write. Not wildly so, but more CLR oriented than VB6
oriented. My VB.NET code could get by without VisualBasic.dll.

By contrast someone who started with, say, QuickBasic and has stayed with
the language ever since understandably tends to want to write code the way
they always have, out of affection and nostalgia. And that's arguably fine
if you really want to stay exclusively in a parochial VB-centric
environment. But I think it cuts your flexibility down.

--Bob
 
Back
Top