Re: test if a string is a valid 'number'?



It is true it takes a bit more work to support multiple locales. It depends on whether or
not you also want to support postfix sign (which is one of the locale options). Then the
issue is whether or not you want to accept prefix or postfix signs or both. None of these
are very hard to add; all you need is a spec. Do you know if the VB subroutine handles
any of these situations beyond the decimal point?

I'm already getting request to convert code to Win64, if for no other reason that a
compute-bound 64-bit app actually runs in about 75% of the time of a 32-bit app on the
same platorm.
joe


On Thu, 31 May 2007 10:29:49 -0700, "Ashot Geodakov" <a_geodakov@xxxxxxxxxxxxxxxxxx>
wrote:

Comments:

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:hhht535lr0fert96g6mngbfh9bbat30arb@xxxxxxxxxx
My code does work, does sell, and doesn't require grotesque solutions. I
can write an FSM
to parse an integer in less time than it takes to discover how to find a
function in VB,
invent a way to call it, and create distribution package that includes the
DLL. In fact,
I can write an FSM to parse an integer as fast as I can type it in.

I am happy for you, but there was already a message about
internationalization.

If you care so much about Win64 (which is really not so widely spread in the
market yet), then how fast can you write your FSM for many different
locales, that are already out there, running on Win32?


The "need it NOW" approach has led to more bad decisions, some of which
took MONTHS to
undo, and some of which cost us customers because the problems that
resulted created code
that was unreliable.

Yes, some decisions are bad, but hey, basketball score changes 5 times per
minute, and stocks go up and down at the speed of light. There is software
that you spend years thinking through carefully, and there's one that you
need "right here and right now".


The best possible solution would be an optimized FSM, but an optimized FSM
takes too long
to write and doesn't matter when the unoptimized version can parse a
number in under a
microsecond. But a kludgy solution remains a kludgy solution. The
long-term implications
of code that is this bad are far more serious.

This whole discussion has stemmed from a simple question. And nobody seemed
to really be interested in some basic details.

1) The main one: what is the developer trying to accomplish?
1a) Is it some school project or a marketable product?
1b) When is the solution needed (yesterday, in a month, in a year)?
1c) What's the lifespan of the solution? (Boss wants some printed report
right now, and won't care about it tomorrow?)

2) What are the performance requirements?
3) What's the target environment?

I see you rush to judge and to provide with "the most stylish" code (which,
the style, I still have questions about). You didn't even ask these basic
questions.


This violates the KISS principle: Keep It Simple. It adds unnecessary
complexity to the
system, creating failure points that do not need to exist. The simplest
one that should
be at the forefront of all decisions is "Will it run under Win64?", which
this clearly
will not (The Win64 compilers do not support embedded assembler, and you
can't call 32-bit
DLLs from 64-bit apps).

Yea, yea... How well spread is Win64 today? Why aren't you more concerned
about the code portability from Win32 to Linux, which, if I am not mistaken,
owns about 10% of the market?


One company I worked for failed because management kept pushing for quick
solutions, and
would not accept the time required to do correct solutions.

This is from your point of view.

There's also management's point of view, investor's point of view,
customer's point of view.

Write the best code in the world, and spend some decent time doing it. But
the money flow stops, and voila! Let's blame the developer in the
neighboring cubicle for his bad programming style!

I learned a lot about project
management from that company, mostly from antipatterns of bad management.
I got a lot of
flak because I would not accept short-term kludges, yet my code didn't
break. Everyone
who did quick & dirty solutions ended up having to rewrite their code
again and again to
get it right. The result was a failure to ship (my code, for example, was
running solidly
for a YEAR while the code around it got rewritten and rewritten and
rewritten until that
particular project failed. During that year, I ended up rewriting several
modules for
other people, and once rewritten, my code remained solid and required no
support
whatsoever. Meanwhile, the quick & dirty code got rewritten yet again...)

Again, good for you.

I've worked for many companies too, and had seen tons of crappy code.
However,

1) Rewriting it for the sake of beauty wastes more time than fixing a bug,
adding what customer wants, plus shipping, plus finding more customers.
2) Since rewriting is not an option, you have to adapt. You need to work
around existing flaws.


I have no respect whatsoever for the kind of solutions that this code
demonstrates,
because I've seen the ultimate consequences of these solutions, code that
breaks far too
easily.

I am sorry that you have no respect for the sample. Hey, take it easy
though - you don't have to use it, and I don't insist on you dramatically
changing your own style, so that a modest person like me will approve it.

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.