>Let’s also look at alternatives. Off the top of my heard, when I think
about how much C code it would take to do the equivalent work of the culture
correct version of .Net Parse, I’d offhand say the work will often simple
not get done, and the effect will be >the conversion of numbers will more
often be wrong when using culture local strings.
There’s always Boost…
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Sunday, July 11, 2010 7:14 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re: need advice learning driver development
One example is numeric input and output. Everyone I’ve seen
programming .NET applications uses the default ToString() and Parse()
methods to
handle
numbers. It’ll all work fine in your office, but send it to someone in
mainland
Europe and it’ll start crashing because there will be a mixture of
decimal separators in use.
It’s easy to be a sheep and go along with some comment that says “.Net is
bad”, but I was curious about the accuracy of this .Net bashing and looked
up up the doc page on .Net Parse.
You will get a FormatException if you use the Parse(String s) method on an
international format number. The docs for Parse are very explicit on its
behavior and limitations, and also refer you to fancier version of Parse
that will correctly work on culture local numbers. The docs section title
“Parsing Numeric Strings” gives the managed C++ example code:
CultureInfo^ MyCultureInfo = gcnew CultureInfo(“en-US”); String^ MyString =
“123,456”; int MyInt = int::Parse(MyString, NumberStyles::AllowThousands,
MyCultureInfo);
It seems like .Net is getting bashed because some programmer didn’t read the
very clear and explicit docs on how to convert numeric strings to numbers.
One might argue that the simple version of Parse should just “do the right
thing” when presented with a culture local string, although it’s a religious
battle to say this is right or wrong, and depending on your religion you
will have a different opinion.
Let’s also look at alternatives. Off the top of my heard, when I think about
how much C code it would take to do the equivalent work of the culture
correct version of .Net Parse, I’d offhand say the work will often simple
not get done, and the effect will be the conversion of numbers will more
often be wrong when using culture local strings.
It sounds like the argument is: .Net is bad because it provides built in
methods to correctly handle culture local format conversion? Or perhaps:
.Net is bad because it raises an exception when code detects a condition it
can’t handle? Or based on a sample size of 1, where a programmer didn’t
follow the docs, we have just proven .Net is junk.
Beliefs are grown with evidence as fertilizer, and you need to take care
which fertilizer you use, and which seedlings you fertilize. Once a belief
is grown, changing its root system is pretty difficult, and before fully
grown its not always easy to tell the weeds from the flowers.
Jan
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer