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

See below...
On Wed, 30 May 2007 22:44:43 -0700, "Ashot Geodakov" <a_geodakov@xxxxxxxxxxxxxxxxxx>
wrote:

Comments now...

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:faes535sha68g7f36km2qjp45h3k496jq8@xxxxxxxxxx
Yes, but it is also unfair to Swiss Army Knives to compare VB to them. It
is an insult to
Swiss Army Knives everywhere!

The code was truly bizarre, and predicating it on the existence of VB
(which I don't have
on any of my production machines, just one development machine). Using
embedded assembly
code to accomplish the trivial call to the subroutine is equally weird.

Ever heard of InstallShield? Like, including required DLLs in the package?

As for embedded assembly:
1) It's part of C++
*****
Not on Win64!
*****
2) It accomplishes the task
*****
So does Func(args) where Func is a pointer to the function, so why choose a non-portable
and, frankly, grotesque solution to something that is ALREADY part of C++, in the actual
syntax of the language, requiring NO assembly code? You could even port the code to
Win64!

You put assembly code inline when there is no alternative. In this case, it is simply
foolish, because C++ ALREADY SUPPORTS WHAT YOU WANT!
*****
3) It let me use the already developed code instead of (reinventing a wheel)
writing a new parser
*****
It probably took longer to figure this out than to write a parser. Requiring a load of
the massive VB dll EACH TIME a number is checked is grotesque, to put it mildly. Do you
have performance data on this? Remember, I always say "Performance doesn't matter until
it matters, then it matters a lot". Do you really know how long this takes? (Operations
that have direct impact on user response time matter). Whereas your own FSM would execute
it time measured in at most a few hundred nanoseconds, and not require distributing a
massive DLL to solve one tiny little problem.
*****


It is one of those examples that proves that a solution "that works" can
clearly be the
worst possible solution, but hey, it works, so why do we care about
comprehensibility,
portability, usability, or anything else that might matter outside the
author's particular
development environment?

I really don't have a single example of software that lasted for ages. I
learned long time ago that code that we write is not gonna end up in a
Museum or a Library of Classic Code. It's written, it lives through a couple
of versions, then it's thrown out and rewritten. Repeat until retirement.
*****
I'm maintaining code I wrote 12 years ago. It is in daily use in thousands of
installations. Another program started on MS-DOS in the mid-1980s, and although I don't
think it is still in use, it was converted to Win16 and then Win32. The longest-lived
program I wrote ran for almost 20 years, until the last instance of the computer on which
it ran disappeared, in late 1991. There may yet be instances still running but I haven't
heard of them.
*****

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

Relevant Pages
Quantcast